螞蟻金服 Service Mesh 大規模落地系列 - 質量篇

時間 2021-05-25

原文原文鏈接

本文爲《螞蟻金服 Service Mesh 大規模落地系列》最後一篇 - 質量篇，該系列從核心、RPC、消息、無線網關、控制面、安全、運維、測試等模塊對 Service Mesh 雙十一大規模落地實踐進行詳細解析。文末包含往期系列文章。跨域

前言

Service Mesh 在螞蟻金服內部已經大規模落地，經歷剛剛雙十一的檢閱，將現有的體系快速演進至 Service Mesh 架構，無異於給飛機換髮動機。本主題主要分享在螞蟻金服當前的體量下，咱們如何作到給飛機換髮動機，還確保不出問題。同時在mesh對外客戶輸出一樣有高質量的保障。安全

本文結合螞蟻金服 Mesh 化落地質量保障落地的思考，給你們帶來以下三個方面的一些質量保障的分享：架構

Mesh 化質量保障體系；
Mesh 化測試技術；
Mesh 化雙十一大規模落地的性能保障；

質量保障體系

首先給你們介紹下咱們的質量保障體系。併發

測試保障體系框架

咱們從測試環境、測試用例、基礎功能測試原子鏡像能力、測試工具平臺、測試場景組合調度、測試方案制定、線上巡檢監控、灰度發佈三板斧、交付驗證、性能、自動化測試等多個方面進行系統性測試保障。經過內外部的質量數據度量和雙十一大促來檢閱咱們的質量能力。運維

Mesh 測試技術

在開始介紹測試技術以前，咱們先了解一下什麼是 Service Mesh 以及 Service Mesh 是如何工做的，在螞蟻金服的技術架構中是以什麼形式存在，發揮着怎樣的做用。ide

簡單的說 Service Mesh 存在兩個面，一個面叫數據面（好比 MOSN），就是處理應用數據請求的一個獨立代理模塊，脫離於應用，爲應用提供請求代理及一些複雜通訊邏輯處理，另一個叫控制面（好比 SOFAMesh），管理應用配置及業務規則等（好比業務開關/服務路由規則），經過下發配置「指揮」數據面去執行，知足不一樣階段實現不一樣的業務支持。函數

Mesh 框架簡圖微服務

咱們先簡單介紹下經典微服務請求路由。工具

經典微服務模式請求路由

經典微服務模式下 Docker 鏡像化服務在一個 Pod 通常只有一個業務應用容器在運行，這種狀況下測試框架只要關心業務應用便可。

經典微服務測試架構

Mesh 測試架構改進

Mesh 測試架構在經典微服務測試架構上也作了新的演進。MOSN 做爲 Sidecar 與業務容器共存在一個 Pod，資源與業務應用容器共享，每一個業務邏輯都須要經過 MOSN 去處理，於是只關心業務應用確定不夠，須要再擴展支持到 MOSN 這類 Sidecar 的測試驗證。在 MOSN 中集成了控制面 xds client，與控制面 pilot 創建通訊，用於接收 pilot 下發的配置信息。在螞蟻金服技術架構存在三地五中心/同城雙活等容災能力，於是產生了 LDC，一個集羣多個 zone 狀況，控制面 pilot下發是能夠配置集羣+zone+應用+ip 組合粒度，要驗證這個多 zone 下發規則準確性，那就須要建立多個 xds client（或者 MOSN）。另外 Sidecar 是不能直接訪問的，經過測試應用暴露出接口，給上層測試。

Mesh 化測試架構

構建高仿真測試環境

那麼，咱們測試環境要作到足夠仿真，面臨哪些挑戰呢？首先看下咱們自研的 MOSN 具有的能力和技術複雜性。

MOSN 能力大圖

應對 MOSN 測試場景複雜性，咱們搭建了一套高仿真測試環境，這裏以 MOSN 中的 RPC 功能爲例，闡述這套環境的構成要素及環境部署架構。

集成測試環境構成要素

這裏能夠舉一個 RPC 路由的例子來詳細講述。咱們知道，業務在作跨 IDC 路由時，主要經過跨域 VIP 實現，這就須要業務在本身的代碼中設置 VIP 地址，例如：

<sofa:reference interface="com.alipay.APPNAME.facade.SampleService" id="sampleRpcService">
        <sofa:binding.tr>
            <sofa:vip url="APPNAME-pool.zone.alipay.net:12200"/>
        </sofa:binding.tr>
    </sofa:reference>

這時候假如業務配置了不合法的 URL，如：

<sofa:reference interface="com.alipay.APPNAME.facade.SampleService" id="sampleRpcService">
        <sofa:binding.tr>
            <sofa:vip url="http://APPNAME-pool.zone.alipay.net:12200?_TIMEOUT=3000"/>
        </sofa:binding.tr>
    </sofa:reference>

