idou老師教你學Istio 04：Istio性能及擴展性介

Istio的性能問題一直是國內外相關廠商關注的重點，Istio對于數據面應用請求時延的影響更是備受關注，而以現在Istio官方與相關廠商的性能測試結果來看，四位數的qps顯然遠遠不能滿足應用于生產的要求。從發布以來，Istio官方也在不斷的對其性能進行優化增強。同時，Istio控制面的可靠性是Istio用于生產的另一項重要考量標準，自動伸縮擴容，自然是可靠性保證的重要手段。下面我們先從性能測試的角度入手，了解下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還需要進一步優化。

第二部分是當前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早日成熟，發展壯大，揚帆起航。