螞蟻金服 Service Mesh 深度實踐

做者丨敖小劍

2019 年，螞蟻金服在 Service Mesh 領域繼續高歌猛進，進入大規模落地的深水區。本文介紹了 Service Mesh 在螞蟻金服的落地狀況和即未來臨的雙十一大考，以及大規模落地時遇到的困難和解決方案，助你瞭解 Service Mesh 的將來發展方向和前景。

1、前言

你們好，我是敖小劍，來自螞蟻金服中間件團隊，今天帶來的主題是「詩和遠方：螞蟻金服 Service Mesh 深度實踐」。

在過去兩年，我前後作過兩次 Service Mesh 的演講：

• 2017 年，當時 Service Mesh 在國內還屬於蠻荒時代，我當時作了一個名爲「Service Mesh: 下一代微服務」的演講，開始在國內佈道 Service Mesh 技術；
• 2018 年，作了名爲「長路漫漫踏歌而行：螞蟻金服 Service Mesh 實踐探索」的演講，介紹螞蟻金服在 Service Mesh 領域的探索性的實踐，當時螞蟻金服剛開始在 Service Mesh 探索。
• 今天，有幸第三次，給你們帶來的依然是螞蟻金服在 Service Mesh 領域的實踐分享。和去年不一樣的是，今年螞蟻金服進入了 Service Mesh 落地的深水區，規模巨大，並且即將迎來雙十一大促考驗。

備註：現場作了一個調研，瞭解聽衆對 Servicve Mesh 的瞭解程度，結果不太理想：在此以前對 Service Mesh 有了解的同窗目測只有 10% 多點（確定不到 20%）。Service Mesh 的技術佈道，依然任重道遠。

今天給你們帶來的內容主要有三塊：

1. 螞蟻金服落地狀況介紹：包括你們最關心的雙十一落地狀況；
2. 大規模落地的困難和挑戰：分享一下咱們過去一年中在大規模落地上遇到的問題；
3. 是否採用 Service Mesh 的建議：這個問題常常被人問起，因此借這個機會給出一些中肯的建議供你們參考。

2、螞蟻金服落地狀況介紹

（一）發展歷程和落地規模

Service Mesh 技術在螞蟻金服的落地，前後經歷過以下幾個階段：

• 技術預研 階段：2017 年末開始調研並探索 Service Mesh 技術，並肯定爲將來發展方向；
• 技術探索 階段：2018 年初開始用 Golang 開發 Sidecar SOFAMosn，年中開源基於 Istio 的 SOFAMesh；
• 小規模落地 階段：2018 年開始內部落地，第一批場景是替代 Java 語言以外的其餘語言的客戶端 SDK，以後開始內部小範圍試點；
• 規模落地 階段：2019 年上半年，做爲螞蟻金融級雲原生架構升級的主要內容之一，逐漸鋪開到螞蟻金服內部的業務應用，並平穩支撐了 618 大促；
• 全面大規模落地 階段：2019 年下半年，在螞蟻金服內部的業務中全面鋪開，落地規模很是龐大，並且準備迎接雙十一大促。

目前 ServiceMesh 正在螞蟻金服內部大面積鋪開，我這裏給出的數據是前段時間（大概 9 月中）在雲棲大會上公佈的數據：應用數百個，容器數量（pod 數）超過 10 萬。固然目前落地的 pod 數量已經遠超過 10 萬，這已是目前全球最大的 Service Mesh 集羣，但這僅僅是一個開始，這個集羣的規模後續會繼續擴大，明年螞蟻金服會有更多的應用遷移到 Service Mesh。

（二）主要落地場景

目前 Service Mesh 在螞蟻金服內部大量落地，包括支付寶的部分核心鏈路，落地的主要場景有：

• 多語言支持：目前除了支持 Java 以外，還支持 Golang，Python，C++，NodeJS 等語言的相互通訊和服務治理；
• 應用無感知的升級：關於這一點咱們後面會有特別的說明；
• 流量控制：經典的 Istio 精準細粒度流量控制；
• RPC 協議支持：和 Istio 不一樣，咱們內部使用的主要是 RPC 協議；
• 可觀測性。

（三）Service Mesh 的實際性能數據

以前和一些朋友、客戶交流過，目前在 Service Mesh 方面你們最關心的是 Service Mesh 的性能表現，包括對於此次螞蟻金服 Service Mesh 上雙十一，你們最想看到的也是性能指標。

爲何你們對性能這麼關注？

由於在 Service Mesh 工做原理的各類介紹中，都會提到 Service Mesh 是將原來的一次遠程調用，改成走 Sidecar（並且像 Istio 是客戶端和服務器端兩次 Sidecar，如上圖所示），這樣一次遠程調用就會變成三次遠程調用，對性能的擔心也就天然而然的產生了：一次遠程調用變三次遠程調用，性能會降低多少？延遲會增長多少？

