數據面質量
服務網格（Service Mesh） 包含了控制面和數據面，其中，數據面為自研的 MOSN。本文介紹 Service Mesh 數據面 MOSN 在螞蟻集團的落地過程中，如何進行質量保障，以及如何確保從現有的微服務體系平滑演進至 Service Mesh 架構。
MOSN 簡介
經典微服務架構和 Service Mesh 架構的差別主要包括：
經典微服務體系：基于 SDK 實現服務的注冊和發現。
Service Mesh 體系：基于數據面 MOSN 實現服務的注冊和發現，且服務調用也通過 MOSN 來完成。
經典微服務架構
Service Mesh 微服務架構
在 ServiceMesh 體系下，原先的 SDK 邏輯下沉至數據面 MOSN 中，會帶來如下優點：
基礎能力下沉后，基礎能力的升級不再依賴應用的改造和發布，降低應用打擾率。
基礎能力升級后，可快速迭代并鋪開，對應用無感。
螞蟻集團自研數據面 MOSN 具備的能力：
落地面臨的問題
MOSN 具備豐富的能力，在落地過程中，也面臨下述幾個問題：
在質量保障上有哪些挑戰？
如何應對質保挑戰？
在質量保障上有哪些挑戰？
新產品：螞蟻團隊并沒有采用社區方案 Envoy 或 Linkerd，而是選擇自研數據面 MOSN。從底層的網絡模型，到上層的業務模塊，全部需要研發重新編碼來實現，并作為基礎設施，去替代線上運行穩定的 SDK。這種線上變更的風險很高。
非標語言：這套自研的數據面 MOSN，采用的是 Golang 語言。螞蟻集團內部的技術棧主要是 Java，相應的研發流程也是圍繞著 Java 來構建。這套新引入的技術棧，需要新的流程平臺來支撐。
大促：從螞蟻集團內部著手基礎設施升級開始到雙十一來臨，時間短，任務重。完成核心鏈路應用的全部 Mesh 化，涉及應用數量達 100 多個，涉及 Pod 達數十萬多個，還需要經受住雙十一大促考驗。
線上穩定性：在升級過程中，要求對業務無損，大規模升級完成后，業務能正常運行。
輸出站點：包括螞蟻集團、網商銀行和公有云。但是，3 個站點所依賴的基礎設施和所要求的能力，存在差異，這些不同能力要求會造成代碼分支碎片化。因此需要考慮下述 2 個問題。
如何同時保障多站點輸出的質量？
如何管理好這些碎片化分支？
如何應對質保挑戰？
規范研發流程
在推進 Mesh 化落地時，螞蟻集團內部的研發效能部開始推出 ANT CODE 研發平臺，其支持 Golang 語言，提供自定義流水線編排能力和部分原生插件?；谠撈脚_，螞蟻團隊對研發過程做了如下規范：
git-flow 分支管控
代碼管理需要一個清晰的流程和規范，螞蟻團隊引入了 Vincent Driessen 提出的代碼管理解決方案。詳情請參見 A Successful Git Branching Model。
代碼審查（CR）：從現有的質量保障手段來看，Code Review（CR） 是低成本發現問題的有效方式，基于 ANT CODE 平臺，螞蟻團隊定義了下述 CR 規范。
交付流水線：以 MOSN 持續交付流水線為例，圖示如下。
流水線卡點
上述任一步驟執行失敗，整個流水線將會失敗，代碼將無法合并。
卡點規則在工程根目錄的 YAML 配置文件中。通過自定義插件統一收口這些卡點規則，精簡了工程根目錄的 YAML 配置文件，也使得規則的變更只需更新插件的內存配置即可。
集成測試
為了驗證 MOSN，螞蟻團隊搭建了一套完整的測試環境。這里以 MOSN 中的 RPC 功能為例，闡述這套環境的構成要素及環境部署架構。
集成測試環境構成要素
集成測試環境優缺點：
優點：
MOSN 中的路由能力，完全兼容原先 SDK 中的能力，且在其基礎上不斷優化，如通過路由緩存提升性能等。
依托于這套環境做集成測試，可完成自動化腳本編寫，并在迭代中持續集成。
缺點：這套測試環境，并不能發現所有的問題，有一些問題會遺留到線上，并給業務帶來干擾。
下文以 RPC 路由為例，闡述對線下集成測試的一些思考。
業務在做跨 IDC 路由時，主要通過 ANTVIP 實現，這就需要業務在自己的代碼中設置 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，這種配置是不合法的。 因為歷史原因，這種場景在原先的 CE（Cloud Engine） 中做了兼容，而在 MOSN 中未繼續這種兼容。
這類歷史遺留問題，在多數產品里都會遇到，可以歸為測試場景分析遺漏。一般對于這種場景，可以借助于線上流量回放的能力，將線上的真實流量復制到線下，作為測試場景的補充。但現有的流量回放能力，并不能直接用于 MOSN，原因在于 RPC 的路由尋址與部署結構有關，線上的流量并不能夠在線下直接運行，因此需要一套新的流量回放解決方案。目前，這部分能力還在建設中。
專項測試
除了上述功能測試之外，螞蟻團隊還引入了如下專項測試：
兼容性測試
性能測試
故障注入測試
兼容性測試
MOSN 兼容性驗證圖
發現的問題：通過兼容性測試，發現問題主要集中在 接入/未接入MOSN 這個場景中。
例如，在線下驗證過程中，接入了 MOSN 的客戶端調用未接入 MOSN 的服務端會偶發失敗，服務端會有如下協議解析報錯：
[SocketAcceptorIoProcessor-1.1]Error com.taobao.remoting -Decode meetexception
java.io.IOException:Invalid protocol header:1經分析，原因在于老版本 RPC 支持 TR 協議，后續的新版支持 BOLT 協議，應用升級過程中，存在同時提供 TR 協議和 BOLT 協議服務的情況，即相同接口提供不同協議的服務，示例如下：
配圖說明：
應用向 MOSN 發布服務訂閱的請求，MOSN 向配置中心訂閱，配置中心返回給 MOSN 兩個地址，分別支持 TR 和 BOLT，MOSN 從兩個地址中選出一個返回給應用 APP。
MOSN 返回給 APP 的地址是直接取配置中心返回的第一條數據，有下述 2 種可能：
地址是支持 BOLT 協議的服務端：后續應用發起服調用時，會直接以 BOLT 協議請求 MOSN，MOSN 選址時，會輪詢兩個服務提供方，如果調用到 Server1，就出現了上述協議不支持的報錯。
地址是支持 TR 協議的服務端：因 BOLT 對 TR 做了兼容，因而不會出現上述問題。
修復方案：最終的修復方案是，MOSN 收到配置中心的地址列表后，會做一層過濾，只要服務端列表中包含 TR 協議的，則全部降級到 TR 協議。
性能測試
為了驗證業務接入 MOSN 后的性能影響，螞蟻團隊將業務的性能壓測環境應用接入 MOSN，并使用業務的壓測流量做驗證。下述為業務接入 MOSN 后的性能對比圖：
故障注入測試
從 MOSN 的視角來看，其外部依賴如下：
除了驗證 MOSN 自身的功能外，螞蟻團隊還通過故障注入的方式，對 MOSN 的外部依賴做了專項測試。通過這種方式發現了一些上述功能測試未覆蓋的場景。
下文以應用和 MOSN 之間的 12199 端口為例，進行說明。
MOSN 與 APP 心跳斷連處理示意圖
配圖說明：
應用 APP 接入 MOSN 后，原先應用對外提供的 12200 端口改由 MOSN 去監聽，應用的端口修改為 12199，MOSN 會向應用的 12199 端口發送心跳，檢測應用是否存活。
如果應用運行過程中出現問題，MOSN 可以通過心跳的方式及時感知到。
如果 MOSN 感知到心跳異常后，會向配置中心取消服務注冊，同時關閉對外提供的 12200 端口服務。這樣做的目的是防止服務端出現問題后，仍收到客戶端的服務調用，導致請求失敗。
為了驗證該場景，螞蟻團隊在線下測試環境中，通過 iptables 命令 drop 掉 APP 返回給 MOSN 的響應數據，人為制造應用 APP 異常的場景。通過這種方式，螞蟻團隊也發現了一些其它不符合預期的 bug，并修復完成。
快速迭代
從項目立項到雙十一，留給整個項目組的時間并不充裕，為了確保雙十一能夠平穩過度，螞蟻團隊采取的策略是：在質量可控范圍內，通過快速迭代，讓 MOSN 在線上能夠獲得充分的時間做驗證。這離不開上述基礎測試能力的建設，同時也依賴螞蟻集團線上變更三板斧原則。
線上壓測及演練
MOSN 全部上線之后，跟隨著業務一起，由業務的 SRE（Site Reliability Engineer ） 觸發多輪的線上壓測，以此發現更多的問題。線上演練，主要是針對 MOSN 自身的應急預案的演練，如線上 MOSN 日志降級等。
監控及巡檢
在 Mesh 化之前，線上的監控主要是整個 POD 級別的監控；Mesh 化之后，在監控團隊的配合下，線上監控支持了 MOSN 的獨立監控，以及 POD 中 Sidecar 與 APP 容器的監控。
巡檢是對監控的補充，部分信息無法通過監控直接獲取，如 MOSN 版本的一致性。通過巡檢可以發現，哪些 POD 的 MOSN 版本還沒有升級到最新，是否存在有問題的版本還在線上運行的情況等。
未來如何完善產品？
通過雙十一，Service Mesh 更多是在性能和線上穩定性方面給出了證明，但技術風險底盤依然不夠穩固。接下來，除了建設新功能外，螞蟻團隊還會在技術風險領域做更多的建設。在質量這塊，主要包括：
在這個過程中，螞蟻團隊期望能夠引入一些新的測試技術，能夠有一些新的質量創新，以便把 Service Mesh 做的越來越好。