本文根據螞蟻金服中間件SRE技術專家黃家琦（嘉祁）於 Service Mesh Meetup#9 杭州站上的分享整理。
背景
Service Mesh 在軟件形態上，是將中間件的能力從框架中剝離成獨立軟件。而在具體部署上，保守的做法是以獨立進程的方式與業務進程共同存在於業務容器內。螞蟻金服的做法是從開始就選擇了擁抱雲原生。
大規模落地的過程中，我們在看到 Service Mesh 帶來的巨大紅利的同時，也面臨過很多的挑戰。爲此，螞蟻金服配備了“豪華”的技術團隊陣容，除了熟悉的 SOFA 中間件團隊，還有安全、無線網關以及專門配備了專屬的 SRE 團隊，使得 MOSN 能力更加全面更加可靠。
今天我們詳細聊聊技術風險這個方面。對於一個新的中間件技術，在落地過程中總會面臨穩定性、運維模式變化等等很多的問題與挑戰，需要建設相應的技術風險能力，確保整個落地過程以及長期運行的穩定和可靠。
本次分享主要從以下三個方面展開：
- 落地過程中對於部署模式和資源分配的思考；
- 變更包括接入、升級的支持、問題與思考；
- 整個生產生命週期中穩定性面臨的挑戰與技術風險保障；
Sidecar 部署模式
業務容器內獨立進程的好處在於與傳統的部署模式兼容，易於快速上線；但獨立進程強侵入業務容器，對於鏡像化的容器更難於管理。而云原生化，則可以將 Service Mesh 本身的運維與業務容器解耦開來，實現中間件運維能力的下沉。在業務鏡像內，僅僅保留長期穩定的 Service Mesh 相關 JVM 參數，從而僅通過少量環境變量完成與 Service Mesh 的聯結。同時考慮到面向容器的運維模式的演進，接入 Service Mesh 還同時要求業務完成鏡像化，爲進一步的雲原生演進打下基礎。
優 劣
獨立進程 兼容傳統的部署模式 侵入業務容器
改造成本低 鏡像化難於運維
快速上線
Sidecar 面向終態 依賴 K8s 基礎設施
運維解耦 運維環境改造成本高
應用需要鏡像化改造
在接入 Service Mesh 之後，一個典型的 POD 結構可能包含多個 Sidecar：
- MOSN：RPC Mesh, MSG Mesh, ...（擴展中）；
- 其它 Sidecar；
MOSN：https://github.com/mosn/mosn
這些 Sidecar 容器與業務容器共享相同的網絡 Namespace，使得業務進程可以以本地端口訪問 Service Mesh 提供的服務，保證了與保守做法一致的體驗。
基礎設施雲原生支撐
我們也在基礎設施層面同步推進了面向雲原生的改造，以支撐 Service Mesh 的落地。
運維平臺模型支撐
首先是運維平臺需要能夠理解 Sidecar，支撐 Sidecar 模型的新增元數據，包括基於 POD 的 Sidecar 的多種標籤，以及 Sidecar 基線配置的支持。
業務全面鏡像化
其次我們在螞蟻金服內部推進了全面的鏡像化，我們完成了內部核心應用的全量容器的鏡像化改造。改造點包括：
- 基礎鏡像層面增加對於 Service Mesh 的環境變量支撐；
- 應用 Dockerfile 對於 Service Mesh 的適配；
- 推進解決了存量前後端分離管理的靜態文件的鏡像化改造；
- 推進了大量使用前端區塊分發的應用進行了推改拉的改造；
- 大批量的 VM 模式的容器升級與替換；
容器 POD 化
除了業務鏡像層面的改造，Sidecar 模式還需要業務容器全部跑在 POD 上，來適應多容器共享網絡。由於直接升級的開發和試錯成本很高，我們最終選擇將接入 Service Mesh 的 數百個應用的數萬個非 K8s 容器，通過大規模擴縮容的方式，全部更換成了 K8s PODs。
經過這兩輪改造，我們在基礎設施層面同步完成了面向雲原生的改造。
資源的演進
Sidecar 模式的帶來一個重要的問題，如何分配資源。
理想比例的假設獨佔資源模型
最初的資源設計基於內存無法超賣的現實。我們做了一個假設：
- MOSN 的基本資源佔用與業務選擇的規格同比例這一假設。
CPU 和 Memory 申請與業務容器相應比例的額外資源。這一比例最後設定在了 CPU 1/4，Memory 1/16。
此時一個典型 Pod 的資源分配如下圖示：
獨佔資源模型的問題
這一方式帶來了兩個問題：
- 螞蟻金服已經實現了業務資源的 Quota 管控，但 Sidecar 並不在業務容器內，Service Mesh 容器成爲了一個資源泄漏點；
- 業務很多樣，部分高流量應用的 Service Mesh 容器出現了嚴重的內存不足和 OOM 情況；
共享資源模型
討論之後，我們追加了一個假設：
- Service Mesh 容器佔用的資源實質是在接入 Service Mesh 之前業務已使用的資源。接入 Service Mesh 的過程，同時也是一次資源置換。
基於這個假設，推進了調度層面支持 POD 內的資源超賣，新的資源分配方案如下圖，Service Mesh 容器的 CPU、MEM 都從 POD 中超賣出來，業務容器內仍然可以看到全部的資源。
考慮到內存超賣也引入了 POD OOM 的風險，因此對於 Sidecar 容器還調整了 OOM Score，保證在內存不足時，Service Mesh 進程能夠發揮啓動比 Java 業務進程更快的優勢，降低影響。
新的分配方案解決了同時解決了以上兩個問題，並且平穩支持了螞蟻金服的雙十一大促。
變更-Service Mesh 是如何在螞蟻金服內部做變更的
Service Mesh 的變更包括了接入與升級，所有變更底層都是由 Operator 組件來接受上層寫入到 POD annotation 上的標識，對相應 POD Spec 進行修改來完成，這是典型的雲原生的方式。
接入-從無至有
標準的雲原生的接入方式，是在創建時通過 sidecar-operator webhook 注入一個 Sidecar 容器。
這個方式的固有缺陷在於：
- 滾動替換過程需要 Buffer 資源；
- 過程緩慢；
- 回滾慢，應急時間長；
原地接入
原地接入是爲了支撐大規模的快速接入與回滾，通過在存量的 POD 上操作修改 POD Spec。
- 不需要重新分配資源；
- 可原地回滾；
升級
Service Mesh 是深度參與業務流量的，最初的 Sidecar 的升級方式也需要業務伴隨重啓。
帶流量的平滑升級
爲了規避 Java 應用重啓帶來的重新預熱等問題，MOSN 提供了更爲靈活的平滑升級機制：由 Operator 控制啓動第二個 MOSN Sidecar，完成連接遷移，再退出舊的 Sidecar。整個過程業務可以做到流量不中斷，幾近無感。
變更能力的取捨
雖然提供了原地接入與平滑升級，但從實踐的效果來看，對存量 POD spec 的修改帶來的問題，比收益要多得多。
創建時注入/普通升級
原地注入/平滑升級
- 不改變現存 POD spec
- 改變現存 POD
- 資源預分配，不影響調度
- 邏輯簡單，成功率高
- 與原有業務升級邏輯一致
- 變更簡單完全可逆
- 資源分配需要重新計算，細節多易出錯
- 邏輯複雜成功率與效率不佳
- 強依賴 operator，不易觀測
- 逆變更需要反向重新計算，難度高
- 接入需要替換資源
- 升級需要中斷業務
- 接入不需要額外資源
- 升級時業務無感
最終我們在生產環境放棄了相應的能力，而依賴於更靈活高效的調度層與變更流程來解決接入與升級中的問題。
變更流程支撐
我們建設了完整的 Service Mesh 變更流程來支撐全站規模的接入與升級的變更動作。整體變更按照環境-IDC 多維度分組，結合全程變更管控，確保變更過程平穩、可控。
全程變更管控
全程變更管控提供了不限於以下幾方面的能力：
- 強制灰度/分批流程；
- 前後置業務自動巡檢；
- 變更完整性校驗；
其中業務自動巡檢，提供了在每個分組變更前自動處理參數檢查，衝突規避，容量檢查等，和變更後基於算法與規則匹配的業務檢查的能力，變更完整度檢查等，保障規模變更穩定可靠。
控制面的變更
控制面的實際上面臨所有使用 Deployment、daemonset 等雲原生部署方式相同的問題，即無法回答：
- 如何控制灰度範圍；
- 當前的進度如何；
總體來說，我們在向類似 CafeDeployment 的解決方案靠近來解決這類通用問題。
技術風險建設-我們如何保障 Service Mesh 的生產穩定
監控與定位能力
Service Mesh 爲監控與定位提供的數據包括：
- Metrics：實時的業務統計數據；
- 錯誤碼：Service Mesh 的運行時的分類錯誤日誌；
- 業務監控：tracing與業務錯誤日誌；
基於這些數據，我們期望回答三個問題：
- 是否是 Service Mesh 的問題；
- 哪個 Service Mesh 組件的問題；
- 如何處理出現的問題；
從這三個問題出發，我們的監控平臺爲 Service Mesh 提供了全局的 Service Mesh 大盤和業務視圖的 Service Mesh 視圖，在其中提供錯誤碼聚合與 Metrics 數據，展示各指標的 Top 視角。
基於這樣的數據聚合能力，在最上層提供基於 Tracing 定位與監控數據的 chat ops 定位能力，最終來回答這三個問題。
基於全局大盤的數據，我們得以在落地過程中發現並定位了某些業務場景下出現的連接問題。
仍面臨的問題
雖然已經有了很多的數據聚合，但在定位上，還面臨一些挑戰：
- 模塊啓用在不同應用存在差異，錯誤碼聚合效果有偏差；
- 報警閾值對應於不同應用存在差異；
- 集羣規模極大帶來了極大的噪聲；
這些問題說明單一維度的指標與低階的閾值已經無法適應我們的業務與問題發現的要求了，定位能力需要向多維度，高階標準方向進化。
預案與應急能力
Service Mesh 自身具備按需關閉部分功能的能力，包括但不限於：
- 日誌分級降級；
- Tracelog 日誌分級降級；
- 控制面(Pilot)依賴降級；
- 軟負載均衡長輪詢降級；
對於 Service Mesh 依賴的服務，爲了防止潛在的抖動風險，也增加了相應的預案：
- 軟負載均衡列表停止變更；
- 服務註冊中心高峯期關閉推送；
Service Mesh 是非常基礎的組件，目前的應急手段主要是重啓：
- Sidecar 單獨重啓；
- POD 重啓；
自愈
基於以上的預案與應急手段，結合現存的監控與定位能力，我們在 Service Mesh 實現了多種場景下的自愈，極大加快了已知場景的處理響應。
攻擊能力
攻擊能力主要指兩個層面：
- 對Service Mesh本身的攻擊演練能力
- 在Service Mesh中提供細粒度的業務攻擊服務
一方面是常態化驗證 Service Mesh 自身的穩定性，另一方面則對於全站層面的技術風險能力的深入提供基礎能力。
未來
Service Mesh 在快速落地的過程中，遇到並解決了一系列的問題，但同時也要看到還有更多的問題還亟待解決。做爲下一代雲原生化中間件的核心組件之一，Service Mesh 的技術風險能力還需要持續的建議與完善。未來需要在下面這些方面持續建設：
- 高度自愈能力；
- 更精準的變更防控能力與規模化高度無人值守變更能力；
- 精確智能化定位能力；
- 更高效，低噪聲的高精度監控；
歡迎有志於中間件 Service Mesh 化與雲原生穩定性的同學加入我們，共同建設 Service Mesh 的未來。
作者介紹
黃家琦（花名：嘉祁）2012年畢業後加入阿里巴巴技術保障，2015年轉入螞蟻金服SRE，長期從事穩定性相關工作，當前重點關注於中間件，Service Mesh 與雲原生基礎設施的穩定性。
本期回顧視頻以及分享 PPT 查看地址
https://tech.antfin.com/community/activities/1056/review/966
關於 Service Mesh Meetup
本期是 Service Mesh Meetup 第9期杭州站，2018年4月杭州的第一期 Service Mesh Meetup 開啓了 ServiceMesher 社區的全國技術交流之旅，至今已經快2年了，我們走過了北京、上海、深圳、廣州、成都、杭州等六座城市，累計舉辦9期線下活動。
同時，感謝滴滴、華爲、網易、酷家樂、中興通訊、美團、唯品會、七牛、諧雲科技、慧擇網、虎牙、才雲、京東、新浪微博、聯邦車網、JEX、Apache SkyWalking、知羣等公司的支持，參與技術分享、共同組織活動。
2020年，社區希望走到更多的城市，與更多對 Service Mesh 感興趣的技術同學們交流、探討想法。
We are ServiceMesher! May the Mesh be with you!
ServiceMesher：https://www.servicemesher.com/