下圖是咱們內部的大促壓測數據，對比帶 SOFAMosn 和不帶 SOFAMosn 的狀況（實現相同的功能）。其中 SOFAMosn 是咱們螞蟻金服自行開發的基於 Golang 的 Sidecar/ 數據平面，咱們用它替代了 Envoy，在去年的演講中我有作過詳細的介紹。

SOFAMosn：

github.com/sofastack/s…

• CPU：CPU 使用在峯值狀況下增長 8%，均值約增長 2%。在最新的一次壓測中，CPU 已經優化到基本持平（低於 1%）；
• 內存：帶 SOFAMosn 的節點比不帶 SOFAMosn 的節點內存佔用平均多 15M；
• 延遲：延遲增長平均約 0.2ms。部分場景帶 SOFAMosn 比不帶 SOFAMosn RT 增長約 5%，可是有部分特殊場景帶 SOFAMosn 比不帶 SOFAMosn RT 反而下降 7.5%；

這個性能表現，和前面"一次遠程調用變三次遠程調用"的背景和擔心相比有很大的反差。尤爲是上面延遲的這個特殊場景，竟然出現帶 SOFAMosn（三次遠程調用）比不帶 SOFAMosn（一次遠程調用） 延遲反而下降的狀況。

是否是感受不科學？

（四）Service Mesh 的基本思路

咱們來快速回顧一下 Service Mesh 實現的基本思路：

在基於 SDK 的方案中，應用既有業務邏輯，也有各類非業務功能。雖然經過 SDK 實現了代碼重用，可是在部署時，這些功能仍是混合在一個進程內的。

在 Service Mesh 中，咱們將 SDK 客戶端的功能從應用中剝離出來，拆解爲獨立進程，以 Sidecar 的模式部署，讓業務進程專一於業務邏輯：

業務進程：專一業務實現，無需感知 Mesh；

Sidecar 進程：專一服務間通信和相關能力，與業務邏輯無關；

咱們稱之爲"關注點分離"：業務開發團隊能夠專一於業務邏輯，而底層的中間件團隊（或者基礎設施團隊）能夠專一於業務邏輯以外的各類通用功能。

經過 Sidecar 拆分爲兩個獨立進程以後，業務應用和 Sidecar 就能夠實現「獨立維護」：咱們能夠單獨更新 / 升級業務應用或者 Sidecar。

（五）性能數據背後的情景分析

咱們回到前面的螞蟻金服 Service Mesh 落地後的性能對比數據：從原理上說，Sidecar 拆分以後，原來 SDK 中的各類功能只是拆分到 Sidecar 中。總體上並無增減，所以理論上說 SDK 和 Sidecar 性能表現是一致的。因爲增長了應用和 Sidecar 之間的遠程調用，性能不可避免的確定要受到影響。

首先咱們來解釋第一個問題：爲何性能損失那麼小，和"一次遠程調用變三次遠程調用"的直覺不符？

所謂的「直覺」，是將關注點都集中到了遠程調用開銷上，下意識的忽略了其餘開銷，好比 SDK 的開銷、業務邏輯處理的開銷，所以：

推導出來的結果就是有 3 倍的開銷，性能天然會有很是大的影響。

可是，真實世界中的應用不是這樣：

1. 業務邏輯的佔比很高：Sidecar 轉發的資源消耗相比之下要低不少，一般是十倍百倍甚至千倍的差別；
2. SDK 也是有消耗的：即便不考慮各類複雜的功能特性，僅僅就報文（尤爲是 Body）序列化的編解碼開銷也是不低的。並且，客戶端和服務器端原有的編解碼過程是須要處理 Body 的，而在 Sidecar 中，一般都只是讀取 Header 而透傳 Body，所以在編解碼上要快不少。另外應用和 Sidecar 的兩次遠程通信，都是走的 Localhost 而不是真實的網絡，速度也要快很是多；

所以，在真實世界中，咱們假定業務邏輯百倍於 Sidecar 的開銷，而 SDK 十倍於 Sidecar 的開銷，則：

推導出來的結果，性能開銷從 111 增長到 113，大約增長 2%。這也就解釋了爲何咱們實際給出的 Service Mesh 的 CPU 和延遲的性能損失都不大的緣由。固然，這裏我是刻意選擇了 100 和 10 這兩個係數來拼湊出 2% 這個估算結果，以迎合咱們前面給出「均值約增長 2%」的數據。這不是準確數值，只是用來模擬。

（六）情理當中的意外驚喜

前面的分析能夠解釋性能開銷增長很少的情景，可是，還記得咱們的數據中有一個不科學的地方嗎：「部分特殊場景帶 SOFAMosn 比不帶 SOFAMosn RT 反而下降 7.5%」。

理論上，不管業務邏輯和 SDK 的開銷比 Sidecar 的開銷大多少，也就是無論咱們怎麼優化 Sidecar 的性能，其結果也只能接近零。不管如何不可能出現多兩個 Sidecar，CPU 消耗和延遲反而下降的狀況。

這個「不科學」是怎麼出現的？

