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

ec723354-2427-4e30-b129-78b6843045c0.jpeg

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

引言

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

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

  • Service Mesh 簡介;

  • 爲什麼要 Service Mesh;

  • 方案落地;

  • 分時調度案例;

  • 思考與未來;

作者簡介

e55e540d-b39a-4f09-a22c-7d4c0668a636.jpeg

黃挺(花名:魯直):螞蟻金服雲原生負責人

主要 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 裏面去。

ad2cd768-39c8-421b-8b8a-01165d0c78e4.png


今天我們講的實踐主要集中在 MOSN 上,以下我的分享中提到的主要就是集中在數據面上的落地,這裏面大家可以看到,我們有支持 HTTP/SOFARPC/Dubbo/WebService。

爲什麼我們要 Service Mesh

有了一個初步的瞭解之後,可能大家都會有這樣一個疑問,你們爲什麼要 Service Mesh,我先給出結論:

因爲我們要解決在 SOA 下面,沒有解決但亟待解決的:基礎架構和業務研發的耦合,以及未來無限的對業務透明的穩定性與高可用相關訴求。

那麼接下來,我們一起先看看在沒有 Service Mesh 之前的狀況。

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

e7548485-b725-44c2-a74e-2b4e3568efcd.png


  1. 線上客戶端框架版本不統一;

  2. 業務和框架耦合,升級成本高,很多需求由於在客戶端無法推動,需要在服務端做相應的功能,方案不夠優雅;

  3. 機器逐年增加,如果不增加機器,如何度過雙十一;

  4. 在基礎框架準備完成後,對於新功能,不再升級給用戶的 API 層是否可行; 

  5. 流量調撥,灰度引流,藍綠髮布,AB Test 等新的訴求;


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

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

8393b97c-75a5-4f52-bec3-6da414ebda71.png

我們的方案

說了這麼多,那我們怎麼解決呢?我們經歷了這樣的選型思考。

1768d235-a5d5-474c-b7ed-f989748f745d.png

總體目標架構


5110a3c5-7ae6-4fe1-8151-a210b34c0d56.png


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

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

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

969dcaf8-295e-43d2-a793-3c79147cbc2a.png


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

框架升級方案


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

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

1565a8d3-daa0-41e8-a01d-aa7baa82ba0d.png


那麼,我們就可以在風險評估可控的情況下,直接升級底層的 SOFABoot。在這裏,我們的 RPC 會檢測一些信息,來確定當前 Pod 是否需要開啓 MOSN 的能力。然後我們完成如下的步驟。

2ebc11d3-82c2-4d7e-9cfd-0c3e9444f9c2.png

我們通過檢測 PaaS 傳遞的容器標識,知道自己是否開啓了 MOSN,則將發佈和訂閱給 MOSN,然後調用不再尋址,直接完成調用。

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

這裏我們來詳細回答一下,爲什麼不採用社區的流量劫持方案?

主要的原因是一方面 iptables 在規則配置較多時,性能下滑嚴重。另一個更爲重要的方面是它的管控性和可觀測性不好,出了問題比較難排查。螞蟻金服在引入 Service Mesh 的時候,就是以全站落地爲目標的,而不是簡單的“玩具”,所以我們對性能和運維方面的要求非常高,特別是造成業務有損或者資源利用率下降的情況,都是不能接受的。

容器替換方案


解決了剛剛提到的第一個難題,也只是解決了可以做,而並不能做得好,更沒有做得快,面對線上數十萬帶着流量的業務容器, 我們如何立刻開始實現這些容器的快速穩定接入?

這麼大的量,按照傳統的替換接入顯然是很耗接入成本的事情,於是我們選擇了原地接入,我們可以來看下兩者的區別:

80cfb637-1584-4d7c-86cd-6648948b0908.png

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

可以看到, 通過 PaaS 層,我們的 Operator 操作直接在現有容器中注入,並原地重啓,在容器級別完成升級。升級完成後,這個 Pod 就具備了 MOSN 的能力。

MOSN 升級方案


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

30e32174-fdf0-4ede-9cd8-103bdf78d742.png

能想到最簡單的方法,就是銷燬容器,然後用新的來重建,但是在容器數量很多的時候,這種運維成本是不可接受的。如果銷燬容器重建的速度不夠快,就可能會影響業務的容量,造成業務故障。因此,我們在 MOSN 層面,和 PaaS 一起,開發了無損流量升級的方案。


e4c2728f-31c9-4392-a7c0-a7e6f5b1f397.png

在這個方案中,MOSN 會感知自己的狀態,新的 MOSN 啓動會通過共享卷的 Domain Socket 來檢測是否已有老的 MOSN 在運行,如果有,則通知原有 MOSN 進行平滑升級操作。

980e078d-e0eb-4dfa-8753-7c632af6ccdb.png



具體來說,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、系統部的配合,利用進階的分時調度實現靈活的資源調度,不加機器。這個可以在資源調度下有更好的效果。

94252741-5269-4351-be19-e92584c1070e.png

首先,我們假設有兩個大的資源池的資源需求情況,可以看到在 X 點的時候,資源域 A 需要更多的資源,Y 點的時候,資源域 B 需要更多的資源,總量不得增加。那當然,我們就希望能借調機器。就像下面這樣。請大家看左圖。

73f10383-b025-474c-813e-313e34d77b31.png

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

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

在這裏,我們可以看這張圖。

19d02d65-c22e-4048-9b58-440d8b397f47.png

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

我們對 Service Mesh 的思考與未來


427e440d-4283-41c0-b748-405dbe2f39aa.png

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 以及回顧視頻:點擊“這裏

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章