螞蟻金服 Service Mesh 大規模落地系列 - RPC 篇

螞蟻金服雲原生負責人魯直 雙十一後首次線下分享

引言

Service Mesh 是螞蟻金服下一代架構的核心，本主題主要分享在螞蟻金服當前的體量下，咱們如何作到在奔跑的火車上換輪子，將現有的 SOA（service-oriented architecture，面向服務的架構）體系快速演進至 Service Mesh 架構。聚焦 RPC 層面的設計和改造方案，本次將分享螞蟻金服雙十一核心應用是如何將現有的微服務體系平滑過渡到 Service Mesh 架構下並下降大促成本。

螞蟻金服每一年雙十一大促會面臨很是大的流量挑戰，在已有 LDC（Logical Data Center，邏輯數據中心，是螞蟻金服原創的一種「異地多活單元化架構」實現方案）微服務架構下已支撐起彈性擴容能力。本次分享主要分爲 5 部分：

• Service Mesh 簡介；
• 爲何要 Service Mesh；
• 方案落地；
• 分時調度案例；
• 思考與將來；

做者簡介

黃挺（花名：魯直）：螞蟻金服雲原生負責人
主要 Focus 領域：

• SOFAStack 微服務領域；
• Service Mesh，Serverless 等雲原生領域；

雷志遠（花名：碧遠）：螞蟻金服 RPC 框架負責人
主要 Focus 領域：

• 服務框架：SOFARPC（已開源）；
• Service Mesh：MOSN（已開源）；

SOFARPC：https://github.com/sofastack/sofa-rpc

MOSN：https://github.com/sofastack/sofa-mosn

Service Mesh 簡介

在講具體的螞蟻金服落地以前，想先和你們對齊一下 Service Mesh 的概念，和螞蟻金服對應的產品。這張圖你們可能不陌生，這是業界廣泛承認的 Service Mesh 架構，對應到螞蟻金服的 Service Mesh 也分爲控制面和數據面，分別叫作 SOFAMesh 和 MOSN，其中 SOFAMesh 後面會以更加開放的姿態參與到 Istio 裏面去。

今天咱們講的實踐主要集中在 MOSN 上，如下個人分享中提到的主要就是集中在數據面上的落地，這裏面你們能夠看到，咱們有支持 HTTP/SOFARPC/Dubbo/WebService。

爲何咱們要 Service Mesh

有了一個初步的瞭解以後，可能你們都會有這樣一個疑問，大家爲何要 Service Mesh，我先給出結論：

由於咱們要解決在 SOA 下面，沒有解決但亟待解決的：基礎架構和業務研發的耦合，以及將來無限的對業務透明的穩定性與高可用相關訴求。

那麼接下來，咱們一塊兒先看看在沒有 Service Mesh 以前的情況。

在沒有 Service Mesh 以前，整個 SOFAStack 技術演進的過程當中，框架和業務的結合至關緊密，對於一些 RPC 層面的需求，好比流量調度，流量鏡像，灰度引流等，是須要在 RPC 層面進行升級開發支持，同時，須要業務方來升級對應的中間件版本，這給咱們帶來了一些困擾和挑戰。如圖所示：

1. 線上客戶端框架版本不統一；
2. 業務和框架耦合，升級成本高，不少需求因爲在客戶端沒法推進，須要在服務端作相應的功能，方案不夠優雅；
3. 機器逐年增長，若是不增長機器，如何度過雙十一；
4. 在基礎框架準備完成後，對於新功能，再也不升級給用戶的 API 層是否可行；
5. 流量調撥，灰度引流，藍綠髮布，AB Test 等新的訴求；

這些都困擾着咱們。咱們知道在 SOA 的架構下，負責每一個服務的團隊均可以獨立地去負責一個或者多個服務，這些服務的升級維護也不須要其餘的團隊的接入，SOA 其實作到了團隊之間能夠按照接口的契約來接耦。可是長期以來，基礎設施團隊須要推進不少事情，都須要業務團隊進行緊密的配合，幫忙升級 JAR 包，基礎設施團隊和業務團隊在工做上的耦合很是嚴重，上面提到的各類問題，包括線上客戶端版本的不一致，升級成本高等等，都是這個問題帶來的後果。

而 Service Mesh 提供了一種可能性，可以將基礎設施下沉，讓基礎設施團隊和業務團隊可以解耦，讓基礎設施和業務均可以更加快步地往前跑。

咱們的方案

說了這麼多，那咱們怎麼解決呢？咱們經歷了這樣的選型思考。

整體目標架構

咱們的 MOSN 支持了 Pilot、自有服務發現 SOFARegistry 和自有的消息組件，還有一些 DB 的組件。在產品層，提供給開發者不一樣的能力，包括運維、監控、安全等能力，這個是目前咱們的一個線上的狀態。