咱們繼續來回顧這個 Service Mesh 的實現原理圖：

出現性能大幅提高的主要的緣由，是咱們在 SOFAMosn 上作了大量的優化，特別是路由的緩存。在螞蟻金服內部，服務路由的計算和處理是一個異常複雜的邏輯，很是耗資源。而在最近的優化中，咱們爲服務路由增長了緩存，從而使得服務路由的性能獲得了大幅提高。所以：

備註：這裏我依然是刻意拼湊出 -7% 這個估算結果，請注意這不是準確數值，只是用來模擬示意。

也許有同窗會說，這個結果不「公平」：這是優化了的服務路由實如今 PK 沒有優化的服務路由實現。的確，理論上說，在 Sidecar 中作的任何性能優化，在 SDK 裏面一樣能夠實現。可是，在 SDK 上作的優化須要等整個調用鏈路上的應用所有升級到優化後的 SDK 以後才能徹底顯現。而在傳統 SDK 方案中，SDK 的升級是須要應用配合，這一般是一個漫長的等待過程。極可能代碼優化和發版一週搞定，可是讓全站全部應用都升級到新版本的 SDK 要花費數月甚至一年。

此時 Service Mesh 的優勢就凸顯出來了：Service Mesh 下，業務應用和 Sidecar 能夠「獨立維護」 ，咱們能夠很方便的在業務應用無感知的狀況下升級 Sidecar。所以，任何 Sidecar 的優化結果，均可以很是快速的獲取收益，從而推進咱們對 Sidecar 進行持續不斷的升級。

前面這個延遲下降 7% 的例子，就是一個很是經典的故事：在中秋節先後，咱們開發團隊的同窗，任勞任怨加班加點的進行壓測和性能調優，在一週以內連續作了屢次性能優化，連發了多個性能優化的小版本，以「小步快跑」的方式，最後拿到了這個令你們都很是開心的結果。

總結：持續不斷的優化 + 無感知升級 = 快速得到收益。

這是一個意外驚喜，但又在情理之中：這是 SDK 下沉到基礎設施並具有獨立升級能力後帶來的紅利。

也但願這個例子，可以讓你們更深入的理解 Service Mesh 的基本原理和優點。

3、大規模落地的困難和挑戰

當 Service Mesh 遇到螞蟻金服的規模，困難和挑戰也隨之而來：當規模達到必定程度時，不少本來很小的問題都會急劇放大。後面我將在性能、容量、穩定性、可維護性和應用遷移幾個方面給你們介紹咱們遇到的挑戰和實踐。

（一）數據平面的優化

在數據平面上，螞蟻金服採用了自行研發的基於 Golang 的方案：SOFAMosn。關於爲何選擇全新開發 SOFAMosn，而不是直接使用 Envoy 的緣由，在去年 QCon 的演講中我有過詳細的介紹，有興趣能夠了解。

前面咱們給出的性能數據，實際上主要是數據平面的性能，也就是做爲 Sidecar 部署的 SOFAMosn 的性能表現。從數據上看 SOFAMosn 目前的性能表現仍是很不錯的，這背後是咱們在 SOFAMosn 上作了很是多的性能優化。

CPU 優化：在 SOFAMosn 中咱們進行了 Golang 的 writev 優化，將多個包拼裝一次寫以下降 syscall 調用。測試中發現，Golang 1.9 的時候 writev 有內存泄露的 bug。當時 debug 的過程很是的辛苦...... 詳情見咱們當時給 Golang 提交的 PR：

github.com/golang/go/p…；

內存優化：在內存複用，咱們發現報文直接解析會產生大量臨時對象。SOFAMosn 經過直接複用報文字節的方式，將必要的信息直接經過 unsafe.Pointer 指向報文的指定位置來避免臨時對象的產生；

延遲優化：前面咱們談到 Sidecar 是經過只解析 Header 而透傳 Body 來保證性能的。針對這一點，咱們進行了協議升級，以便快速讀取 Header。好比咱們使用的 TR 協議請求頭和 Body 均爲 hessian 序列化，性能損耗較大。而 Bolt 協議中 Header 是一個扁平化 map，解析性能損耗小。所以咱們升級應用改走 Bolt 協議來提高 Sidecar 轉發的性能。這是一個典型的針對 Sidecar 特性而作的優化；

此外還有前面特地重點介紹的路由緩存優化（也就是那個不科學的延遲下降 7% 的場景）。因爲螞蟻金服內部路由的複雜性（一筆請求常常須要走多種路由策略最終肯定路由結果目標），經過對相同條件的路由結果作秒級緩存，咱們成功將某核心鏈路的全鏈路 RT 下降 7%。

這裏我簡單給出了上述幾個典型案例，雙十一以後會有更多更詳細的 SOFAMosn 資料分享出來，有興趣的同窗能夠多關注。

在雙十一事後，咱們也將加大 SOFAMosn 在開源上的投入，將 SOFAMosn 作更好地模塊化地抽象，而且將雙十一中通過考驗的各類優化放進去，預計在 2020 年的 1 月底能夠發佈第一個優化後的版本。

