螞蟻金服 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 以及回顧視訊：點選“ 這裡”

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69904796/viewspace-2671349/，如需轉載，請註明出處，否則將追究法律責任。