idou老師教你學Istio 04：Istio效能及擴充套件性介紹
Istio的效能問題一直是國內外相關廠商關注的重點，Istio對於資料面應用請求時延的影響更是備受關注，而以現在Istio官方與相關廠商的效能測試結果來看，四位數的qps顯然遠遠不能滿足應用於生產的要求。從釋出以來，Istio官方也在不斷的對其效能進行優化增強。同時，Istio控制面的可靠性是Istio用於生產的另一項重要考量標準，自動伸縮擴容，自然是可靠性保證的重要手段。下面我們先從效能測試的角度入手，瞭解下Istio官方提供的效能測試方法與基準，主要分為以下四個方面展開。
一、函式級別測試
Istio提供了函式級別的效能測試用例，開發者可用更好的有針對性的進行效能優化，這裡不做展開，感興趣的朋友可用參考：
https://raw.githubusercontent. ... st.go二、端到端測試基準
為了更好的跟蹤Istio的效能問題，Istio提供了一個專門用於Isito效能測試的測試工具——Fortio。你可以通過kubernetes叢集，輕而易舉的將Forito部署起來，測試工具的安裝連結如下：
https://github.com/istio/istio ... 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還需要進一步優化。
第二部分是當前release每日構建版本的效能情況，可以對比出每天的修改對效能方面的影響，這裡我們列出一部分，更詳細的資訊大家可以到相應連結中檢視，可以看到近期每日構建版本相較於1.0基線版本，有了一定的提升。
最後一部分是master分支的每日構建效能測試結果。可以看到，最新的master分支的效能測試結果，相較基線版本已經有了較大的提升，但是QPS損耗嚴重的問題依然存在，同時，千級別的QPS也不能真正滿足生產需求，我們期待Istio的發展與進步。
五、Isito的可靠性與可擴充套件性
對控制面各元件的作用作用及故障影響進行了彙總，結果如下：
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早日成熟，發展壯大，揚帆起航。