（二）Mixer 的性能優化

vMixer 的性能優化是個老生常談的話題，基本上只要談及 Istio 的性能，都避無可避。

Mixer 的性能問題，一直都是 Istio 中最被人詬病的地方。

尤爲在 Istio 1.1/1.2 版本以後，引入 Out-Of-Process Adapter 以後，更是雪上加霜。

原來 Sidecar 和 Mixer 之間的遠程調用已經嚴重影響性能，在引入 Out-Of-Process Adapter 以後又在 Traffic 流程中引入了新的遠程調用，性能更加不可接受。

從落地的角度看，Mixer V1 糟糕至極的性能，已是「生命沒法承受之重」。對於通常規模的生產級落地而言，Mixer 性能已是難於接受，更不要提大規模落地……

Mixer V2 方案則給了社區但願：將 Mixer 合併進 Sidecar，引入 web assembly 進行 Adapter 擴展，這是咱們期待的 Mixer 落地的正確姿式，是 Mixer 的將來，是 Mixer 的"詩和遠方"。然而社區望穿秋水，但 Mixer V2 遲遲未能啓動，長期處於 In Review 狀態，遠水解不了近渴。

所以在 Mixer 落地上，咱們只能接受妥協方案，所謂"眼前的苟且"：一方面咱們棄用 Mixer v1，改成在 SOFAMosn 中直接實現功能；另外一方面咱們並無實現 Mixer V2 的規劃。實際的落地方式是：咱們只在 SOFAMosn 中提供最基本的策略檢查功能如限流，鑑權等，另外可觀測性相關的各類能力也都是從 SOFAMosn 直接輸出。

（三）Pilot 的性能優化

在 Istio 中，Pilot 是一個被 Mixer 掩蓋的重災區：長期以來你們的性能關注點都在 Mixer，表現糟糕並且問題明顯的 Mixer 一直在吸引火力。可是當選擇放棄 Mixer（典型如官方在 Istio 新版本中提供的關閉 Mixer 的配置開關）以後，Pilot 的性能問題也就很快浮出水面。

這裏簡單展現一下咱們在 Pilot 上作的部分性能優化：

• 序列化優化：咱們全面使用 types.Any 類型，棄用 types.Struct 類型，序列化性能提高 70 倍，總體性能提高 4 倍。Istio 最新的版本中也已經將默認模式修改成 types.Any 類型。咱們還進行了 CR(CustomResource) 的序列化緩存，將序列化時機從 Get/List 操做提早至事件觸發時，並緩存結果。大幅下降序列化頻率，壓測場景下總體性能提高 3 倍，GC 頻率大幅降低；
• 預計算優化：支持 Sidecar CRD 維度的 CDS /LDS/RDS 預計算，大幅下降重複計算，壓測場景下總體性能提高 6 倍；支持 Gateway 維度的 CDS / LDS / RDS 預計算；計算變動事件的影響範圍，支持局部推送，減小多餘的計算和對無關 Sidecar 的打擾；
• 推送優化：支持運行時動態降級，支持熔斷閾值調整，限流閾值調整，靜默週期調整，日誌級別調整；實現增量 ADS 接口，在配置相關處理上，Sidecar cpu 減小 90%，Pilot cpu 減小 42%；

這裏簡單解釋一下，Pilot 在推送數據給 Sidecar 時，代碼實現上的有些簡單：Sidecar 鏈接上 Pilot 時；Pilot 就給 Sidecar 下發 xDS 數據。假定某個服務有 100 個實例，則這 100 個實例的 Sidecar 鏈接到 Pilot 時，每次都會進行一次下發數據的計算，而後進行序列化，再下發給連上來的 Sidecar。下一個 Sidecar 鏈接上來時，重複這些計算和序列化工做，而無論下發的數據是否徹底相同，咱們稱之爲「千人千面」。

而實際中，同一個服務每每有多個實例，Pilot 下發給這些實例的 Sidecar 的數據每每是相同的。所以咱們作了優化，提早作預計算和序列化並緩存結果，以便後續重複的實例能夠直接從緩存中取。所以，「千人千面」就能夠優化爲「千人百面」或者「千人十面」，從而大幅提升性能。

另外，對於整個 Service Mesh 體系，Pilot 相當重要。所以 Pilot 自己也應該進行保護，也須要諸如熔斷 / 限流等特性。

（四）Service Mesh 的運維

在 Service Mesh 的運維上，咱們繼續堅持「線上變動三板斧」原則。這裏的變動，包括髮布新版本，也包括修改配置，尤爲特指修改 Istio 的 CRD。

線上變動「三板斧」指的是：

