本文整理自 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互聯網架構大會，螞蟻科技平臺數據技術事業群技術專家石建偉（花名：卓與）的分享。分享基于 Service Mesh 的理念，結合螞蟻科技內部實際場景，將中間件、數據層、安全層等能力從應用中剝離出來后下沉至獨立的 Sidecar SOFAMosn 中，結合 Kubernetes 運維體系，提供應用無感知的情況下升級基礎設施層能力的案例。

本次分享將從以如下次序展開進行：

| 螞蟻科技當前的服務化現狀

在看螞蟻科技的服務化架構之前我們先從一個簡單的服務化調用示例說起，下圖是 SOFARPC 基本原理：

圖1. SOFARPC 基本原理

我們從上圖可以看出，構建一個服務化框架需要有服務注冊中心，有服務定義，調用方和服務提供方使用相同的服務定義來互相通訊。通過服務注冊中心，調用方可以直接訂閱到服務提供方的地址，采用點對點的方式直接發起請求。客戶端內可實現服務發現、路由尋址、負載均衡、限流熔斷等能力來增強服務通訊能力。通過我們開源的 SOFARPC、SOFARegistry、SOFABoot，用戶已經可以直接構建起微服務體系，助力業務發展。

螞蟻科技發展至今，雙 11 系統需要應對的交易洪峰逐年遞增：

圖2. 歷年雙 11 交易額與峰值數據

每秒 26.5 萬筆交易是 2017 年雙 11 的峰值數據，這個數據背后有非常復雜的架構支持，LDC 單元化架構是螞蟻科技沉淀多年的核心架構，依靠這個架構實現每年峰值交易量飛速增長下系統依然能平滑渡過。我們來簡要看下 LDC 架構：

圖3. LDC 架構示例

上圖摘自 金融級分布式架構 中的?素描單元化?一文，這里不詳細展開。LDC 的單元化架構給應用的服務化帶來更多的規范與抽象，服務路由中需要考慮單元間的調用，跨機房調用等更多場景。這里主要希望表達的是 LDC 架構給 RPC 調用帶來更高的復雜度。

| 服務化痛點

中間件版本升級

在上面介紹背景時，有介紹到目前 LDC 架構下服務調用的復雜度，這些復雜度目前是直接體現在應用的代碼中。對于業務同學來講，一個應用的關注重點是如何實現業務邏輯，至于高可用、容災等能力更多是整體架構層面會考慮的點。應用內通過引入 RPC 的 jar 包即可獲得 LDC 架構下服務調用各種能力的支撐，帶來便利的同時也可以看到這種模式的缺點：

圖4. APP 業務與 SDK 組成部分

應用內除業務邏輯之外，由中間件的 SDK 引入大量外部依賴，來完成服務發現、路由尋址、負載均衡、限流熔斷、序列化、通訊等能力，每個組件的引入都可能帶來穩定性風險，以及更高的升級成本。

圖5. SDK 內不同能力對應的依賴

根據目前 SOFARPC 在內部的版本舉例，服務發現依賴 SOFARegistry 的客戶端做 IDC 內的服務發現，依賴 Antvip 做跨 IDC 的服務發現，ZoneClient 集成 LDC 架構的單元化信息，路由尋址需要根據請求的入參計算目前 Zone 然后確定調用目標，限流熔斷依賴 Guardian 組件，通訊協議與序列化協議相對穩定，變更較少。僅為了完成服務調用，應用需要額外引入 7+ 客戶端包。

每年雙 11 需要涉及到架構調整時：比如支持彈性架構，需要做很多中間件客戶端的版本升級來支撐更優的架構，對于業務同學來講，這些升級是很耗費精力的，拿 200 個核心應用舉例，每個應用升級中間件版本經過研發、測試、再到部署預發、灰度、生產等環境需要 5個人日的話，200 個核心應用中間件升級需要耗費 1000 人日，如果這部分時間可以節省出來，每年架構升級可以節約大量人力資源。