SOFARegistry 是螞蟻金服開源的具備承載海量服務註冊和訂閱能力的、高可用的服務註冊中心，在支付寶/螞蟻金服的業務發展驅動下，近十年間已經演進至第五代。

看上去很美好，要走到這個狀態，咱們要回答業務的三個靈魂拷問。

這三個問題後面，分別對應着業務的幾大訴求，你們作過基礎框架的應該比較有感觸。

框架升級方案

準備開始升級以後，咱們要分析目前咱們的線上狀況，而咱們如今線上的狀況，應用代碼和框架有必定程度的解耦，用戶面向的是一個 API，最終代碼會被打包，在 SOFABoot 中運行起來。

SOFABoot 是螞蟻金服開源的基於 Spring Boot 的研發框架，它在 Spring Boot 的基礎上，提供了諸如 Readiness Check，類隔離，日誌空間隔離等能力。在加強了 Spring Boot 的同時，SOFABoot 提供了讓用戶能夠在 Spring Boot 中很是方便地使用 SOFA 中間件的能力。

那麼，咱們就能夠在風險評估可控的狀況下，直接升級底層的 SOFABoot。在這裏，咱們的 RPC 會檢測一些信息，來肯定當前 Pod 是否須要開啓 MOSN 的能力。而後咱們完成以下的步驟。

咱們經過檢測 PaaS 傳遞的容器標識，知道本身是否開啓了 MOSN，則將發佈和訂閱給 MOSN，而後調用再也不尋址，直接完成調用。

能夠看到，經過批量的運維操做，咱們直接修改了線上的 SOFABoot 版本，以此，來直接使得現有的應用具有了 MOSN 的能力。有些同窗可能會問，那你一直這麼作不行嗎？不行，由於這個操做是要配合流量關閉等操做來運行的，也不具有平滑升級的能力，並且直接和業務代碼強相關，不適合長期操做。

這裏咱們來詳細回答一下，爲何不採用社區的流量劫持方案？

主要的緣由是一方面 iptables 在規則配置較多時，性能下滑嚴重。另外一個更爲重要的方面是它的管控性和可觀測性很差，出了問題比較難排查。螞蟻金服在引入 Service Mesh 的時候，就是以全站落地爲目標的，而不是簡單的「玩具」，因此咱們對性能和運維方面的要求很是高，特別是形成業務有損或者資源利用率降低的狀況，都是不能接受的。

容器替換方案

解決了剛剛提到的第一個難題，也只是解決了能夠作，而並不能作得好，更沒有作得快，面對線上數十萬帶着流量的業務容器， 咱們如何馬上開始實現這些容器的快速穩定接入？

這麼大的量，按照傳統的替換接入顯然是很耗接入成本的事情，因而咱們選擇了原地接入，咱們能夠來看下二者的區別：

在以前，咱們作一些升級操做之類的，都是須要有必定的資源 Buffer，而後批量的進行操做，替換 Buffer 的不斷移動，來完成升級的操做。這就要求 PaaS 層留有很是多的 Buffer，可是在雙十一的狀況下，咱們要求不增長機器，而且爲了一個接入 MOSN 的操做，反而須要更多的錢來買資源，這豈不是背離了咱們的初衷。有人可能會問，不是仍是增長了內存和 CPU 嗎，這是提升了 CPU 利用率。之前業務的 CPU 利用率很低，而且這個是一個相似超賣的方案，看上去分配了，實際上基本沒增長。

能夠看到， 經過 PaaS 層，咱們的 Operator 操做直接在現有容器中注入，並原地重啓，在容器級別完成升級。升級完成後，這個 Pod 就具有了 MOSN 的能力。

MOSN 升級方案

在快速接入的問題完成後，咱們要面臨第二個問題。因爲是大規模的容器，因此 MOSN 在開發過程當中，勢必會存在一些問題，出現問題，如何升級？要知道線上幾十萬容器要升級一個組件的難度是很大的，所以，在版本初期，咱們就考慮到 MOSN 升級的方案。

能想到最簡單的方法，就是銷燬容器，而後用新的來重建，可是在容器數量不少的時候，這種運維成本是不可接受的。若是銷燬容器重建的速度不夠快，就可能會影響業務的容量，形成業務故障。所以，咱們在 MOSN 層面，和 PaaS 一塊兒，開發了無損流量升級的方案。

在這個方案中，MOSN 會感知本身的狀態，新的 MOSN 啓動會經過共享卷的 Domain Socket 來檢測是否已有老的 MOSN 在運行，若是有，則通知原有 MOSN 進行平滑升級操做。