• 可灰度：任何變動，都必須是能夠灰度的，即控制變動的生效範圍。先作小範圍內變動，驗證經過以後才擴大範圍；
• 可監控：在灰度過程當中，必須能作到可監控，能瞭解到變動以後對系統的應用。若是沒有可監控，則可灰度也就沒有意義了；
• 可回滾：當經過監控發現變動後會引起問題時，還須要有方法能夠回滾；
• 咱們在這裏額外引入了一個名爲「ScopeConfig」的配置變動生效範圍的控制能力，即配置變動的灰度。什麼是配置變動的灰度呢？

Istio 的官方實現，默認修改配置（Istio API 對應的各類 CRD）時新修改的配置會直接全量推進到全部生效的 Sidecar，即配置變動自己沒法灰度。注意這裏和平時說的灰度不一樣，好比最多見的場景，服務 A 調用服務 B，並假定服務 A 有 100 個實例，而服務 B 有 10 個 v1 版本的服務實例正在進行。此時須要更新服務 B 到新的 v2 版本。爲了驗證 v2 新版本，咱們一般會選擇先上線一個服務 B 的 v2 版本的新實例，經過 Istio 進行流量百分比拆分，好比切 1% 的流量到新的 v2 版本的，這被稱爲「灰度發佈」。此時新的「切 1% 流量到 v2」的 CRD 被下發到服務 A 的 Sidecar，這 100 個 Sidecar 中的每一個都會執行該灰度策略。若是 v2 版本有問題不能正常工做，則隻影響到 1% 的流量，即此時 Istio 的灰度控制的是 CRD 配置生效以後 Sidecar 的流量控制行爲。

可是，實際生產中，配置自己也是有風險的。假設在配置 Istio CRD 時出現低級錯誤，不當心將新舊版本的流量比例配反了，錯誤配置成了 99% 的流量去 v2 版本。則當新的 CRD 配置被下發到所有 100 個服務 A 的實例時並生效時， Sidecar 控制的流量就會發生很是大的變化，形成生產事故。

爲了規避這個風險，就必須引入配置變動的範圍控制，好比將新的 CRD 配置下發到少數 Sidecar，驗證配置無誤後再擴展到其餘 Sidecar。

（五）應用平滑遷移的終極方案

在 Service Mesh 落地的過程當中，現有應用如何平滑遷移到 Service Mesh，是一個相當重要的話題。典型如基於傳統微服務框架如 SpringCloud/Dubbo 的應用，如何逐個（或者分批）的遷移到 Service Mesh 上。

螞蟻金服在去年進行落地實踐時，就特別針對應用平滑遷移進行了深刻研究和探索。這個問題是 Service Mesh 社區很是關注的核心落地問題，今天咱們重點分享。

在今年 9 月份的雲棲大會上，螞蟻金服推出了雙模微服務的概念，以下圖所示：

「雙模微服務」是指傳統微服務和 Service Mesh 雙劍合璧，即「基於 SDK 的傳統微服務」能夠和「基於 Sidecar 的 Service Mesh 微服務」實現下列目標：

• 互聯互通：兩個體系中的應用能夠相互訪問；
• 平滑遷移：應用能夠在兩個體系中遷移，對於調用該應用的其餘應用，作到透明無感知；
• 靈活演進：在互聯互通和平滑遷移實現以後，咱們就能夠根據實際狀況進行靈活的應用改造和架構演進。

雙模還包括對應用運行平臺的要求，即兩個體系下的應用，既能夠運行在虛擬機之上，也能夠運行在容器 /k8s 之上。

怎麼實現這麼一個美好的雙模微服務目標呢？

咱們先來分析一下傳統微服務體系和 Service Mesh 體系在服務註冊 / 服務發現 / 服務相關的配置下發上的不一樣。

首先看傳統微服務體系，其核心是服務註冊中心 / 配置中心，應用經過引用 SDK 的方式來實現對接各類註冊中心 / 配置中心。一般不一樣的註冊中心 / 配置中心都有各自的實現機制和接口協議，SDK 和註冊中心 / 配置中心的交互方式屬於內部實現機制，並不通用。

優勢是支持海量數據（十萬級別甚至百萬級別），具有極強的分發能力，並且通過十餘年間的打磨，穩定可靠可謂久經考驗。市面上有不少成熟的開源產品，各大公司也都有本身的穩定實現。如阿里集團的 Nacos，螞蟻金服的 SOFARegistry。

SOFARegistry：

github.com/sofastack/s…

缺點是註冊中心 / 配置中心與 SDK 一般是透傳數據，即註冊中心 / 配置中心只進行數據的存儲和分發。大量的控制邏輯須要在 SDK 中實現，而 SDK 是嵌入到應用中的。所以，任何變動都須要改動 SDK 並要求應用升級。

再來看看 Service Mesh 方案，以 Istio 爲例：

Service Mesh 的優勢是引入了控制平面（在 Istio 中具體指 Pilot 組件），經過控制平面來提供強大的控制邏輯。而控制平面的引入，MCP/xDS 等標準協議的制訂，實現了數據源和下發數據的解耦。即存儲於註冊中心 / 配置中心（在 Istio 中體現爲 k8s api server + Galley）的數據能夠有多種靈活的表現形式，如 CRD 形式的 Istio API，經過運行於 Pilot 中的 Controller 來實現控制邏輯和格式轉換，最後統一轉換到 xDS/UDPA。這給 API 的設計提供了很是大的施展空間，極具靈活度，擴展性很是好。

