螞蟻金服 Service Mesh 大規模落地系列 - 控制面篇

本文為《螞蟻金服 Service Mesh 大規模落地系列》第七篇 - 控制面篇，該系列将會從核心、RPC、消息、無線網關、控制面、安全、運維、測試等子產品對 Service Mesh 雙十一大規模落地實踐進行詳細解析。文末包含往期系列文章。

引言

Service Mesh 是螞蟻金服下一代架構的核心，本次主題主要分享在螞蟻金服目前的體量下，控制面平穩支撐大規模 Sidecar 的落地實踐。聚焦控制面核心元件 Pilot 和 Citadel，分享螞蟻金服雙十一控制面如何管理并服務好全站 Sidecar。

本次分享主要分為兩大部分，分别是：

• Pilot 落地實踐；
• Citadel 安全加強；

Pilot 落地實踐

在開始分享落地實踐之前，我們先來看看 Istio 的架構圖：

理想很豐滿，現實很骨感。由于性能等方面的綜合考慮，我們在落地過程中，将控制面的元件精簡為 Pilot 和 Citadel 兩個元件了，不使用因性能問題争議不斷的 Mixer，不引入 Galley 來避免多一跳的開銷。

在架構圖中，控制面元件 Pilot 是與 Sidecar 互動最重要的元件，負責配置轉化和下發，直面 Sidecar 規模化帶來的挑戰。這也是雙十一大促中，控制面最大的挑戰。

規模化的問題在生産實踐中，是一個元件走向生産可用級的必經之路。接下來将會分别從穩定性、性能優化、監控這三個方面分别展開。

穩定性增強

我們先梳理下 Pilot 提供的服務能力，從功能實作上來看，Pilot 是一個 Controller + gRPC Server 的服務，通過 List/Watch 各類 K8s 資源，進行整合計算生成 XDS 協定的下發内容，并提供 gRPC 接口服務。本次分享我們先把關注點放在 gRPC 接口服務這個環節，如何保證接口服務支撐大規模 Sidecar 執行個體，是規模化的一道難題。

負載均衡

要具備規模化能力，橫向擴充能力是基礎。Pilot 的通路方式我們采用常用的 DNSRR 方案，Sidecar 随機通路 Pilot  執行個體。由于是長連接配接通路，是以在擴容時，原有的連接配接沒有重連，會造成負載不均。為解決這個問題，我們給 Pilot  增加了連接配接限流、熔斷、定期重置連接配接功能，并配合 Sidecar 散列重連邏輯，避免産生連接配接風暴。

• 連接配接限流

為了降低大量 MOSN 同時連接配接同一個 Pilot 執行個體的風險，在 gRPC 首次連接配接時，Pilot 增加基于令牌桶方案的流控能力，控制新連接配接的處理響應，并将等待逾時的連接配接主動斷連，等待 Sidecar 下一次重連。

• 熔斷

基于使用場景的壓測資料，限制單執行個體 Pilot 同時可服務的 Sidecar 數量上限，超過熔斷值的新連接配接會被Pilot 主動拒絕。

• 定期重置

為了實作負載均衡，對于已經存在的舊連接配接，應該怎麼處理呢？我們選擇了 Pilot 主動斷開連接配接，不過斷開連接配接的周期怎麼定是個技術活。要考慮錯開大促峰值，退避擴縮容視窗之類，這個具體值就不列出來了，大家按各自的業務場景來決定就好了。

• Sidecar 散列重連

最後還有一點是 Client 端的配合，我們會控制 Sidecar 重連 Pilot 時，采用退避式重試邏輯，避免對 DNS 和 Pilot 造成負載壓力。

性能優化

規模化的另一道難題是怎麼保證服務的性能。在 Pilot 的場景，我們最關注的當然是配置下發的時效性了。性能優化離不開細節，其中部分優化是通用的，也有部分優化是面向業務場景定制的，接下來會分享下我們優化的一些細節點。

• 首次請求優化

社群方案裡 Pilot 是通過 Pod.Status 來擷取 Pod 的 IP 資訊，在小叢集的測試中，這個時間基本秒級内可以完成。然而在大叢集生産環境中，我們發現 Status 的更新事件時間較慢，甚至出現超過 10s 以上的情況，而且延遲時間不穩定，會增加 Pilot 首次下發的時延。我們通過與基礎設施 K8s 打通，由 PaaS 側将 Pod 配置設定到的 IP 直接标記到Pod.Annotation 上，進而實作在第一次擷取 Pod 事件時，就可以擷取到 IP，将該環節的時延減少到0。