具體來講，MOSN 啓動的時候查看同 Pod 是否有運行的 MOSN (經過共享卷的 Domain Socket)，若是存在，須要進入以下流程：

• New MOSN 通知 Old MOSN，進入平滑升級流程；
• Old MOSN 把服務的 Listen Fd 傳遞給 New MOSN，New MOSN 接收 Fd 以後啓動， 此時 Old 和 New MOSN 都正常提供服務；
• 而後 New MOSN 通知 Old MOSN，關閉 Listen Fd，而後開始遷移存量的長連接；
• Old MOSN 遷移完成， 銷燬容器；

這樣，咱們就能作到，線上作任意的 MOSN 版本升級，而不影響老的業務，這個過程當中的技術細節，不作過多介紹，以後，本號會有更詳細的分享文章。

分時調度案例

技術的變革一般必定不是技術自己的訴求，必定是業務的訴求，是場景的訴求。沒有人會爲了升級而升級，爲了革新而革新，一般，技術受業務驅動，也反過來驅動業務。

在阿里經濟體下，在淘寶直播，實時紅包，螞蟻森林，各類活動的不斷擴張中，給技術帶了複雜的場景考驗。

這個時候，業務同窗每每想的是什麼？個人量快撐不住了，個人代碼已經最優化了，我要擴容加機器。而更多的機器付出更多的成本，面對這樣的狀況，咱們以爲應用 Service Mesh 是一個很好的解法。經過和 JVM、系統部的配合，利用進階的分時調度實現靈活的資源調度，不加機器。這個能夠在資源調度下有更好的效果。

首先，咱們假設有兩個大的資源池的資源需求狀況，能夠看到在 x 點的時候，資源域 A 須要更多的資源，Y 點的時候，資源域 B 須要更多的資源，總量不得增長。那固然，咱們就但願能借調機器。就像下面這樣。請你們看左圖。

在這個方案中， 咱們須要先釋放資源，而後銷燬進程，而後開始重建資源，而後啓動資源域 B 的資源。這個過程對於大量的機器是很重的，並且變動就是風險，關鍵時候作這種變動，頗有可能帶來衍生影響。

而在 MOSN 中，咱們有了新的解法。如右圖所示，有一部分資源一直經過超賣，運行着兩種應用，可是 X 點的時候，對於資源域 A，咱們經過 MOSN 來將流量所有轉走，應用的 CPU 和內存就被限制到很是低的狀況，大概保留 1% 的能力。這樣操做，機器依然能夠預熱，進程也不停。

在這裏，咱們能夠看這張圖。

在須要比較大的資源調度時，咱們推送一把開關，則資源限制打開，包活狀態取消。資源域 B 瞬間能夠滿血復活。而資源域 A 此時進入上一個狀態，CPU 和內存被限制。在這裏，MOSN 以一個極低的資源佔用完成流量保活的能力，使得資源的快速借調成爲可能。

咱們對 Service Mesh 的思考與將來

Service Mesh 在螞蟻金服通過 2 年的沉澱，最終通過雙十一的檢驗，在雙十一，咱們覆蓋了數百個雙十一交易核心鏈路，MOSN 注入的容器數量達到了數十萬，雙十一當天處理的 QPS 達到了幾千萬，平均處理 RT<0.2 ms，MOSN 自己在大促中間完成了數十次的在線升級，基本上達到了咱們的預期，初步完成了基礎設施和業務的第一步的分離，見證了 Mesh 化以後基礎設施的迭代速度。

不論何種架構，軟件工程沒有銀彈。架構設計與方案落地老是一種平衡與取捨，目前還有一些 Gap 須要咱們繼續努力，可是咱們相信，雲原生是遠方也是將來，通過咱們兩年的探索和實踐，咱們也積累了豐富的經驗。

咱們相信，Service Mesh 可能會是雲原生下最接近「銀彈」的那一顆，將來 Service Mesh 會成爲雲原生下微服務的標準解決方案，接下來螞蟻金服將和阿里集團一塊兒深度參與到 Istio 社區中去，一塊兒和社區把 Istio 打形成 Service Mesh 的事實標準。

今天的分享就到這裏，感謝你們。若是有想交流更多的，歡迎參與到社區裏來，尋找新技術帶來更多業務價值。

SOFAStack：https://github.com/sofastack

本次分享 PPT 以及回顧視頻：點擊「這裏」

螞蟻金服 Service Mesh 大規模落地系列文章

• 螞蟻金服 Service Mesh 大規模落地系列-運維篇
• 螞蟻金服 Service Mesh 大規模落地系列-消息篇
• 螞蟻金服 Service Mesh 大規模落地系列-核心篇
• Service Mesh 落地負責人親述：螞蟻金服雙十一四大考題

公衆號：金融級分佈式架構（Antfin_SOFA）