雲原生的理念正如火如荼，然而真正大規模落地的公司依然屈指可數，螞蟻作為國内比較早進行嘗試的公司，經過了 2 年多的探索，沉澱出了一套切實可行的方案并最終通過了雙十一的考驗。
本文主要分享我們在 Service Mesh 大規模落地過程中的一些經驗以及對未來的思考，希望能給大家帶來一些啟發。
一、為什麼需要 Service Mesh?
我們為什麼需要Service Mesh，它對業務的價值在哪裡，我們總結了三點：
1. 微服務治理與業務邏輯解耦。
2. 異構系統的統一治理。
3. 金融級的網絡安全。
下面分别進行闡述。
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 級别，主要展現在：
1. 系統自動編排分批政策，實作強制灰階
2. 引入了變更防禦，增加了前置、後置校驗，當問題發生時，能夠及時阻斷變更
變更防禦流程如下圖所示：
- 送出變更工單以後，系統會對變更進行分批，按照機房、應用、單元等次元開啟分批變更
- 在每個批次變更開始前首先會進行前置校驗，比如檢查目前時間是否是業務高峰期，是否是故障期間，檢查系統容量等
- 前置校驗如果不通過，則變更終止并通知變更的同學，如果通過，則會開始 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+ 實體核，實作了雙大促不加機器；在安全可信方面，實作了身份認證、服務鑒權和通信加密，進而使得服務可以運作于零信任網絡中，提升了整體安全水位；在服務治理方面，快速上線了自适應限流、全局限流、單機壓測、業務單元隔離等能力，大大提升了精細化服務治理水準，給業務也帶來了很大的價值。
三、展望未來
目前，我們已經能非常清楚地看到整個行業正在經曆從雲托管(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 帶來的效率、成本等方面的紅利。
- END -