• 按需擷取 & Custom Resource 緩存

這是一個面向 DBMesh 業務場景的定制性優化，是基于按需擷取的邏輯來實作的。其目的在于解決 DBMesh CR 數量過多，過大導緻的性能問題，同時避免 Pilot 由于 List/Watch CR 資源導緻 OOM 問題，Pilot 采用按需緩存和過期失效的政策來優化記憶體占用。 

• 局部推送

社群方案中當 Pilot List/Watch 的資源發生變更時，會觸發全部 Sidecar 的配置推送，這種方案在生産環境大規模叢集下，性能開銷是巨大的。舉個具體例子，如果單個叢集有 10W 以上的 Pod 數量，任何一個 Pod 的變更事件都會觸發全部 Sidecar 的下發，這樣的性能開銷是不可接受的。

優化的思路也比較簡單，如果能夠控制下發範圍，那就可以将配置下發限制在需要感覺變更的 Sidecar 範圍裡。為此，我們定義了 ScopeConfig CRD 用于描述各類資源資訊與哪些 Pod 相關，這樣 Pilot 就可以預先計算出配置變更的影響範圍，然後隻針對受影響的 Sidecar 推送配置。

• 其他優化

強管控能力是大促基本配備，我們給 Pilot Admin API 補充了一些額外能力，支援動态變更推送頻率、推送限流、日志級别等功能。

監控能力

安全生産的基本要求是要具備快速定位和及時止血能力，那麼對于 Pilot 來說，我們需要關注的核心功能是配置下發能力，該能力有兩個核心監控名額：

• 下發時效性

針對下發的時效性，我們在社群的基礎上補充完善了部分下發性能名額，如下發的配置大小分布，下發時延等。

• 配置準确性

而對于配置準确性驗證是相對比較複雜的，因為配置的準确性需要依賴 Sidecar 和 Pilot 的配置雙方進行檢驗，是以我們在控制面裡引入了 Inspector 元件，定位于配置巡檢，版本掃描等運維相關功能子產品。

配置巡檢的流程如下：

1. Pilot 下發配置時，将配置的摘要資訊與配置内容同步下發；
2. MOSN 接收配置時，緩存新配置的摘要資訊，并通過 Admin API 暴露查詢接口；
3. Inspector 基于控制面的 CR 和 Pod 等資訊，計算出對應 MOSN 的配置摘要資訊，然後請求 MOSN 接口，對比配置摘要資訊是否一緻；

由于 Sidecar 的數量較大，Inspector 在巡檢時，支援基于不同的巡檢政策執行。大體可以分為以下兩類：

1. 周期性自動巡檢，一般使用抽樣巡檢；
2. SRE 主動觸發檢查機制；

Citadel 安全方案

證書方案

Sidecar 基于社群 SDS 方案 （Secret Discovery Service），支援證書動态發現和熱更新能力。同時螞蟻金服是一家金融科技公司，對安全有更高的要求，不使用 Citadel 的證書自簽發能力，而是通過對接内部 KMS 系統獲驗證書。同時提供證書緩存和證書推送更新能力。

我們先來看看架構圖，請看圖：

對整體架構有個大緻了解後，我們分解下 Sidecar 獲驗證書的流程，一圖勝千言，再上圖：

補充說明下圖中的每一步環節：

• Citadel 與 Citadel Agent (nodeagent) 元件通過 MCP 協定(Mesh Configuration Protocol) 同步 Pod 和 CR 資訊，避免 Citadel Agent 直接請求 API Server 導緻 API Server 負載過高；
• MOSN 通過 Unix Domain Socket 方式向 Citadel Agent 發起 SDS 請求；
• Citadel Agent 會進行防篡改校驗，并提取 appkey；
• Citadel Agent 攜帶 appkey 請求 Citadel 簽發證書；
• Citadel 檢查證書是否已緩存，如無證書，則向 KMS 申請簽發證書；
• KMS 會将簽發的證書響應回 Citadel，另外 KMS 也支援證書過期輪換通知；
• Citadel 收到證書後，會将證書層層傳遞，最終到達MOSN ；

國密通信

