宋順

讀完需要

10

分鐘

速讀僅需 5 分鐘

云原生的理念正如火如荼，然而真正大規模落地的公司依然屈指可數，螞蟻作為國內比較早進行嘗試的公司，經過了 2 年多的探索，沉淀出了一套切實可行的方案并最終通過了雙十一的考驗。

本文主要分享我們在 Service Mesh 大規模落地過程中的一些經驗以及對未來的思考，希望能給大家帶來一些啟發。

1

? ?

為什么需要 Service Mesh?

我們為什么需要Service Mesh，它對業務的價值在哪里，我們總結了三點：

微服務治理與業務邏輯解耦。

異構系統的統一治理。

金融級的網絡安全。

下面分別進行闡述。

1.1

? ?

微服務治理與業務邏輯解耦

在 Service Mesh 之前，傳統微服務體系的玩法都是由中間件團隊提供一個 SDK 給業務應用使用，在 SDK 中會實現各種服務治理的能力，如：服務發現、負載均衡、熔斷限流、服務路由等。

?

在運行時，SDK 和業務應用的代碼其實是混合在一個進程中運行的，耦合度非常高，這就帶來了一系列的問題：

?

• 升級成本高。每次升級都需要業務應用修改 SDK 版本號，重新發布。以螞蟻為例，以往每年我們在中間件版本升級上就需要耗費數千人日。

• 版本碎片化嚴重。由于升級成本高，但中間件還是會持續向前發展，久而久之，就會導致線上 SDK 版本各不統一、能力參差不齊，造成很難統一治理。

• 中間件演進困難。由于版本碎片化嚴重，所以中間件向前演進過程中就需要在代碼中去兼容各種各樣的老版本邏輯，就像是戴著『枷鎖』前行，無法實現快速迭代。

?

有了 Service Mesh 之后，我們就可以把 SDK 中的大部分能力從應用中剝離出來，拆解為獨立進程，以 Sidecar 的模式運行。通過將服務治理能力下沉到基礎設施，可以讓業務更加專注于業務邏輯，而中間件團隊則更加專注于各種通用能力建設，真正實現獨立演進，透明升級，提升整體效率。

1.2

? ?

異構系統統一治理

隨著新技術的發展，在同一家公司中往往也會出現使用各種不同語言、不同框架的應用和服務。以螞蟻為例，內部業務也是百花齊放，有前端、搜索推薦、人工智能、安全等各種業務，它們使用到的技術棧也非常多樣化，除了Java 以外，還有 NodeJS、Golang、Python、C++ 等，為了能夠統一管控這些服務，我們要為每種語言、每種框架都重新開發一套完整的 SDK，維護成本非常高，而且對我們的人員結構也帶來了很大的挑戰。?

有了 Service Mesh 之后，通過將主體的服務治理能力下沉到基礎設施，多語言的支持就輕松很多了，只需要提供一個非常輕量的 SDK、甚至很多情況都不需要一個單獨的 SDK，就可以方便地實現多語言、多協議的統一流量控制、監控等治理需求。

?

1.3

? ?

金融級網絡安全

當前很多公司的微服務體系建設都建立在『內網可信』的假設之上，然而這個假設在當前大規模上云的背景下可能不再合適，尤其是涉及到一些金融場景的時候。

?

通過 Service Mesh，我們可以更方便地實現應用的身份標識和訪問控制，輔之以數據加密，就能實現全鏈路可信，從而使得服務可以運行于零信任網絡中，提升整體安全水位。

?

2

? ?

螞蟻 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+ 物理核，實現了雙大促不加機器；在安全可信方面，實現了身份認證、服務鑒權和通信加密，從而使得服務可以運行于零信任網絡中，提升了整體安全水位；在服務治理方面，快速上線了自適應限流、全局限流、單機壓測、業務單元隔離等能力，大大提升了精細化服務治理水平，給業務也帶來了很大的價值。

3

? ?

展望未來

目前，我們已經能非常清楚地看到整個行業正在經歷從云托管(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?-

想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信

申請備注（姓名+公司+技術方向）才能通過哦！

阿里技術精彩文章推薦

往期推薦

深度：揭秘阿里巴巴的客群畫像

多隆：從工程師到阿里巴巴合伙人

阿里技術專家楚衡：架構制圖的工具與方法論

螞蟻集團技術專家山丘：性能優化常見壓測模型及優缺點

阿里文娛技術專家戰獒: 領域驅動設計詳解之What, Why, How?

阿里專家馬飛翔：一文讀懂架構整潔之道

阿里專家常昊：新人如何上手項目管理？

螞蟻集團沈凋墨：Kubernetes-微內核的分布式操作系統

阿里合伙人范禹：常掛在阿里技術人嘴邊的四句土話

阿里技術專家都鐸：一文搞懂技術債

支付寶研究員兼OceanBase總架構師楊傳輝：我在數據庫夢之隊的十年成長路

阿里技術專家麒燁：修煉測試基本功

阿里計算平臺掌門人賈揚清：我對人工智能方向的一點淺見

螞蟻資深算法專家周俊：從原理到落地，支付寶如何打造保護隱私的共享智能？

阿里高級技術專家簫逸：如何畫好一張架構圖？

阿里高級技術專家張建飛：應用架構分離業務邏輯和技術細節之道

螞蟻科技 Service Mesh 落地實踐與挑戰 | GIAC 實錄

阿里6年，我的技術蛻變之路！

螞蟻集團涵暢：再啟程，Service Mesh 前路雖長，尤可期許

阿里P9專家右軍：大話軟件質量穩定性

阿里合伙人程立：阿里15年，我撕掉了身上兩個標簽

阿里高工流生 | 云原生時代的 DevOps 之道

阿里高級技術專家邱小俠：微服務架構的理論基礎 - 康威定律

阿里P9專家右軍：以終為始的架構設計

阿里P8架構師：淘寶技術架構從1.0到4.0的架構變遷！12頁PPT詳解

阿里技術：如何畫出一張合格的技術架構圖？

螞蟻資深技術專家王旭：開源項目是如何讓這個世界更安全的？

阿里資深技術專家崮德：8 個影響我職業生涯的重要技能

儒梟：我看技術人的成長路徑

阿里高級技術專家宋意：平凡人在阿里十年的成長之旅

阿里技術專家甘盤：淺談雙十一背后的支付寶LDC架構和其CAP分析

阿里技術專家光錐：億級長連網關的云原生演進之路

阿里云原生張羽辰：服務發現技術選型那點事兒

螞蟻研究員玉伯：做一個簡單自由有愛的技術人

阿里高級技術專家至簡: Service Mesh 在超大規模場景下的落地挑戰

阿里巴巴山獵：手把手教你玩轉全鏈路監控

阿里涉江：你真的會學習嗎？從結構化思維說起

螞蟻金服資深技術專家經國：云原生時代微服務的高可用架構設計

深入分布式緩存之EVCache探秘開局篇

? ?END ? ?? #架構師必備#點分享點點贊點在看

總結

以上是生活随笔為你收集整理的蚂蚁Service Mesh大规模落地实践与展望的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。