作者：宋順
來源：金融級分佈式架構公眾號
雲原生的理念正如火如荼，然而真正大規模落地的公司依然屈指可數，螞蟻作為國內比較早進行嘗試的公司，經過了 2 年多的探索，沉澱出了一套切實可行的方案並最終通過了雙十一的考驗。
本文主要分享我們在 Service Mesh 大規模落地過程中的一些經驗、社區好消息以及對未來的思考，希望能給大家帶來一些啟發。
一、為什麼需要 Service Mesh?
我們為什麼需要Service Mesh，它對業務的價值在哪裡，我們總結了三點：
- 微服務治理與業務邏輯解耦。
- 異構系統的統一治理。
- 金融級的網絡安全。
下面分別進行闡述。
1. 微服務治理與業務邏輯解耦
在 Service Mesh 之前，傳統微服務體系的玩法都是由中間件團隊提供一個 SDK 給業務應用使用，在 SDK 中會實現各種服務治理的能力，如：服務發現、負載均衡、熔斷限流、服務路由等。
在運行時，SDK 和業務應用的代碼其實是混合在一個進程中運行的，耦合度非常高，這就帶來了一系列的問題：
- 升級成本高。每次升級都需要業務應用修改 SDK 版本號，重新發布。以螞蟻為例，以往每年我們在中間件版本升級上就需要耗費數千人日。
- 版本碎片化嚴重。由於升級成本高，但中間件還是會持續向前發展，久而久之，就會導致線上 SDK 版本各不統一、能力參差不齊，造成很難統一治理。
- 中間件演進困難。由於版本碎片化嚴重，所以中間件向前演進過程中就需要在代碼中去兼容各種各樣的老版本邏輯，就像是戴著『枷鎖』前行，無法實現快速迭代。
有了 Service Mesh 之後，我們就可以把 SDK 中的大部分能力從應用中剝離出來，拆解為獨立進程，以 Sidecar 的模式運行。通過將服務治理能力下沉到基礎設施，可以讓業務更加專注於業務邏輯，而中間件團隊則更加專注於各種通用能力建設，真正實現獨立演進，透明升級，提升整體效率。
2. 異構系統統一治理
隨著新技術的發展，在同一家公司中往往也會出現使用各種不同語言、不同框架的應用和服務。以螞蟻為例，內部業務也是百花齊放，有前端、搜索推薦、人工智能、安全等各種業務，它們使用到的技術棧也非常多樣化，除了Java 以外，還有 NodeJS、Golang、Python、C++ 等，為了能夠統一管控這些服務，我們要為每種語言、每種框架都重新開發一套完整的 SDK，維護成本非常高，而且對我們的人員結構也帶來了很大的挑戰。
有了 Service Mesh 之後，通過將主體的服務治理能力下沉到基礎設施，多語言的支持就輕鬆很多了，只需要提供一個非常輕量的 SDK、甚至很多情況都不需要一個單獨的 SDK，就可以方便地實現多語言、多協議的統一流量控制、監控等治理需求。
3. 金融級網絡安全
當前很多公司的微服務體系建設都建立在『內網可信』的假設之上，然而這個假設在當前大規模上雲的背景下可能不再合適，尤其是涉及到一些金融場景的時候。
通過 Service Mesh，我們可以更方便地實現應用的身份標識和訪問控制，輔之以數據加密，就能實現全鏈路可信，從而使得服務可以運行於零信任網絡中，提升整體安全水位。
二、螞蟻 Service Mesh 大規模落地實踐
正因為 Service Mesh 帶來了上述種種的好處，所以我們從 2018 年初就開始了技術探索並進行了小規模的落地試點，然而初期在和業務團隊推廣時，卻面臨了靈魂拷問：
1. 需要業務改代碼嗎？業務團隊日常面臨著非常繁重的業務壓力，沒有太多精力做技術改造。
2. 升級過程不要影響我業務。對公司業務而言，穩定肯定是第一位的，新的架構不能對業務產生影響
3. 其它你隨便。言下之意就是隻要我們能確保改造成本夠低，穩定性夠好，那業務團隊還是願意配合我們一起去落地 Service Mesh 的。
這就讓我想起了著名的產品價值公式：
由此公式可知：
『新體驗 - 舊體驗』就是前述提到的 Service Mesh 所帶來的種種好處，這部分價值需要被最大化
『遷移成本』就是業務在遷移至 Service Mesh 新架構過程中的種種成本，這部分成本需要被最小化，主要包括
- 接入成本：已有的系統如何接入 Service Mesh？是否要做業務改造？
- 是否平滑遷移：生產環境已經運行著眾多的業務系統，是否能平滑地遷移到 Service Mesh 架構下？
- 穩定性：Service Mesh 是一套全新的架構體系，業務遷移上去之後如何確保穩定性？
接下來我們就來看一下螞蟻是怎麼做的。
接入成本
由於螞蟻的服務統一使用了 SOFA 框架，所以為了最小化業務的接入成本，我們的方案是修改 SOFA SDK 的邏輯，從而能夠自動識別運行模式，當發現運行環境啟用了 Service Mesh，就會自動和 Sidecar 對接，如果沒有啟用 Service Mesh，則繼續以非 Service Mesh 的方式運行。對業務方而言，只需要升級一次 SDK，就完成了接入，不需要改業務代碼。
我們再來看一下 SDK 是怎麼和 Sidecar 對接的，首先來看服務發現的過程：
1.假設服務端運行在1.2.3.4這臺機器上，監聽20880端口，首先服務端會向自己的 Sidecar 發起服務註冊請求，告知 Sidecar 需要註冊的服務以及 IP + 端口(1.2.3.4:20880)
2.服務端的 Sidecar 會向註冊中心發起服務註冊請求，告知需要註冊的服務以及 IP + 端口，不過這裡需要注意的是註冊上去的並不是業務應用的端口(20880)，而是Sidecar自己監聽的一個端口(例如：20881)
3.調用端向自己的 Sidecar 發起服務訂閱請求，告知需要訂閱的服務信息
4.調用端的 Sidecar 向調用端推送服務地址，這裡需要注意的是推送的IP是本機，端口是調用端的 Sidecar 監聽的端口(例如：20882)
5.調用端的 Sidecar 會向註冊中心發起服務訂閱請求，告知需要訂閱的服務信息
6.註冊中心向調用端的 Sidecar 推送服務地址(1.2.3.4:20881)
再來看一下服務通信過程：
1.調用端拿到的『服務端』地址是127.0.0.1:20882，所以就會向這個地址發起服務調用
2.調用端的 Sidecar 接收到請求後，通過解析請求頭，可以得知具體要調用的服務信息，然後獲取之前從服務註冊中心返回的地址後就可以發起真實的調用(1.2.3.4:20881)
3.服務端的 Sidecar 接收到請求後，經過一系列處理，最終會把請求發送給服務端(127.0.0.1:20880)
通過上面的過程，就完成了 SDK 和 Sidecar 的對接。可能會有人問，為啥不採用 iptables 的方案呢？主要的原因是一方面 iptables 在規則配置較多時，性能下滑嚴重，另一個更為重要的方面是它的管控性和可觀測性不好，出了問題比較難排查。
平滑遷移
螞蟻的生產環境運行著非常多的業務系統，有著複雜的上下游依賴關係，有些是非常核心的應用，稍有抖動就會產生故障，所以對於像 Service Mesh 這樣一個大的架構改造，平滑遷移是一個必選項，同時還需要支持可灰度和可回滾。
得益於我們在架構體系中保留的註冊中心，平滑遷移方案也是比較簡單直白的：
1.初始狀態
以下圖為例，初始有一個服務提供者，有一個服務調用者。
2.透明遷移調用方
在我們的方案中，對於先遷移調用方還是先遷移服務方沒有任何要求，這裡假設調用方希望先遷移到 Service Mesh 上，那麼只要在調用方開啟 Sidecar 的注入即可，SDK 會自動識別到當前啟用了 Service Mesh，就會和Sidecar 做服務的訂閱和通信，然後 Sidecar 會訂閱服務並和真正的服務方通信，而服務方則完全不感知調用方是否遷移了。所以調用方可以採用灰度的方式一臺一臺開啟 Sidecar，如果有問題直接回滾即可。
3.透明遷移服務方
假設服務方希望先遷移到 Service Mesh 上，那麼只要在服務方開啟 Sidecar 的注入即可，SDK 會自動識別到當前啟用了 Service Mesh，就會和 Sidecar 做服務的註冊和通信，然後 Sidecar 會把自己作為服務提供方註冊到註冊中心，調用方依然從註冊中心訂閱服務，完全不感知服務方是否遷移了。所以服務方可以採用灰度的方式一臺一臺開啟 Sidecar，如果有問題直接回滾即可。
4.終態
最後就達到了終態，調用方和服務方都平滑地遷移到了 Service Mesh 上，如下圖所示。
穩定性
通過 Service Mesh 架構的引入，我們初步實現了應用和基礎設施的解耦，大大加快了基礎設施的迭代速度，不過這對穩定性意味著什麼？
在 SDK 的模式下，中間件同學在發佈 SDK 後，業務應用會逐步升級，並且會按照開發、測試、預發、灰度、生產等環境逐步推進並進行完整的功能驗證，從一定程度上來說，其實是有大量的業務同學在幫中間件的產品做測試，並且是分環境小規模逐步升級，所以風險非常小。
然而，在 Service Mesh 的架構下，業務應用和基礎設施解耦了，這個使迭代速度大大加快，但是也意味著我們無法再用以前的這套模式來確保穩定性，我們不僅需要在研發階段保證產品質量，更要在線上變更時控制風險。
考慮到螞蟻的集群規模，線上變更往往涉及到幾十萬個容器，如何保證這麼大規模下升級的穩定性呢？我們給出的方案是：無人值守變更。
在瞭解無人值守變更之前，我們先來看下無人駕駛，下面這副圖定義了無人駕駛的成熟度級別，從L0 - L5。L0 就對應著我們現在大部分的駕駛模式，汽車本身沒有任何自動化能力，需要由駕駛員來完全控制，而 L5 呢就是最高級別，能夠實現真正的無人駕駛。像我們熟知的 Tesla，它的自動駕駛就處於L2 – L3 之間，具備了在一定場景下的自動駕駛能力。
我們也參照了這套體系定義了無人值守變更的級別，如下圖所示：
L0：純人肉變更，黑屏操作，沒有任何工具輔助
L1：有了一些工具，不過並沒有體系化串聯起來，需要人編排不同的工具來完成一個變更，確保人工灰度
L2：具備了初步的自動化能力，系統能夠自己編排將整個變更流程串起來，具備強制灰度的能力，所以相比於 L1 級別，人的手解放了，一次變更只需要提交一個工單即可
L3：系統具備了觀測能力，在變更過程中，如果發現有異常會通知用戶並且阻斷變更，所以相比於 L2 級別，人的眼睛也解放了，我們不需要時刻盯著變更過程，不過電話還得開著，一旦有問題需要及時上線處理
L4：就更進一步了，系統具備了決策能力，當發現變更有問題的時候，系統可以自動處理實現自愈，所以相比於 L3 級別，人的大腦也解放了，變更可以放在半夜進行，有問題系統會按照預定義的方案自動處理，實在解決不了才需要電話通知人上線處理
L5：就是終極狀態了，提交完變更後，人就可以離開了，系統會自動執行並且確保沒有問題
目前我們自評已經做到了 L3 級別，主要體現在：
- 系統自動編排分批策略，實現強制灰度
- 引入了變更防禦，增加了前置、後置校驗，當問題發生時，能夠及時阻斷變更
變更防禦流程如下圖所示：
- 提交變更工單以後，系統會對變更進行分批，按照機房、應用、單元等維度開啟分批變更
- 在每個批次變更開始前首先會進行前置校驗，比如檢查當前時間是否是業務高峰期，是否是故障期間，檢查系統容量等
- 前置校驗如果不通過，則變更終止並通知變更的同學，如果通過，則會開始 Mosn 的升級或接入流程
- 變更完成後會進行後置校驗，比如會檢查業務監控，像交易、支付成功率是否下跌等，還會檢查服務健康度，比如RT、錯誤率是否有異常，同時也會檢查上下游的系統，還會和告警關聯，檢查變更期間是否有故障產生等
- 後置校驗如果不通過，則變更終止並通知變更的同學，如果通過，則會開始下一批次的變更流程
整體架構
我們再來看一下螞蟻 SOFAMesh 的整體架構，這裡的『雙模微服務』是指傳統的基於SDK 的微服務和 Service Mesh 微服務雙劍合璧，從而可以實現：
- 互聯互通：兩個體系中的應用可以相互訪問
- 平滑遷移：應用可以在兩個體系中平滑遷移，對於上下游依賴可以實現透明無感知
- 靈活演進：在互聯互通和平滑遷移實現之後，我們就可以根據實際情況進行靈活的應用改造和架構演進
在控制面上，我們引入了 Pilot 實現配置的下發（如服務路由規則），在服務發現上仍然保留了獨立的註冊中心來實現平滑遷移和規模化落地。
在數據面上，我們使用了自研的 Mosn，不僅支持 SOFA 應用，同時也支持 Dubbo 和 Spring Cloud 應用。
在部署模式上，我們不僅支持容器/k8s，同時也支持虛擬機場景。
落地規模和業務價值
目前 Service Mesh 覆蓋了螞蟻數千個應用，實現了核心鏈路全覆蓋，生產運行的 Pod 數量有幾十萬，雙十一當天處理的 QPS 達到了幾千萬，平均處理響應時間 <0.2 ms，取得了不錯的技術成果。
在業務價值上，通過 Service Mesh 架構，我們初步實現了基礎設施和業務應用的解耦，基礎設施的升級能力從 1 ~ 2 次/年提升為 1 ~ 2 次/月，不僅大大加快了迭代速度，同時節省了全站每年數千人日的升級成本；藉助於 Mosn 的流量調撥實現了分時調度的場景，僅用了 3m40s 就完成了 2w+ 容器的切換，節省下 3.6w+ 物理核，實現了雙大促不加機器；在安全可信方面，實現了身份認證、服務鑑權和通信加密，從而使得服務可以運行於零信任網絡中，提升了整體安全水位；在服務治理方面，快速上線了自適應限流、全侷限流、單機壓測、業務單元隔離等能力，大大提升了精細化服務治理水平，給業務也帶來了很大的價值。
三、社區好消息
近期，很榮幸我們收穫了開發者們的認可，MOSN 榮獲 「2020 年中國優秀開源項目」，Service Mesh 獲得「2020 年中國技術品牌影響力企業」。
開源技術的發展已經深入人心，開發者們積極擁抱開源技術，並共建開源社區。非常感謝所有開發者們的支持和喜愛，MOSN 團隊會繼續努力，加大資源的投入，下週是MOSN新年的第一場 Community Call，屆時會有一些 RoadMap 與大家分享。
為開發者們提供更好的開源產品和服務，也期待大家的持續共建！
「2020 年中國優秀開源項目」
「2020 年中國技術品牌影響力企業」
四、展望未來
目前，我們已經能非常清楚地看到整個行業正在經歷從雲託管(Cloud Hosted)到雲就緒(Cloud Ready)直至雲原生(Cloud Native)的過程。
不過這裡希望強調的一點是，我們並不是為了技術而技術，技術的發展本質上還是為了業務發展。雲原生也是一樣，其根本還是在於提升效率，降低成本，所以雲原生本身不是目的，而是手段。
我們通過 Service Mesh 的大規模落地，也是向著雲原生走出了堅實的一步，驗證了可行性，同時也確實看到了基礎設施下沉後無論是對業務還是對基礎設施團隊都帶來了研發和運維效率的提升。
目前 Mosn 主要提供了 RPC 和 MQ 的能力，然而還有大量的基礎設施邏輯作為 SDK 嵌在業務系統中，離真正解耦基礎設施與業務還有很大距離，所以未來我們會將更多的能力下沉到 Mosn 中（如事務、緩存、配置、任務調度等），實現 Service Mesh 到 Mesh 的演進。對業務應用而言，以後都會通過標準化的接口來和 Mosn 交互，不需要再引入各種很重的 SDK，從而使 Mosn 從單純的流量代理演化成為下一代的中間件運行時。
通過這種方式能進一步降低業務應用和基礎設施的耦合，使得業務應用更輕量化。如圖所示，從最早的單體應用演化到微服務，實現了業務團隊之間的解耦，但是並沒有解開業務團隊和基礎設施團隊之間的耦合，未來的方向就如第三幅圖所示，我們希望業務應用朝著純業務邏輯(Micrologic)這個方向前進，把非業務邏輯都下沉到 Sidecar 中，從而可以真正實現業務和基礎設施的獨立演進，提升整體效率。
另一個趨勢是 Serverless，目前受限於應用體積、啟動速度等因素，Serverless 主要的應用場景還是在 Function 上。
不過我們始終認為 Serverless 不會只侷限在 Function 場景，它的彈性、免運維、按需使用等特性對普通的業務應用而言，價值顯然是更大的。
所以當業務應用演進到 Micrologic + Sidecar 後，一方面業務應用自身的體積會變小、啟動速度會加快，另一方面基礎設施也能做更多的優化（比如提前和數據庫建連、提前準備好緩存數據等），從而使得普通業務應用也能融入到 Serverless 體系中，真正享受到 Serverless 帶來的效率、成本等方面的紅利。