國密通信是基于 TLS 通信實作的，采用更複雜的加密套件來實作安全通信。該功能核心設計是由 Policy 和 Certificate 兩部分組成：

• Pilot 負責 Policy 的下發；
• Citadel 負責 Certificate 下發 （基于 SDS 證書方案）；

在落地過程中，僅依靠社群的 PERMISSIVE TLS MODE 還不能滿足螞蟻金服可灰階、可監控、可應急的三闆斧要求。是以在社群方案的基礎上，引入 Pod 粒度的 Sidecar 範圍選擇能力（也是基于 ScopeConfig ），方案基本如下圖所示：

流程如下：

• Pilot List/Watch ScopeConfig CRD 和 Policy CRD ，基于 Pod Label 選擇 Pod 粒度範圍執行個體；
• Provider 端 MOSN 收到 Pilot 下發的國密配置後，通過 SDS 方案獲驗證書，成功獲驗證書後，會将服務狀态推送至 SOFARegistry；
• SOFARegistry 通知 Consumer 端 MOSN 特定 Provider 端已開啟國密通信狀态，重新發起建連請求；

MCP 優化

Citadel Agent 通過 Citadel 去同步 POD 及 CRD 等資訊，雖然避免了 Node 粒度部署的 Citadel Agent 對 API Server 的壓力。但是使用 MCP 協定同步資料時，我們遇到了以下兩個挑戰：

1. 大叢集部署時，POD 數量在 10W 以上時，全量通信的話，每次需同步的資訊在 100M 以上，性能開銷巨大，網絡帶寬開銷也不可忽視；
2. Pod 和 CR 資訊變更頻繁，高頻的全量推送直接制約了可拓展性，同時效率極低；

為了解決以上兩個問題，就需要對 MCP 實作進行改造。改造的目标很明确，那就是減少同步資訊量，降低推送頻率。為此，我們強化了社群 MCP 的實作，補充了這些功能：

1. 為 MCP 協定支援增量資訊同步模式，性能大幅優于社群原生方案全量 MCP 同步方式；
2. Citadel Agent 是 Node 粒度元件，基于最小資訊可見集的想法，Citadel 在同步資訊給 Citadel Agent 時，通過 Host IP ，Pod 及 CR 上的 Label 篩選出最小集，僅推送每個 Citadel Agent 自身服務範圍的資訊；
3. 更進一步，基于 Pod 和 CR 的變更事件可以預先知道需要推送給哪些 Citadel Agent 執行個體，隻對感覺變更的Citadel Agent 觸發推送事件，即支援局部推送能力；

未來思考

本次大促的控制面的重心在于解決規模化問題，後續控制面将會在服務發現、精細化路由、Policy As Code 等領域深入探索。我們将與社群深度合作，控制面将支援通過 MCP 對接多種注冊中心（SOFARegistry（已開源）, Nacos等）進行服務發現資訊同步，解決大規模服務注冊發現問題，支援增量推送大量 endpoint。同時控制面還能通過增強配置下發能力，為應用啟動提速，将在 Serverless 極速啟動場景擷取技術紅利。控制面還将結合 Policy As Code，進而更具想象空間，具備極簡建站，預設安全等能力。

到此，本次分享的内容就結束了。Istio 生産級實踐機會難得，并且任重道遠。最後，歡迎有志之士加入我們，一起打造世界級規模的 Service Mesh。

• MOSN： https://github.com/sofastack/sofa-mosn
• SOFARegistry： https://github.com/sofastack/sofa-registry

作者簡介

本文作者：彭澤文（花名：封塵），螞蟻金服 Mesh 控制面主站負責人，主要 Focus 領域：Service Mesh（SOFAMosn、Istio）。

螞蟻金服 Service Mesh 大規模落地系列文章

• 螞蟻金服 Service Mesh 大規模落地系列 - Operator 篇
• 螞蟻金服 Service Mesh 大規模落地系列 - 網關篇
• 螞蟻金服 Service Mesh 大規模落地系列 - RPC 篇
• 螞蟻金服 Service Mesh 大規模落地系列 - 運維篇
• 螞蟻金服 Service Mesh 大規模落地系列 - 消息篇
• 螞蟻金服 Service Mesh 大規模落地系列 - 核心篇
• Service Mesh 落地負責人親述：螞蟻金服雙十一四大考題