（譯）Istio 元件的效能與伸縮性
Istio 在不侵入應用程式碼的情況下，在應用服務之間建立了具備豐富的路由能力、負載均衡、服務間認證、監控等功能的網路。Istio 的目標是使用最小資源開銷來提供這些能力，並能夠為負載大量請求的大規模叢集提供低延遲服務。
Envoy 作為 Istio 的資料平面元件，在系統中負責資料流的處理。Istio 控制面元件包括 Pilot、Galley 和 Citadel，負責對資料平面進行控制。資料平面和控制平面在效能方面有著不同的側重點。
Istio 1.1.3 效能概述
Istio 負載測試網格由 1000 個服務和 2000 個 Sidecar 組成，每秒鐘產生 70,000 個網格範圍內的請求。在使用 Istio 1.1.3 完成測試之後，我們獲得了以下結果：
-
Envoy 在每秒處理 1000 請求的情況下，使用 0.6 個 vCPU 以及 50 MB 的記憶體 。
-
istio-telemetry在每秒 1000 個 網格範圍內的請求的情況下，消耗了 0.6 個 vCPU 。 -
Pilot 使用了 1 個 vCPU 以及 1.5 GB 的記憶體。
-
Envoy 在第 90 個百分位上增加了 8 毫秒的延遲。
控制平面的效能
Pilot 根據使用者編寫的配置檔案，結合當前的系統狀況對 Sidecar 代理進行配置。在 Kubernetes 環境中，系統狀態由 CRD 和 Deployment 構成。使用者可以編寫 VirtualService 、 Gateway 之類的 Istio 配置物件。Pilot 會使用這些配置物件，結合 Kubernetes 環境，為 Sidecar 生成配置。
控制平面能夠支援數千個 Pod 提供的數千個服務，以及同級別數量的使用者配置物件。Pilot 的 CPU 和記憶體需求會隨著配置的數量以及系統狀態而變化。CPU 的消耗取決於幾個方面：
-
部署情況的變更頻率。
-
配置的變更頻率。
-
連線到 Pilot 上的代理伺服器數量。
然而這部分的本質上就是支援水平伸縮的。
在啟用了名稱空間隔離的情況下，單一 Pilot 例項在使用 1 個 vCPU 和 1.5 GB 記憶體的情況下，能夠支援 1000 個服務、2000 個 Sidecar。可以增加 Pilot 例項數量來降低為 Sidecar 進行配置分發所需要的時長。
資料平面效能
資料平面同樣會受到多種因素的影響，例如：
-
客戶端連線數量。
-
目標請求頻率。
-
請求和響應尺寸。
-
代理執行緒數量。
-
協議。
-
CPU 核數。
-
Sidecar filter 的數量和型別，尤其是 Mixer filter 。
可以根據這些因素來衡量延遲、吞吐量和 Sidecar 的 CPU 以及記憶體需求。
CPU 和記憶體
Sidecar 會在資料路徑上執行額外的工作，也自然就需要消耗 CPU 和記憶體。Istio 1.1 中，代理在每秒 1000 請求的負載下，需要 0.6 個 vCPU。
Sidecar 的記憶體消耗取決於代理中的配置總數。大量的監聽器、叢集和路由定義都會增加記憶體佔用。Istio 1.1 中加入了名稱空間隔離功能，來限制傳送到 Sidecar 上的配置數量。在一個較大的名稱空間中，Sidecar 要消耗接近 50 MB 的記憶體。
通常情況下 Sidecar 不會對經過的資料進行快取，因此請求數量並不影響記憶體消耗。
延遲
Istio 在資料路徑上注入了 Sidecar，因此延遲是一個重要的考量因素。Istio 在代理中加入了認證和 Mixer 過濾器。每個額外的過濾器都會加入資料路徑中，導致額外的延遲。
在響應傳送給客戶端之後，Envoy 會蒐集原始的遙測資料。手機請求原始指標的耗時不會對完成請求的總體時間造成影響。然而因為 Worker 忙於處理請求，因此不會立刻開始處理下一個請求。這一過程會延長下一請求的請求佇列時間，會對平均和尾部延遲造成影響。實際的尾部延遲取決於通訊模式。
在網格里，一個請求會包含客戶端代理和服務端代理兩部分。每秒 1000 請求的情況下，這兩個代理會在資料路徑上加入 8 毫秒（90 百分位）。服務端代理自身會產生 2 毫秒（90 百分位）的延遲。
Istio 1.1.3 的延遲
預設配置的 Istio 1.1 會在資料平面的基線上加入 8 毫秒的延遲（90 百分位）。這一結果的是使用 Istio benchmarks 得出的，測試過程採用了 http/1.1 協議，16個客戶端連線，每秒 1000 請求，兩個代理 Worker，並啟用了雙向 TLS。
在 Istio 的未來版本中，我們準備把 istio-policy 和 istio-telemetry 功能移入代理，稱為 MixerV2 。這會減少系統中的資料流，從而降低 CPU 消耗以及延遲。
-
baseline：客戶端 Pod 直接呼叫服務端 Pod，不經過 Sidecar。 -
server-sidecar：只使用服務端 Sidecar。 -
both-sidecars：使用客戶端和服務端的 Sidecar，這也是網格中的預設案例。 -
nomixer-both：和 both-sidecars 一致，但是去掉了 Mixer。類似MixerV2的延遲情況。 -
nomixer-server：和 server-sidecar 一致，但是去掉了 Mixer。類似MixerV2的延遲情況。
基準測試工具
Istio 使用下列工具進行基準測試：
-
fortio.org：一個恆定吞吐量的負載測試工具。
-
blueperf：一個模擬的雲原生應用。
-
isotope：具備可配置拓撲結構的合成應用。