跨語言通訊

螞蟻科技發展至今，內部業務百花齊放，搜索推薦、人工智能、安全等各種業務使用到的技術棧非常多樣化，跨語言的服務通訊能力也十分重要。早在幾年前，Java 之外規模最大的就是 NodeJS 應用，為了讓 Java 和 NodeJS 應用之間可以復用螞蟻科技內部的各種中間件和基礎設施，前端團隊使用 NodeJS 逐步重寫了各種中間件客戶端，讓整個 NodeJS 和 Java 體系可以完美互通。

圖6. Java 與 NodeJS 互調

中間件 SDK 跨語言重寫與維護成本極高，隨著語言種類的增多，跨語言通訊的訴求也越來越多。

圖7. 多語言場景

Java, NodeJS, Go, Python, C++ 等，5+ 語言，中間件 SDK 全部重寫成本極高。這些問題不得不激勵我們尋找更優的解法。

| 解決痛點

SDK 能力下沉

圖8. SDK 瘦身并下沉能力至 Sidecar

依然以上述 RPC SDK 舉例，SDK 中的能力我們可以根據穩定性與不可剝離等特性來看，哪些是可以從應用中抽出來的，盡量把 SDK 做薄，做的足夠穩定無需變更，那么升級成本將不復存在。

圖9. SDK 與 Sidecar 對應的依賴

RPC SDK 中的服務發現、路由尋址、限流熔斷等特性，是更易于變更的，我們將這部分能力下沉至獨立的 Sidecar 中，可以復用這部分能力，讓多語言的 SDK 只實現最基本的序列化與通訊協議，而這些能力是很輕量且易于實現的。這里的 Sidecar 我們是希望它作為獨立進程存在，和業務應用的進程剝離，并和業務應用的升級解耦開來，實現業務和基礎設施并行發展，互不干擾的愿景。

圖10. RPC 消息與數據源能力下沉

除了 RPC 通訊，我們還可以下沉消息、數據源等能力至 Sidecar 中，業務應用可以越來越薄，SDK 實現成本也降低到可接受的程度，基礎設施層與業務剝離，雙方均可獨立演進。

| 落地架構

整體架構

圖11. Mesh 落地架構

不同于開源的 Istio 體系，螞蟻科技內部版 Service Mesh 落地優先考慮數據面的實現與落地，控制面在逐步建設中，整體的架構上看，我們使用數據面直接和內部的各種中間件服務端對接，來完成 RPC、消息等能力的下沉，給業務應用減負。由上圖可以看出，我們將不同的 Sidecar 與業務應用編排在同一個 Pod 中，App 與 SOFAMosn 直接通訊，SOFAMosn 來負責目標接口的服務發現、路由尋址，并且由 SOFAMosn 內置的安全模塊來做應用間調用的加密鑒權。通過 DBMesh 的 Sidecar 來實現數據層的下沉，App 不在需要與多個數據源建立連接，只需要連接本 Pod 內的 DBMesh 即可完成數據層調用，數據庫的用戶名、密碼、分庫分表規則等均不再需要關心。

圖中名詞解析：

• ConfigServer：配置中心，負責各種元數據配置、動態開關等

• Registry：服務注冊中心，負責 IDC 內服務發現

• AntVip：類 DNS 解析的產品，可通過域名解析一組目標地址，用于跨 IDC 服務發現

• MQ：消息中心服務端，用于收發消息

落地數據

圖12. 落地 CPU 數據

目前這套架構已經在支付核心鏈路中做試點，618 大促 Mesh 化應用對比無 Mesh 化應用 CPU 損耗增長 1.7%，單筆交易整體耗時增長 5ms。CPU 增長是由于多出一個進程，請求增加一條之后，RT 會有穩定的小幅增長，但這些成本相比于整體架構帶來的紅利，微乎其微，并且針對整個數據面的持續優化是有望逐步減少資源占用，提升資源利用率。