缺點也很明顯，和成熟的註冊中心 / 配置中心相比，支持的容量有限，下發的性能和穩定性相比之下有很大差距。

控制平面和傳統註冊中心 / 配置中心可謂各有千秋，尤爲他們的優缺點是互補的，如何結合他們的優點？

此外，如何打通兩個體系是 Service Mesh 社區的老大難問題。尤爲是缺少標準化的社區方案，只能自行其是，各自爲戰。

最近，在綜合了過去一年多的思考和探索以後，螞蟻金服和阿里集團的同事們共同提出了一套完整的解決方案，咱們戲稱爲「終極方案」：但願能夠經過這個方案打通傳統微服務體系和 Service Mesh 體系，完全終結這個困擾已久的問題。

這個方案的核心在於：以 MCP 和 xDS/UDPA 協議爲基礎，融合控制平面和傳統註冊中心 / 配置中心。

如上圖所示，若是咱們將融合控制平面和傳統註冊中心 / 配置中心而來的新的產品形態視爲一個總體，則這個新產品形態的能力主要有三塊：

1. 傳統註冊中心的數據存儲能力：支持海量數據；
2. Service Mesh 控制平面的能力：解耦以後 API 設計的彈性和靈活度；
3. 傳統註冊中心的分發能力：性能、速度、穩定性。

這個新的產品形態能夠理解爲「帶控制平面的註冊中心 / 配置中心」，或者「存儲 / 分發能力增強版的控制平面」。名字不重要，重要的是各節點的通信交互協議必須標準化：

• MCP 協議：MCP 協議是 Istio 中用 於 Pilot 和 Galley 之間同步數據的協議，源自 xDS 協議。咱們設想經過 MCP 協議將不一樣源的註冊中心集成起來，目標是聚合多註冊中心的數據到 Pilot 中，實現打通異構註冊中心（將來也會用於多區域聚合）。
• xDS/UDPA 協議：xDS 協議源自 Envoy，是目前數據平面的事實標準，UDPA 是正在進行中的基於 xDS 協議的標準化版本。Sidecar 基於 xDS/UDPA 協議接入控制平面，咱們還有進一步的設想，但願增強 SDK 方案，向 Istio 的功能靠攏，具體表現爲 SDK 支持 xDS 協議（初期版本先實現最小功能集）。目標是但願在對接控制平面的前提下，應用能夠在 Service Mesh 和 SDK 方案之間自由選擇和遷移。

基於這個思路，咱們給出以下圖所示的解決方案，但願最大限度的整合傳統微服務框架和 Service Mesh。其基本指導原則是：求同存異，保持兼容。

上圖中，藍色部分是通用的功能模塊，咱們但願能夠和社區一塊兒共建。紅色部分是不兼容的功能模塊，可是保持 API 兼容。

具體說，右邊是各類註冊中心（配置中心同理）：

• Galley 和底下的 k8s API Server 能夠視爲一個特殊的註冊中心，這是 Istio 的官方方式；
• Nacos/SOFARegistry 是阿里集團和螞蟻金服的註冊中心，支持海量規模。咱們計劃添加 MCP 協議的支持，直接對接 Pilot；
• 其餘的註冊中心，也能夠經過提供 MCP 協議支持的方式，接入到這個方案中；
• 對於不支持 MCP 的註冊中心，能夠經過開發一個 MCP Proxy 模塊以適配器模式的方式間接接入。固然最理想的狀態是出現成熟的通用開源方案來統一解決，好比 Nacos Sync 有計劃作相似的事情；

左邊是數據平面：

• Service Mesh 體系下的 Sidecar（如 Envoy 和螞蟻金服的 SOFAMosn）目前都已經支持 xDS/UDPA；
• 相對來講，這個方案中比較「腦洞」的是在 SDK 方案如 Spring Cloud/Dubbo/SOFARPC 中提供 xDS 的支持，以便對接到已經彙總了全局數據的控制平面。從這個角度說，支持 xDS 的 SDK 方案，也能夠視爲廣義的數據平面。咱們但願後面能夠推進社區朝這個方向推動，短時間能夠先簡單對接，實現 xDS 的最小功能集；長期但願 SDK 方案的功能能向 Istio 看齊，實現更多的 xDS 定義的特性；
• 這個方案對運行平臺沒有任何特別要求，只要網絡能通，應用和各個組件能夠靈活選擇運行在容器（k8s）中或虛擬機中。