上述 VIP URL 指定了 12200 端口，卻又同時指定了 http，這種配置是不合法的，就會出現問題，這時候測試環境就須要跨 zone、跨 LDC 的測試環境。咱們在多數複雜產品測試裏都會遇到，極度複雜測試場景沒法 100% 分析充分。通常對於這種場景，咱們能夠藉助於線上流量回放的能力，將線上的真實流量複製到線下，做爲咱們測試場景的補充。這也須要很是仿真的測試環境作 MOSN 的流量回放支撐。

兼容性測試

MOSN 兼容性驗證

咱們經過一個例子來詳細闡述：老版本的 RPC 中咱們支持 TR 協議，後續的新版支持 BOLT 協議，應用升級過程當中，存在同時提供 TR 協議和 BOLT 協議服務的狀況，以下圖：

應用升級過程當中，相同接口提供不一樣協議的服務

首先，應用向 MOSN 發佈服務訂閱的請求，MOSN 向配置中心訂閱，配置中心返回給 MOSN 兩個地址，分別支持 TR 和 BOLT，MOSN 從兩個地址中選出一個返回給應用 APP。

這裏兼容性風險是：MOSN 返回給 APP 的地址是直接取配置中心返回的第一條數據，這裏多是 TR 也多是 BOLT。

若是 MOSN 返回給應用的地址是支持 BOLT 協議的服務端，那麼後續應用發起服調用時，會直接以 BOLT 協議請求 MOSN，MOSN 選址時，會以輪詢的方式兩個服務提供方，若是調用到 Server1，就會出現協議不支持的報錯。
所以咱們針對各類兼容性具體場景都要作好分析和相應的測試。

MOSN 的魯棒測試（穩定性、健壯性）

從 MOSN 的視角來看，其外部依賴以下：

MOSN 外部依賴圖

除了驗證 MOSN 自身的功能外，咱們還經過故障注入的方式，對 MOSN 的外部依賴作了專項測試。經過這種方式，咱們發現了一些上述功能測試未覆蓋的場景，這裏以應用和 MOSN 之間的 12199 端口舉例。

應用 APP 接入 MOSN 後，原先應用對外提供的 12200 端口改由 MOSN 去監聽，應用的端口修改成 12199，MOSN 會嚮應用的 12199 端口發送心跳，檢測應用是否存活。

若是應用運行過程當中出現問題，MOSN 能夠經過心跳的方式及時感知到。

MOSN 與 APP 心跳斷連處理示意圖

如圖所示，若是 MOSN 感知到心跳異常後，會向配置中心取消服務註冊，同時關閉對外提供的 12200 端口服務。這樣作的目的是防止服務端出現問題後，仍收到客戶端的服務調用，致使請求失敗。

測試該場景，咱們經過自動化故障注入系統 drop 掉 APP 返回給 MOSN 的響應數據，人爲製造應用 APP 異常的場景。經過這種方式，自動對比指望結果，判斷是否異常，後自動進行故障恢復，繼續下一個故障注入測試。

Service Mesh 雙十一大規模落地的性能保障

Mesh 在落地過程當中首先遇到的問題就是，螞蟻金服如此大致量下，如何不出性能問題。MOSN 從能力上集成了中間件多種能力，所以線下壓測比較複雜，在線上全鏈路壓測開始以前，線下咱們基於中間件的壓測能力作了一輪自身的壓測，上線後從業務角度再作全鏈路壓測，問題就會少不少，螞蟻全鏈路壓測部分，是很是成熟的技術，各類材料也介紹過屢次，相信你們都已經很是熟悉。螞蟻金服中間件線下壓測部分介紹比較少，所以我總結概括給你們介紹下，以下圖：

舉個控制面 gc 壓測分析的例子：

CRD 下發能力是控制面核心，加密通訊也是基於 CRD 下發開關觸發，而下發的關鍵性能點在於如下幾個因素：

pilot 支持的 client 併發數；
另外對配置下發實時性比較高，於是配置下發到 client 的耗時也是重要指標；

在壓測過程當中，沒有足夠資源來建立那麼多 xds client，於是開發了 mock client（簡化版 xds client），只保留核心通訊模塊，單 pod 能夠支持萬級的 client 模擬。在持續壓測一段時間，咱們發現內存頻繁在 GC，致使耗時很高，pprof 分析內存。

MessageToStruct 和 FromJsonMap 最佔內存，都是在對數據進行轉換，MessageToStruct 以前有過同類優化，所以很快解決，可是 CRD 數據轉換的核心 FromJsonMap，須要將數據轉成 K8s 能識別的 yaml 信息。咱們進行了改造，將一部份內存進行重用，並優化轉換函數，耗時降低了好幾倍，降到了毫秒級別。