idou老師教你學Istio 04：Istio性能及擴展性介紹
一、函數級別測試
Istio提供了函數級別的性能測試用例，開發者可用更好的有針對性的進行性能優化，這裏不做展開，感興趣的朋友可用參考：
https://raw.githubusercontent.com/istio/istio/release-1.0/mixer/test/perf/singlecheck_test.go
二、端到端測試基準
為了更好的跟蹤Istio的性能問題，Istio提供了一個專門用於Isito性能測試的測試工具——Fortio。你可以通過kubernetes集群，輕而易舉的將Forito部署起來，測試工具的安裝鏈接如下：
https://github.com/istio/istio/tree/release-1.0/tools#istio-load-testing-user-guide。
下圖是測試工具的組織結構圖，其中上半部分為Istio服務網格管理的兩個服務S1與S2，其中S1服務關掉了mixer上報功能（mixer遙測功能實現方案一直備受爭議，業界普遍認為sidecar向mixer上報遙測數據一定程度上損害了sidecar的請求轉發能力），請求通過ingressgateway流入系統，再經由sidecar分發到各個服務，是典型的Istio服務訪問方式。下半部分為經典的kubernetes集群中的服務訪問方式，請求經由k8s的proxy的轉發，負載均衡到各個pod。兩者的對比也就展示了Istio訪問模式與經典模式相比，性能方面的損耗，下面介紹一下Fortio的幾個功能點：
a)Fortio是一個快速，小巧，可重復使用，可嵌入的go庫以及命令行工具和服務器進程，該服務器包括一個簡單的Web UI和結果的圖形表示；
b)Fortio也是100％開源的，除了go和gRPC之外沒有外部依賴，能夠輕松地重現Istio官方性能測試場景也能適應自己想要探索的變體或場景；
c)Fortio以每秒指定的qps對服務進行壓測，並記錄影響時延的直方圖並，計算百分比，平均值，tp99等統計數值。
Fortio在kubernetes中的安裝步驟：
kubectl -n fortio run fortio --image=istio/fortio:latest_release --port=8080
kubectl -n fortio expose deployment fortio --target-port=8080 --type=LoadBalancer
三、真實場景下測試基準
Acmeair（又名BluePerf）是一個用Java實現的類似客戶的微服務應用程序。此應用程序在WebSphere Liberty上運行，並模擬虛擬航空公司的運營。
Acmeair由以下微服務組成：
a) Flight Service檢索航班路線數據。預訂服務會調用它來檢查獎勵操作的裏程（Acmeair客戶忠誠度計劃）。
b) 客戶服務存儲，更新和檢索客戶數據。它由Auth服務用於登錄和預訂服務用於獎勵操作。
c) 預訂服務存儲，更新和檢索預訂數據。
d) 如果用戶/密碼有效，Auth服務會生成JWT。
e) 主服務主要包括與其他服務交互的表示層（網頁）。這允許用戶通過瀏覽器直接與應用程序交互，但在負載測試期間不會執行此操作。
這個模擬航空公司的運營系統demo，能夠更好的模擬在實際生產環境中的Istio應用，感興趣的朋友可用到如下鏈接了解一下：https://github.com/blueperf
四、每日構建自動化測試結果
Istio與IBM會對Istio的每日構建版本進行性能測試，並將測試結果公布出來，供大家參考。自動化測試包括端對端用例fortio以及應用級別bluePerf的性能測試結果。對Isito性能感興趣，但沒有時間精力進行性能測試的朋友，可以關註一下官方的每日性能測試結果，跟蹤Istio性能優化的最新進展。
● https://fortio-daily.istio.io/
● https://ibmcloud-perf.istio.io/regpatrol/
這裏，我們一起來看下IBM的性能測試結果，並進行一下分析。
IBM的性能測試對比主要包括三部分，第一部分是各個Release版本之間的性能比較，其中列出了0.6.0,0.7.1,0.8.0版本的性能測試情況，這裏的指標數據是qps，可以看到，前三個版本之間的數據十分相近，沒有比較大的提升，且Istio與IngressOnly之間的對比可以看出，Istio造成了相當大的性能損耗，大約只能達到無Istio時百分之三十多的qps，可見，性能方面Istio還需要進一步優化。
| Row | Release | (A)Istio Full | (B) No Mixer | (C) Ingress Only | (A)/(C) % | (B)/(C) % |
|---|---|---|---|---|---|---|
| 1 | 0.6.0 | 1307 | 1987 | 3804 | 34.4 | 52.2 |
| 2 | 0.7.1 | 1294 | 2050 | 3671 | 35.2 | 55.8 |
| 3 | 0.8.0 | 1335 | 2222 | 3708 | 36.0 | 59.9 |
第二部分是當前release每日構建版本的性能情況，可以對比出每天的修改對性能方面的影響，這裏我們列出一部分，更詳細的信息大家可以到相應鏈接中查看，可以看到近期每日構建版本相較於1.0基線版本，有了一定的提升。
最後一部分是master分支的每日構建性能測試結果。可以看到，最新的master分支的性能測試結果，相較基線版本已經有了較大的提升，但是QPS損耗嚴重的問題依然存在，同時，千級別的QPS也不能真正滿足生產需求，我們期待Istio的發展與進步。
五、Isito的可靠性與可擴展性
對控制面各組件的作用作用及故障影響進行了匯總，結果如下：
| 組件 | 作用及故障影響 |
|---|---|
| istio-ingressgateway | 對外流量入口，該組件掛掉將導致整個應用服務無法從外部訪問，建議設置多實例，增強可靠性 |
| istio-telemetry Mixer | 相關組件，用於采集envoy上報的遙測數據，該組件掛掉將導致各監控運維插件無法采集到數據，同時，該組件在高並發情境下，會承受較大負荷，建議設置為多實例，增強可靠性 |
| istio-policy Mixer | 相關組件，用於與envoy交互，check需要上報的數據，確定緩存內容，掛掉會影響check相關功能 |
| istio-pilot | 控制sidecar中envoy的啟動與參數配置，即流量規則實際下發者，掛掉將會導致新策略配置失效 |
| istio-sidecar-injector | 用於實現sidecar自動註入功能，掛掉將會導致sidecar無法自動註入，同時，若註入策略設置為必須註入（policy為Fail），則會導致新creating的pod無法啟動 |
| istio-citadel | 用於安全相關功能，掛掉則會導致認證，安全相關功能失效 |
a) 考量到Istio控制面的可靠性，以及對資源的有效利用，建議將重要組件設置為多實例，包括：
● ingressgateway：作為外部流量入口，服務網格管理的所有服務的對外流量，都要經過gateway才能進入到服務網格內部，與業務邏輯強相關，建議配置為多實例；
● mixer：遙測數據的搜集端，用於匯總服務網格內所有服務上報的日誌、監控數據，處理數據量巨大，建議設置為多實例，並給予更多資源配置；
● 其他控制面組件運行壓力並不大，可根據需要自行調整實例數。
b) 容器自動擴縮容，Istio為主要組件gateway，pilot與mixer設置了自動擴縮容策略，且策略可以在安裝時配置，我們以pilot為例看一下其自動擴縮容配置，以CPU占用率55%作為閾值，進行pod實例數的擴縮容側率：
c) 高可用（HA），可根據需要，為Istio控制面組件設置親和性策略，使相同控制面組件的多個不同pod運行不同node上，確保Istio控制面的高可用狀態，下面以pilot為例，Istio為其增加了節點反親和策略，使pod盡可能不運行在相同架構操作系統的節點上，大家可根據需要，自行增加親和與反親和策略。
d) 健康檢查，Istio也為控制面組件配置了健康檢查策略，以保證控制面組件異常時，k8s能夠將其重新拉起，同樣以sidecarinjector為例，設置了啟動健康檢查readinessProbe與運行時健康檢查livenessProbe，以確保容器正常運行：
六、總結
再次說明一下，性能與可靠性是Istio生產可用至關重要的一環，功能方面Istio已經做的十分強大，並在不斷的完善發展中，但在性能與可靠性方面，Istio還有很長的路要走。其中微服務sidecar的路由轉發與mixer遙測功能對請求時延的影響，是擺在Istio性能提升前面的兩道障礙，我們共同努力，共同關註，望Istio早日成熟，發展壯大，揚帆起航。
idou老師教你學Istio 04：Istio性能及擴展性介紹