須要特別強調的是，這個方案最大的優勢在於它是一個高度標準化的社區方案：經過 MCP 協議和 xDS 協議對具體實現進行了解耦和抽象，整個方案沒有綁定到任何產品和供應商。所以，咱們但願這個方案不只僅能夠用於阿里集團和螞蟻金服，也能夠用於整個 Istio 社區。阿里集團和螞蟻金服目前正在和 Istio 社區聯繫，咱們計劃將這個方案貢獻出來，並努力完善和增強 Pilot 的能力，使之可以知足咱們上面提到的的美好願景：融合控制平面和傳統註冊中心 / 配置中心的優勢，打通傳統微服務框架和 Service Mesh，讓應用能夠平滑遷移靈活演進。

但願社區承認這個方案的同窗能夠參與進來，和咱們一塊兒努力來建設和完善它。

4、是否採用 Service Mesh 的建議

在過去一年間，這個問題常常被人問起。借這個機會，結合過去一年中的實踐，以及相比去年此時更多的心得和領悟，但願能夠給出一些更具參考價值的建議。

（一）建議一：有沒有直接痛點

有沒有短時間急迫需求，一般取決於當前有沒有迫切須要解決的痛點。

在 Service Mesh 的發展過程當中，有兩個特別清晰而直接的痛點，它們甚至對 Service Mesh 的誕生起了直接的推進做用：

1.多語言支持

這是 SDK 方案的自然侷限，也是 Service Mesh 的自然優點。須要支持的編程語言越多，爲每一個編程語言開發和維護一套 SDK 的成本就越高，就有越多的理由採用 Service Mesh。

2.類庫升級困難

一樣，這也是 SDK 方案的自然侷限，也是 Service Mesh 的自然優點（還記得前面那個不科學的 -7% 嗎？）。SDK 方案中類庫和業務應用打包在一塊兒，升級類庫就不得不更新整個業務應用，並且是須要更新全部業務團隊的全部應用。在大部分公司，這一般是一個很是困難的事情，並且每次 SDK 升級都要重複一次這種痛苦。

並且，這兩個痛點有可能會同時存在：有多個編程語言的類庫須要升級版本......

因此，第一個建議是先檢查是否存在這兩個痛點。

（二）建議二：老應用升級改造

Service Mesh 的無侵入性，在老應用升級改造，尤爲是但願少改代碼甚至徹底不改代碼的狀況下，堪稱神器。

因此，第二個建議是，若是有老應用無改動升級改造的需求，對流量控制、安全、可觀測性有訴求，則能夠考慮採用 Service Mesh。

（三）建議三：維護統一的技術棧

這個建議僅僅適用於技術力量相對薄弱的企業，這些企業廣泛存在一個問題：技術力量不足，或者主要精力投放在業務實現，致使無力維護統一的技術棧，系統呈現煙囪式架構。

傳統煙囪式架構的常見問題有：

• 重複建設，重複造輪子；
• 不一樣時期，不一樣廠商，用不一樣的輪子；
• 難以維護和演進，後續成本高昂；
• 掌控力不足，容易受制於人；

這種狀況下，建議引入 Service Mesh 技術，經過 Service Mesh 將非業務邏輯從應用剝離並下沉的特性，來統一整個公司的技術棧。

特別須要強調的是，對於技術力量不足、嚴重依賴外包和採購的企業，尤爲是銀行 / 保險 / 證券類金融企業，引入 Service Mesh 會有一個額外的特殊功效，相當重要：

將乙方限制在業務邏輯的實現上

即企業自行建設和控制 Service Mesh，做爲統一的技術棧，在其上再開發運行業務應用。因爲這些業務應用運行在 Servcie Mesh 之上，所以只須要實現業務邏輯，非業務邏輯的功能由 Servcie Mesh 來提供。經過這種方式，能夠避免乙方公司借項目機會引入各類技術棧而形成技術棧混亂，致使後期維護成本超高；尤爲是要避免引入私有技術棧，由於私有技術棧會形成對甲方事實上的技術綁定（甚至技術綁架）。

（四）建議四：雲原生落地

最後一個建議，和雲原生有關。在去年的 QCon 演講中，我曾經提到咱們在探索 Kubernetes / Service Mesh / Serverless 結合的思路。在過去一年，螞蟻金服一直在雲原生領域作深度探索，也有一些收穫。其中，有一點咱們是很是明確的：Mesh 化是雲原生落地的關鍵步驟。

下圖展現了螞蟻金服在雲原生落地方面的基本思路：

• 最下方是雲，以 Kubernetes 爲核心，關於這一點社區基本已經達成共識：Kubernetes 就是雲原生下的操做系統；
• 在 Kubernetes 之上，是 Mesh 層。不只僅有咱們熟悉的 Service Mesh，還有諸如 Database Mesh 和 Message Mesh 等相似的其餘 Mesh 產品形態，這些 Mesh 組成了一個標準化的通訊層；
• 運行在各類 Mesh 的應用，無論是微服務形態，仍是傳統非微服務形態，均可以藉助 Mesh 的幫助實現應用輕量化，非業務邏輯的各類功能被剝離到 Mesh 中後，應用得以「瘦身減負」；
• 瘦身以後的應用，其內容主要是業務邏輯實現。這樣的工做負載形式，更適合 Serverless 的要求，爲接下來轉型 Serverless 作好準備；