降低打擾度

中間件能力下沉在架構上看是可行的，實際落地如何做到無打擾的在奔跑的火車上換輪子，低打擾是一個非常重要的考量點。借助于 Kubernetes 的優秀實踐，將業務容器與 Sidecar 容器編排在同一個 Pod 中是比較合理的架構，Sidecar 與業務容器互不干擾，互相升級均可做到雙方無感。

圖13. 落地方式

我們為了讓業務應用升級盡可能如絲般順滑，主要做了如下優化方案：

1. 無感鏡像化

螞蟻科技內部還有部分應用未完成鏡像化，或者說以富容器的方式來使用鏡像化，這種方式也是在逐步淘汰的過程中，為了讓業務更順滑的鏡像化，PAAS 平臺聯動整個研發體系，將應用的打包過程通過自動生成 Dockerfile 的方式主動幫用戶完成鏡像化。做到用戶無感知鏡像化改造。

2. 低感 Mesh 化

鏡像化完成之后，想要借助 Pod 模型將應用的容器和 SOFAMosn 的容器部署在一起，我們需要將底層資源管理與調度全部替換到 Kubernetes 體系。然后在 PAAS 上給 Mesh 化的應用增加標識，通過 Kubernetes 識別這些標識并主動注入 SOFAMosn sidecar 來完成應用的 Mesh 化接入。

3. 無感 Sidecar 升級

Sidecar 與業務進程獨立后，還有一個核心的訴求就是希望 Sidecar 可以獨立升級，為了讓 Sidecar 的升級盡量對生產做到無打擾，我們實現了 SOFAMosn 平滑升級的 Operator，通過對運行中 SOFAMosn 的連接遷移，實現整個升級過程應用完全無感知。當然這里面包含著很多挑戰，后面我們會詳細介紹。

| 落地挑戰

Sidecar 平滑升級

目前我們已經實現 SOFAMosn 的平滑升級能力，SOFAMosn 的主要能力是 RPC 和 消息的通訊代理，平滑升級的目的是業務 App 進程不重啟，業務請求不中斷，完成 SOFAMosn 的版本升級。

圖14. SOFAMosn 平滑升級

由于SOFAMosn 與應用是獨立的 container，如上圖描述，SOFAMosn 的升級是需要做到 Pod 內鏡像的熱替換，這種熱替換能力必須要保障幾點：

Pod 不會被重建，應用進程始終正常運行

鏡像的替換不會影響運行中的流量

鏡像替換后整個 Pod 描述需要進行更新

為了達成以上目標，我們通過對 Kubernetes 的改造以及自定義 Operator 來完成以上升級的處理。處理流程如下：

圖15. SOFAMosn 平滑升級流程

在不考慮多鏡像間做平滑升級的場景下，通過 Fork 進程，可以繼承父進程的 FD 來完成長連接的遷移，實現無損熱升級。SOFAMosn 以鏡像化的方式運行后，平滑升級的難度極大增加。整個平滑升級的難點在于如何讓不同容器內的SOFAMosn 進程可互相感知并可完成連接遷移。

下面我們來看下SOFAMosn 升級過程中，如何保障流量無損：

圖16. 正常流量走向

SOFAMosn 處理的正常流量分為入口流量和出口流量，Client 可以看成和SOFAMosn 部署在同 Pod 內的 App，Server 可以是請求調用的目標服務提供方，可以是一個 App 也可以是被調用 App 側的SOFAMosn。當一筆請求從 Client 發至 Server 時，中間會經過兩條長連接：TCP1 和 TCP2，SOFAMosn 會記錄這筆請求對應的 ConnectionID，來完成請求的發起與響應。

圖16. 正向流量遷移

