控制面質量
最近幾年，云原生概念越來越火，螞蟻集團歷來熱衷于技術創(chuàng)新，積極在云原生領域實踐 Service Mesh 理念，結合現有技術架構，將一些通用能力（通信/數據/安全等）抽離出來，沉淀出了 MOSN。同時，依托于 Istio 的能力，擴展出了 Service Mesh 控制面，為 MOSN 提供上層的管控能力。本文主要介紹 Service Mesh 控制面在螞蟻集團落地過程中，我們如何提供可靠的質量保障。
主要內容分為下面幾個方面：
Service Mesh 組成
Service Mesh 組成圖
Service Mesh 組成說明：
數據面：稱為 MOSN，是處理應用數據請求的一個獨立代理模塊，脫離于應用，為應用提供請求代理及一些復雜通信邏輯處理。
控制面：稱為 SOFAMesh，管理應用配置及業(yè)務規(guī)則等（例如業(yè)務開關、服務路由規(guī)則），通過下發(fā)配置，“指揮”數據面去執(zhí)行，滿足不同階段不同實現的業(yè)務支持。
控制面與經典微服務的差異
經典微服務形態(tài)
Service Mesh 融入形態(tài)
2 者區(qū)別主要為下述幾個方面：
Service Mesh 在數據面 Pod 中額外增加了 Mosn。
Service Mesh 取消了 Config Server，由 Service Mesh 控制面處理 Mosn 推送的配置數據。而經典微服務通過 Config Server 來推送配置數據。
Service Mesh 控制面落地
Service Mesh 控制面，在 Kubenates 基礎上對上層提供 CRD/RBAC 等操作能力；并在開源 Istio 的 Envoy 基礎上，通過 xDS 協(xié)議擴展業(yè)務信息，支持將 “服務路由規(guī)則/配置開關” 等下發(fā)到 MOSN，讓 MOSN 去執(zhí)行，以滿足不同業(yè)務需求。在雙十一活動中，控制面落地了下述 2 個能力：
CRD 配置下發(fā)：CRD 指 Custom Resource Definitions，是 K8s 原生支持的自定義資源語義。
TLS 加密通信：TLS 指 Transport Layer Security。
CRD 配置下發(fā)
螞蟻集團擴展出了 ScopeConfig 來限定 CR（Custom Resource） 生效的范圍，支持機房/集群/應用/IP 等級別設置，在 ScopeConfig 基礎上增加了一些 PilocyConfig CRD（策略/規(guī)則/開關等），這樣可以實現線上灰度可控/降級回滾能力及一些 A/B TEST。
TLS 加密通信
TLS 加密通信實現過程：
在開啟 TLS 開關后，MOSN 通過 UDS（Unified Diagnostic Services） 向控制面的 Citadel Agent 獲取 TLS 證書信息。
TLS 證書由螞蟻集團自身安全證書服務 KMS 授權給控制面 Citadel 服務，Citadel 會做一些證書檢測等處理。
將校驗通過的證書同步給 Citadel Agent，依次循環(huán)實現證書流轉更新。
TLS 加密通信過程示例
挑戰(zhàn)及應對
測試架構改進
標準模式下， 在一個 Pod 中，Docker 鏡像化服務一般只有一個業(yè)務應用容器在運行，這種情況下測試框架只要關心業(yè)務應用即可。
Service Mesh 是一種非標準模式。MOSN 作為 Sidecar，與業(yè)務容器共存于一個 Pod 中，資源與業(yè)務應用容器共享。每個業(yè)務邏輯都需要通過 MOSN 去處理，因而不能只關心業(yè)務，需要將測試驗證擴展到 MOSN。
MOSN 集成了控制面 xds Client，與控制面 Pilot 建立通信，用于接收 Pilot 下發(fā)的配置信息。螞蟻集團技術架構有 “三地五中心/同城雙活”等容災能力，因而產生了 LDC、一個集群多個 Zone 等情況。
控制面 Pilot 下發(fā)，配置粒度可以為集群 + Zone + 應用 + IP，要驗證這種多 Zone 下發(fā)規(guī)則的準確性，需要創(chuàng)建多個 xds Client（或者 MOSN）。
Sidecar 不能直接訪問，需要通過測試應用暴露出接口，給上層測試。
代碼質量管控
新工程新代碼，在快速迭代同時，還需要保證代碼質量。控制面幾乎全部由 Go 語言開發(fā)，不像標準開發(fā)語言 Java 一樣有非常豐富的組件支持，因而在度量時沒有豐富的質量指標。
借助螞蟻集團效能團隊的 Ant Code 服務，螞蟻團隊配置了適合 ServiceMesh 控制面的流水線，目前可以支持安全掃描/規(guī)范掃描/代碼覆蓋率等，也支持 Code Review，只有研發(fā)/質量 Review 通過，才能合并代碼，而且在合并時會自動觸發(fā)執(zhí)行 UT（Unit Test），避免異常代碼合入。
鏡像統(tǒng)一化打包，Review 通過和 UT 通過之后，會自動構建測試鏡像包，提升測試包質量，示例如下。
在 Ant Code 基礎上，螞蟻團隊開發(fā)了自定義組件，動態(tài)管控代碼覆蓋率，不斷提升代碼研發(fā)質量，加強研發(fā)自測意識。
穩(wěn)定性要求
CRD 下發(fā)能力是控制面核心，TLS 加密通信也是基于 CRD 下發(fā)開關觸發(fā)，而下發(fā)的關鍵性能點在于以下幾個因素：
Pilot 支持的 Client 并發(fā)數。
下發(fā)到 Client 的耗時：因為對配置下發(fā)實時性要求比較高。
在壓測過程中，由于沒有足夠資源用來創(chuàng)建很多 XDS Client，因而開發(fā)了 Mock Client（簡化版 XDS Client），只保留核心通信模塊，單 Pod 可以支持萬級的 Client 模擬。在持續(xù)壓測一段時間后，螞蟻團隊發(fā)現內存頻繁在 GC，導致耗時很高。
PProf 內存分析圖
PProf內存分析圖說明：
MessageToStruct 和 FromJsonMap 最占內存，都是在對數據進行轉換。
MessageToStruct 之前有過同類優(yōu)化，因此可以很快解決。
FromJsonMap：是 CRD 數據轉換的核心 ，需要將數據轉成 K8s 能識別的 YAML 信息。螞蟻團隊對此進行改造，將一部分內存進行重用，并優(yōu)化轉換函數，耗時下降好幾倍，降到毫秒級別。
運維管控
控制面服務基于 K8s 開發(fā)，以 Deployment 和 Daemonset 形式發(fā)布上線，每次發(fā)布都會影響到整個集群，需要一定風險把控手段。
依靠 Ant code 的代碼 Review 機制，螞蟻團隊建立了研發(fā)、質量、SRE 三方評審機制，管控變更范圍。評審完成后自動部署到對應集群，通過監(jiān)控秒級巡檢，發(fā)現問題可以及時告警，共同保障了線上生產質量。
未來規(guī)劃
