Service Mesh 是一種用於管理微服務架構中網絡通信的解決方案，通過在每個服務實例中添加代理，實現流量控制、服務發現、負載均衡等功能。雖然 Service Mesh 能夠提供很多優秀的功能，但也存在一些性能問題，譬如
- 延遲增加：Service Mesh 中每個服務的請求都必須經過一系列的代理，在代理的處理過程中會增加一定的延遲。
- 資源佔用增加：每個代理都需要一定的 CPU、內存等資源，因此隨着服務數量的增加，代理的資源佔用也會相應地增加。
- 此外，如果開啓了 TLS 安全機制，Service Mesh 中的代理會對流量進行加密和解密，這會消耗一定的資源。
在實際使用中，需要根據具體情況進行選擇和優化，以達到更好的性能和用戶體驗。而作爲業內首個全託管 Istio 兼容的服務網格產品 ASM，一開始從架構上就保持了與社區、業界趨勢的一致性，控制平面的組件託管在阿里雲側，與數據面側的用戶集羣獨立。阿里雲服務網格 ASM 產品也是首批通過可信雲服務網格性能測評，先進級認證、排名第一、全項滿分。
阿里雲服務網格 ASM 產品是基於社區開源的 Istio 定製實現的，在託管的控制面側提供了用於支撐精細化的流量管理和安全管理的組件能力。通過託管模式，解耦了 Istio 組件與所管理的 K8s 集羣的生命週期管理，使得架構更加靈活，提升了系統的可伸縮性。
下圖是阿里雲服務網格 ASM 產品的技術架構。
託管式服務網格 ASM 在成爲多種類型計算服務統一管理的基礎設施中，提供了統一的流量管理能力、統一的服務安全能力、統一的服務可觀測性能力、以及基於 WebAssembly 實現統一的代理可擴展能力，以此構築企業級能力。
可以通過：https://www.aliyun.com/product/servicemesh 查看具體的內容介紹。
以下將講述 ASM 產品從多維度、不同層面的性能優化手段來構建網格優化中心， 提升產品的性能指標與高可用性：
- 收斂服務發現的範圍，提升網格配置的推送效率
- 基於訪問日誌分析自動推薦生成 Sidecar 對象，以減少代理資源消耗
- AdaptiveXDS：自適應配置推送優化
- 軟硬結合性能優化的持續推進
- 資源超賣模式下的支持
- 基於 eBPF tcpip-bypass 的數據面性能優化
01 收斂服務發現的範圍，提升網格配置的推送效率
在 Istio 中，可以通過以下幾種方式收斂服務發現的範圍，從而提高控制平面推送網格配置的效率。通過收斂服務發現範圍，可以達到如下目標，包括有效降低控制面組件 CPU 資源消耗與內存資源消耗、以及有效降低控制面組件與網格代理之間的通信時的帶寬資源消耗。
通過 Discovery Selector 可以定義一組過濾規則，用於篩選出需要同步到控制平面的服務發現信息：
- 基於命名空間範圍的篩選，自動發現數據面 Kubernetes 集羣中指定命名空間下的服務；
- 與 Istiod 直接交互，有效提升控制面的處理效率；
此外，通過 ExportTo 與 Workload Selector 來收斂規則配置的範圍，其中：
- ExportTo 用於控制規則(VirtualService, DestinationRule, ServiceEntry 等)的可用性範圍，Workload Selector 用於配置規則(DestinationRule, ServiceEntry, EnvoyFilter, Sidecar)適用的服務範圍；
- 既可以支持全局設置(meshconfig)或命名級別設置，又可以支持細粒度設置(per service/config)；
- 定義的內容類似如下：
阿里雲服務網格 ASM 產品提供了對應的功能，具體來說，可以通過選中或取消選中命名空間來定義服務發現的範圍，如下圖所示：
此外，也可以支持通過編輯標籤選擇器的方式選擇對應的命名空間下的服務，如果數據面 Kubernetes 集羣的命名空間與任一標籤選擇器匹配，該命名空間下的服務將被包括在自動發現範圍之內。同時，數據面 Kubernetes 集羣的命名空間必須與每個標籤選擇器中定義的所有規則相符，才能被該選擇器選中。
如下圖所示：
更多細節，可以參考：https://help.aliyun.com/document_detail/363023.html
02 基於訪問日誌分析自動推薦生成 Sidecar 對象，以減少代理資源消耗
這個優化手段是基於 xDS 及 Sidecar 對象實現的，首先介紹下對應的背景信息。
xDS 協議是 “X Discovery Service” 的簡寫，是 Service Mesh 控制面和數據面 Sidecar Proxy 之間的通信協議，x 表示包含多種協議的集合，比如：LDS 表示監聽器的發現，CDS 表示服務和版本的信息，EDS 表示服務和版本有哪些實例，以及每個服務實例的特徵信息，RDS 表示路由的發現。
xDS 協議是網格代理獲取配置信息的傳輸協議，也是 Istio 與網格代理連接的橋樑。可以簡單的把 xDS 理解爲：網格內的服務發現數據和治理規則的集合。xDS 數據量的大小和網格規模是正相關的。
默認情況下，下發 xDS 使用的是全量下發策略，也就是網格里的所有網格代理內存都會有整個網格內所有的服務發現數據。
在大多數情況下，在大規模集羣中的一個簡單的工作負載可能只與少數其他工作負載進行通信。將它的配置更改爲僅包含一組必要的服務會對網格代理的內存佔用產生很大影響。Sidecar 資源對象可以幫助定義這種配置約束關係。
基於訪問日誌分析自動推薦生成 Sidecar 資源對象的工作實現原理：
- 通過分析數據平面網格代理產生的訪問日誌獲取數據平面服務之間的調用依賴關係，爲數據平面中的每個工作負載自動推薦生成相應的 Sidecar 資源對象。
- 然後根據分析結果生成出 Sidecar 資源對象之後，允許用戶進行二次確認，或者用戶基於自動生成的內容進行定製修改。
它適合的場景是已經存在了這些服務調用的日誌數據，並且現有業務服務的調用依賴關係變化不大，通過該方式可以一次性地實現優化。以 bookinfo 示例來說，通過幾次請求之後，每個網格代理都會產生對應的訪問日誌。以 productpage 服務爲例，生成的推薦的 Sidecar 資源對象內容如下：
當然，使用該功能需要一定的前提條件：
需要依賴於用戶開通日誌服務來採集這些訪問日誌內容，並要求產生的日誌需要覆蓋全部業務調用，才能得到全部的依賴關係。一旦某業務路徑沒有調用產生日誌，那麼很有可能丟失對應的服務依賴關係，從而導致生成的 Sidecar 資源對象定義內容不準確，進而可能導致之後的該業務路徑訪問調用不通。
阿里雲服務網格 ASM 產品提供了對應的功能，提供了使用基於訪問日誌分析自動推薦的 Sidecar 資源對象來提升 xDS 推送的效率，如下圖所示。
具體可以參考：https://help.aliyun.com/document_detail/386398.html
03 AdaptiveXDS：自適應配置推送優化
爲了緩解上述方案中的侷限性，我們提供了另外一種優化手段，即按需推送 xDS 配置的能力，自適應應用服務的變更。
自適應配置推送優化根據網格內服務的訪問日誌分析服務之間的依賴關係，並自動爲服務生成 Sidecar 資源對象以優化針對該服務工作負載的配置推送。功能開啓後，集羣中會部署名爲 istio-axds-egressgateway 的出口網關，服務之間調用的所有 HTTP 流量初始都將指向該出口網關，並通過網關記錄的訪問日誌自動分析服務之間的依賴關係。
具體來說，通過如下架構圖可以看到：
- 在託管側，Adaptive Xds Controller 組件負責管理 AdaptiveXds-EgressGateway 的生命週期、生成 AdaptiveXds-EgressGateway 所需的 Envoy Filter 及 Bootstrap 配置等；
- 啓用該功能之後，AdaptiveXds-EgressGateway 會上報訪問日誌到 Access Log Service（ALS）服務；
- Access Log Service（ALS）負責接收網格代理髮送的日誌數據，並結合 ALS Analyzer 分析日誌內容，然後根據服務調用依賴關係生成對應的 Sidecar 資源對象；
要爲集羣內的服務啓用自適應配置推送優化能力，可以按照命名空間範圍進行開啓。開啓後，命名空間內的服務都將自動地進行基於 Sidecar 資源對象的配置推送優化。
此外，也可以在 Kubernetes 服務的 annotations 中增加 http://asm.alibabacloud.com/asm-adaptive-xds: true 註解以單獨爲該服務打開優化選項。
在使用 ASM 產品的某客戶場景中，通過該方式優化之後，網格代理中的配置減少了 90%，所消耗的內存消耗從 400M 減少到 50M。
阿里雲服務網格 ASM 產品提供了對應的功能，提供了自適應配置推送優化提升 xDS 推送的效率以及減少網格代理的不必要配置。
具體可以參考：https://help.aliyun.com/document_detail/479108.html
04 軟硬結合性能優化的持續推進
數據面的形態是多樣的，運行的 ECS 規格型號、OS 的版本等都不盡相同，通過探測節點的特徵，我們可以更好地理解節點所具備的支撐能力，譬如可以根據 Kernel 版本判斷是否可以支持 eBPF 的相關功能，根據是否支持 AVX 擴展指令集決定開啓 TLS 加解密處理能力, 或者判斷是否提供了 Device Plugin 等。
也就是說，通過檢測 Kubernetes 集羣中每個節點上可用的硬件功能特徵, 包括 CPUID 特徵、指令集擴展等；然後根據探測到的特徵，自適應動態配置相應的特性， 自適應啓用或禁用對應特性，整個過程對用戶無感知。
這樣一來，可以充分利用用戶使用的節點環境，動態啓用這些特性，從而提升相應的能力。在阿里雲服務網格 ASM 產品中，已經上線的功能包括了根據是否支持 AVX 指令集動態啓用 Multi-Buffer 特性，提升 TLS 加解密性能。
具體可以參考與 Intel 合作的技術白皮書：https://developer.aliyun.com/ebook/7817
具體來說：
1) 在服務網格控制面，通過擴展 MeshConfig 或者 CRD 方式，爲用戶提供統一的聲明式配置定義。
2) 控制面的配置通過 xDS 協議下發到數據面 Envoy 代理。這一部分也是在 ASM 產品中做的一些擴展能力。
3) 工作負載 Pod 的調度優先與自適應動態配置。通過對節點的特徵標識，ASM 優先將啓動 Multi-Buffer 功能的 Pod 調度到對應的節點上，從而使得相關的功能能夠被啓用。除了調度之外，ASM 產品支持自適應動態配置能力，也就是說即使沒有對應的節點可調度，這些 Pod 在其他節點上部署時, 能夠自適應去禁用這些功能。
05 資源超賣模式下的支持
在 Kubernetes 系統中，Kubelet 通過參考 Pod 的 QoS 等級來管理單機容器的資源質量，例如 OOM（Out of Memory）優先級控制等。Pod 的 QoS 級別分爲 Guaranteed、Burstable 和 BestEffort。QoS 級別取決於 Pod 配置的 Request 和 Limit（CPU、內存）。
ack-koordinator 提供動態資源超賣功能，通過對節點負載數據的實時收集，可以充分挖掘集羣中已分配但未使用的資源量，以實現對集羣資源的動態超賣。
注意的是，一般不強制資源限制和所需資源配置爲相同值。建議您參照工作負載類型，對資源限制和所需資源進行配置。
- 若 QoS 爲 Guaranteed 類型的工作負載，建議您兩者配置爲相同值。
- 若爲其他類型的 Pod，建議您保持與原生資源類型中所需資源小於資源限制的約定。
阿里雲服務網格 ASM 產品提供了對應的功能，您可以設置注入的 Istio 代理以及 isito-init 初始化容器的 ACK 動態超賣資源。
更多信息，請參見配置 Sidecar 代理：https://help.aliyun.com/document_detail/613582.html
06 MerBridge：基於 eBPFtcpip-bypass 的數據面性能優化
eBPF 是一項獲得廣泛關注和普及的技術，尤其是在流量、性能方面提供許多潛在的優化功能，例如在服務網格領域用 eBPF 替換 iptables 以在網格內進行流量重定向的功能。
Merbridge 是專注於使用 eBPF 加速服務網格的 CNCF 開源項目。Merbridge 在服務網格中使用 eBPF 技術代替 iptables，實現流量攔截。
藉助 eBPF 和 msg_redirect 技術，Merbridge 可以提高 Sidecar 和應用之間的傳輸速度，降低延遲，如下圖所示。
eBPF 提供重寫 tcp_sendmsg 函數的能力，讓 eBPF Program 接管 tcp_sendmsg。
同時，eBPF 提供了 bpf_msg_redirect_hash 相關的 helper 函數，可以在被接管的 tcp_sendmsg 內將主機上的兩個 socket 傳輸路徑進行短接，繞過內核態協議棧，從而加速進程間的訪問。
Helper 函數依賴一個內核級別的 map 保存連接信息，需要確保每個連接在 map 中的 key 互不衝突。
Ambient 模式下，加入/移除網格將更加靈活，CNI 模式將不再適用（CNI 只會在 Pod 創建的時候生效，Ambient 模式允許通過修改 annotation 的方式將 Pod 納入網格）。
Container 出口流量攔截的地址將不再是 127.0.0.1:15001，而需要轉發到當前節點 ztunnel 實例。
由於 Pod 中不存在 Sidecar，之前通過判斷是否監聽 15001 端口等方案來確定是否需要攔截的方案將不再生效。
如何解決 Ambient 模式下這些問題呢？
通過 eBPF 觀察進程創建事件，在用戶態關聯 cgroup id 和 Pod IP。同時，將 Pod 信息等進行儲存。
在 eBPF 程序中，通過當前進程的 cgroup id 查找當前進程的 Pod IP。（一個容器中的進程應該具有相同的 cgroup id，且不會變更）
如果是 Ambient 模式的 Pod 發出的流量，將流量轉發到 ztunnel。
阿里雲服務網格 ASM 產品也在專注於一些基於 eBPF 以及阿里雲容器服務 ACK 網絡插件的性能改進，同時也正在與 Merbridge 團隊更多地合作。
儘管我們已經實現了上述幾種維度下的性能優化手段，然而衆所周知性能是一個需要持續關注的話題，我們會進一步探索和研究，找到更加有效的解決方案，以提高 Service Mesh 的性能和穩定性。
作者：王夕寧 本文根據王夕寧在 2023 年 6 月份在北京舉行的 CNCF Kubernetes Community Day（KCD）會議上的演講主題整理而成
點擊立即免費試用雲產品 開啓雲上實踐之旅！
本文爲阿里雲原創內容，未經允許不得轉載。