當新的 Mosn 容器被啟動時，Mosn 會根據本地的 Domain Socket 來嘗試發送請求，當另一個 Mosn 進程存在時，Mosn V1 和 Mosn V2 進入熱升級模式，Mosn V1 會將已存在連接的 FD 和已讀出的數據包 通過 Domain Socket 發送至 Mosn V2 同時 V1 將不會再從已遷移的 FD 中讀取數據，FD 遷移完成所有流量將會直接由 Mosn V2 來處理。

圖17. 逆向流量遷移

Mosn V1 和 Mosn V2 進入熱升級模式之后，可能會存在 Mosn V1 已經將請求發給 Server 后 Server 還沒有來得及響應的情況，這種場景 Mosn V1 在遷移 FD 給 Mosn V2 時，Mosn V2 會在 FD 接管到之后的 ConnectionID 返回給 Mosn V1，當 Mosn V1 收到 Server 返回的 Response 之后，會將這筆請求通過 Domain Socket 發送給 Mosn V2，然后 Mosn V2 根據 ConnectionId 即可找到 TCP1 的連接，然后響應給 Client。

極致性能優化

圖18. 請求合并寫

SOFAMosn 的核心網絡模型是完全自實現的，我們在整個網絡層做了非常多的優化，通過 golang 的 writev 我們把多筆請求合并成一次寫，降低 sys.call 的調用，提升整體的性能與吞吐。同時在使用 writev 的過程中，有發現 golang 對 writev 的實現有 bug，會導致部分內存無法回收，我們給 golang 提交 PR 修復此問題，已被接受：https://github.com/golang/go/pull/32138?

其他優化點還有很多，不再一一詳細描述，僅供思路參考，如：

• SOFAMosn 日志異步化，避免磁盤問題對 SOFAMosn 轉發性能的影響

• Route 路由結果緩存，空間換時間，提升吞吐

• 接近 90% 內存復用，盡量避免字節拷貝

• Cluster 懶加載，提升 SOFAMosn 啟動速度

• 通訊協議層優化，低版本協議針對性升級，降低解包成本

| 演進方向

圖19. 演進方向控制面結合

Service Mesh 的控制面建設我們也在規劃中逐步向前推進，希望能統一數據面和控制面的交互模型，控制面盡量遵循 SMI 標準，增加對 TCP 協議的描述支持，逐步增強 SOFAMosn 作為數據面的穩定性，減少變更頻率，用更通用的模型來描述服務發現、服務治理等場景，DBMesh 也會基于 XDS 做配置的下發，統一又控制面收口數據下發通道。這里控制面直接對接中間件的服務端是基于性能與容量考慮，螞蟻科技內部的服務發現數據達單機房千萬級別，使用 Kubernetes 的 ETCD 無法承載如此巨大的數據量，需要又控制面做橋梁并分片服務于不同的數據面。

圖20. 產品化模型

接下來還會有完整的產品層建設，借助于 Mesh 化架構的思想，更多的能力希望通過下沉至 Sidecar 的方式來拿到架構升級帶來的紅利。Mesh 的產品層將會包括多種 Mesh 數據面形態的 Metrics 采集、監控大盤，控制面的統一對外途徑，屏蔽外部系統與 Mesh 的交互復雜度，統一控制面與數據面交互協議，通過完善的運維體系建設，提升 Mesh 模式下的 Sidecar 灰度升級能力，做到對應用無打擾且穩定無人值守即可完成版本升級的目的。

| 總結

總結一下全文在 Service Mesh 領域的落地實踐，可以歸納為以下六點：

• 應用層與基礎設施層分離

• 基礎設置層一次編寫多處復用

• 數據面通過能力平移優先落地

• 降低打擾度提升落地效率

• 控制面建設統一數據面配置模型

• 性能、穩定性、可觀測性持續優化

本文介紹了螞蟻科技在 Service Mesh 落地的演進過程以及相關痛點的解決方式，希望可以通過我們的實際經歷來為讀者帶來一些不同與社區主流方案的演進思考。

總結

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

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