因此，個人最後一個建議是，請結合你的長遠發展方向考慮：若是雲原生是你的詩和遠方，那麼 Service Mesh 就是必由之路。

Kubernetes / Service Mesh / Serverless 是當下雲原生落地實踐的三駕馬車，相輔相成，相得益彰。

（五）Service Mesh 的核心價值

在最後，重申一下 Service Mesh 的核心價值：

實現業務邏輯和非業務邏輯的分離。

前面的關於要不要採用 Service Mesh 四個建議，歸根到底，最終都是對這個核心價值的延展。只有在分離業務邏輯和非業務邏輯並以 Sidecar 形式獨立部署以後，纔有了這四個建議所依賴的特性：

• Service Mesh 的多語言支持和應用無感知升級；
• 無侵入的爲應用引入各類高級特性如流量控制，安全，可觀測性；
• 造成統一的技術棧；
• 爲非業務邏輯相關的功能下沉到基礎設施提供可能，幫助應用輕量化，使之專一於業務，進而實現應用雲原生化。

但願你們在理解 Service Mesh 的核心價值以後，再來權衡要不要採用 Service Mesh，也但願我上面給出的四個建議能夠對你們的決策有所幫助。

5、總結

在今天的內容中，首先介紹了螞蟻金服 Service Mesh 的發展歷程，給你們展現了雙十一大規模落地的規模和性能指標，並解釋了這些指標背後的原理。而後分享了螞蟻金服在 Service Mesh 大規模落地中遇到的困難和挑戰，以及咱們爲此作的工做，重點介紹了應用平滑遷移的所謂「終極方案」；最後結合螞蟻金服在雲原生和 Service Mesh 上的實踐心得，對因而否應該採用 Service Mesh 給出了幾點建議。

目前螞蟻金服正在靜待今年的雙十一大考，這將是 Service Mesh 的歷史時刻：全球最大規模的 Service Mesh 集羣，Service Mesh 首次超大規模部署...... 一切都是如此的值得期待。

請對 Service Mesh 感興趣的同窗稍後繼續關注，預期在雙十一以後會有一系列的分享活動：

• 經驗分享：會有更多的技術分享，包括落地場景，經驗教訓，實施方案，架構設計…
• 開源貢獻：螞蟻金服會將落地實踐中的技術實現和方案以不一樣的方式回饋社區，推進 Service Mesh 落地實踐。目前這個工做正在實質性的進行中， 請留意咱們稍後公佈的消息；
• 商務合做：螞蟻金服即將推出 Service Mesh 產品，提供商業產品和技術支持，提供金融級特性，歡迎聯繫；
• 社區交流：ServiceMesher 技術社區繼續承擔國內 Service Mesh 佈道和交流的重任；歡迎參加咱們今年正在持續舉辦的 Service Mesh Meetup 活動。

今年是我在 QCon 演講的第三年，這三年中的三次演講，能夠說是從一個側面反映了國內 Service Mesh 發展的不一樣階段：

2017 年，國內 Service Mesh 一片蠻荒的時候，我作了 Service Mesh 的佈道，介紹了 Service Mesh 的原理，喊出了「下一代微服務」的口號。

2018 年，以螞蟻金服爲表明的國內互聯網企業，陸陸續續開始了 Service Mesh 的落地探索，所謂摸着石頭過河不外如是。第二次演講我分享了螞蟻金服的探索性實踐，介紹了螞蟻金服的 Service Mesh 落地方式和思路。

今天，2019 年，第三次演講，螞蟻金服已經創建起了全球最大規模的 Service Mesh 集羣並準備迎接雙十一的嚴峻挑戰，此次的標題也變成了深度實踐。

從佈道，到探索，再到深度實踐，一路走來已經是三年，國內的 Service Mesh 發展，也從籍籍無名，到煊赫一時，再到理性迴歸。Service Mesh 的落地，依然還存在很是多的問題，距離普及還有很是遠的路要走，然而 Service Mesh 的方向，已經被愈來愈多的人瞭解和承認。

高曉鬆說："生活不止眼前的苟且，還有詩和遠方"。對於 Service Mesh 這樣的新技術來講，也是如此。

2020 年，螞蟻金服將繼續推動和擴大 Service Mesh 落地的規模，繼續引領 Service Mesh 在金融行業的實踐探索。但願明年，能夠有更多更深刻的內容帶給你們！

6、做者介紹

敖小劍，螞蟻金服高級技術專家，十七年軟件開發經驗，微服務專家，Service Mesh 佈道師，ServiceMesher 社區聯合創始人。專一於基礎架構和中間件，Cloud Native 擁護者，敏捷實踐者，堅守開發一線打磨匠藝的架構師。曾在亞信、愛立信、惟品會等任職，目前就任螞蟻金服，在中間件團隊從事 Service Mesh/ Serverless 等雲原生產品開發。