文｜趙真靈（花名：有濟）螞蟻集團技術(shù)專家 劉晶（花名：飛廉） 螞蟻集團技術(shù)專家

以下內(nèi)容整理自 SOFAStack 四周年的分享

SOFAServerelss 研發(fā)運維平臺是螞蟻集團隨著業(yè)務(wù)發(fā)展、研發(fā)運維的復(fù)雜性和成本不斷增加的情況下，為幫助應(yīng)用又快又穩(wěn)地迭代而研發(fā)。從細化研發(fā)運維粒度和屏蔽基礎(chǔ)設(shè)施的角度出發(fā)，演進出的一套解決方案。

核心方式是通過類隔離和熱部署技術(shù)，將應(yīng)用從代碼結(jié)構(gòu)和開發(fā)者陣型拆分為兩個層次：業(yè)務(wù)模塊和基座，基座為業(yè)務(wù)模塊提供計算環(huán)境并屏蔽基礎(chǔ)設(shè)施，模塊開發(fā)者不感知機器、容量等基礎(chǔ)設(shè)施，專注于業(yè)務(wù)研發(fā)幫助業(yè)務(wù)快速向前發(fā)展。

背 景

當前 Serverless 的發(fā)展有兩個演進方向，一個是從面向函數(shù)計算的架構(gòu)往在線應(yīng)用演進，另一種是面向在線應(yīng)用的架構(gòu)往類函數(shù)計算方向演進。

SOFAServerless 體系選擇了后者，是從面向應(yīng)用研發(fā)運維過程中遇到的一些問題展開的。在應(yīng)用架構(gòu)領(lǐng)域，不可避免的問題是應(yīng)用隨著業(yè)務(wù)的復(fù)雜度不斷增加，研發(fā)運維的過程中的問題會不斷暴露出來。

首先我們先看一下對于普通應(yīng)用，研發(fā)和運維過程中的流程是什么樣的？

如圖所示，從需求到設(shè)計、開發(fā)、線下測試，再到發(fā)布線上的研發(fā)運維不斷反饋、循環(huán)迭代的過程。可以簡化為開發(fā)同學(xué)提交代碼到代碼倉庫，在線下做并行的驗證測試，測試通過之后在線上發(fā)布，發(fā)布過程是串行的，只能夠有一個發(fā)布窗口，這樣的過程在應(yīng)用體量業(yè)務(wù)還不太復(fù)雜的情況下問題，并不是很明顯。

但當業(yè)務(wù)復(fù)雜度不斷增加，普通應(yīng)用迭代過程在會出現(xiàn)一些新的問題，如下圖：

管理成本高：需求管理、代碼管理、人員管理

時間成本高：線上驗證與發(fā)布互相阻塞；單次啟動慢

變更風(fēng)險高：一次變更涉及所有代碼； 一次變更涉及所有機器

可擴展性不夠

另外，由于這些問題是因為多業(yè)務(wù)單元與研發(fā)任務(wù)耦合在某些單點上導(dǎo)致的，這些研發(fā)運維的成本隨著業(yè)務(wù)的復(fù)雜度，呈現(xiàn)出指數(shù)增長的特點。

SOFAServerless 研發(fā)運維體系解決方案介紹

對于這些問題，業(yè)界已經(jīng)發(fā)展并演進出了多種應(yīng)用架構(gòu)，從單體架構(gòu) -> 垂直架構(gòu) -> SOA 架構(gòu) -> 分布式微服務(wù)架構(gòu) -> 服務(wù)網(wǎng)格架構(gòu)等，我們分析這些演進過程為解決遇到的研發(fā)運維問題提出 SOFAServerless 研發(fā)運維體系，主要的核心思路是：

1.研發(fā)運維力度的細化

通過細化的方式，讓多人協(xié)作之間不互相 block；迭代的范圍變小，速度變快。

2.屏蔽基礎(chǔ)設(shè)施

屏蔽基礎(chǔ)設(shè)施，讓業(yè)務(wù)開發(fā)同學(xué)只關(guān)注代碼服務(wù)和流量。

對于這兩點，我們采用了 SOFAArk ClassLoader 類隔離和熱部署能力，將應(yīng)用拆分成基座和模塊。

基座和模塊

從這張圖里面可以看到我們拆分的形態(tài)，把一個普通的 JVM 應(yīng)用拆出多個模塊，進一步對模塊進行了一些分工：基座和模塊，對應(yīng)的研發(fā)人員也分為基座開發(fā)者和模塊開發(fā)者。

基座沉淀通用的邏輯，為模塊提供計算和環(huán)境，并會模塊開發(fā)者屏蔽基礎(chǔ)設(shè)施，讓模塊開發(fā)者不需要關(guān)心容量、資源、環(huán)境。各個模塊是獨立的代碼倉庫，可以進行獨立的研發(fā)運維，這樣研發(fā)運維粒度得到細化，并且由于基座為模塊屏蔽了環(huán)境與基礎(chǔ)設(shè)施，模塊開發(fā)者可以專注業(yè)務(wù)開發(fā)，提高整體效率。

如何共享和通信

應(yīng)用如果只是做拆分，沒有共享和通信能力是不完整的方案也難以解決實際問題。對于共享和通信，基座作為共享的一層，能幫模塊預(yù)熱 RPC 數(shù)據(jù)庫緩存通用類、通用方法、通用邏輯，可以供安裝一些模塊去復(fù)用。這樣模塊實現(xiàn)得比較輕，所以模塊的部署密度也可以做得很高。

對于模塊通信，當前模塊之間的通信可以支持任意的通信方式，比如說基座調(diào)模塊、模塊調(diào)基座模塊和模塊之間調(diào)用。由于模塊通信是 JVM 內(nèi)跨 ClassLoader 調(diào)用，與普通 JVM 內(nèi)方法調(diào)用增加了序列化與反序列化的開銷，目前這部分開銷已經(jīng)優(yōu)化到約等于 JVM 內(nèi)部的方法調(diào)用。

在這一能力建設(shè)之后，可以較大降低模塊的接入改造成本并擴大可適用的業(yè)務(wù)范圍。

如何解決業(yè)務(wù)痛點

管理成本

相較于原來的研發(fā)模式，研發(fā)人員拆分成不同小組，代碼倉庫也拆分出多個模塊倉庫，并且可以獨立并行發(fā)布到線上，整個 pipelien 都可以做到獨立進行。

如此一來，需求管理、代碼管理、人員管理的成本就得到下降了，線上發(fā)布過程中也不會再有互相阻塞的問題存在。

當然這些成本下降不代表這些問題完全沒有了，只是從原來的指數(shù)增長轉(zhuǎn)變成了這種線性增長。隨業(yè)務(wù)的復(fù)雜度不斷增加，它的收益會更加的明顯。

時間成本

相對于普通應(yīng)用的鏡像構(gòu)建需要 3 分鐘，發(fā)布需要鏡像下載、啟動、掛載流量大概 3 分鐘，總共平均需要 6 分鐘；模塊構(gòu)建只需要 10 秒，啟動大概 1~10 秒（模塊大小可大可小，對于較小的模塊，速度可以做到毫秒級別）。

把一次發(fā)布耗時從原來的 6 分鐘下降到 15 秒，一次迭代從原來 2 周下降到了 2 天，最快可以 5 分鐘上線的。

可擴展性

對于線上集群的部署形態(tài)，不同的機器上部署的模塊不盡相同。例如對于模塊 1，只安裝在了第一第二臺機器上，那么模塊升級時只會涉及到這兩臺機器本身，變更的機器范圍就比較小了。另外，模塊 1 如果要擴容的話，可以從集群內(nèi)篩選出較空閑的機器進行模塊熱部署即可，一般也就是 10s 級別，所以能做大快速的水平擴展能力。

變更風(fēng)險

對于一次模塊的升級變更，只會涉及模塊自身的代碼本身，不會涉及整個應(yīng)用代碼。模塊變更需要更新的機器也只是模塊安裝過的機器本身，不會涉及到整個集群，所以變更范圍大大縮小，變更風(fēng)險也相較普通應(yīng)用能得到明顯減少。

高可用和配套能力

SOFAServerless 體系在解決業(yè)務(wù)研發(fā)運維痛點基礎(chǔ)上，建設(shè)了高可用和配套的能力。

資源隔離

資源隔離體現(xiàn)在單個 JVM 內(nèi)部的，這里采用了我們公司內(nèi)部 AliJDK 多租戶隔離能力，每一個模塊可以指定自己的資源使用的上限。

比如說，其中一個模塊的邏輯有一些問題，消耗的資源比較大，不會影響到其他的模塊，相當于得到了故障的隔離。

流量隔離能力

對于單個集群內(nèi)部，我們做了一些精細化的流量路由。主要是因為發(fā)服務(wù)時能夠動態(tài)增加 tag，流量路由時能夠配一些規(guī)則，推送到 MOSN、Layotto 里，能讓流量根據(jù)對應(yīng)的 tag 進行一些精細化路由，這樣就具備了流量的精細化路由和流量隔離能力。

可觀測性能力與變更防御能力

具備模塊粒度的健康檢查、資源監(jiān)控、日志監(jiān)控還有排障能力，在此基礎(chǔ)上建設(shè)模塊粒度的變更防御。

一個模塊可以同時存在多個版本，可以做一些快速的 A/B 測試、灰度、回滾這些能力。

業(yè)務(wù)的落地形態(tài)

SOFAServerless 發(fā)展到現(xiàn)在，已經(jīng)在螞蟻內(nèi)部接入了 700 多個 Java、nodejs 應(yīng)用，基本涵蓋了螞蟻所有業(yè)務(wù)線，支撐了 1 萬多次的完整的生產(chǎn)研發(fā)迭代。線下可以做到秒級發(fā)布，支付寶應(yīng)用內(nèi)很多業(yè)務(wù)就是跑在 SOFAServerless 上的，比如投放展位、公益游戲、營銷玩法。

去年 SOFAServerless 成功支撐了 618、雙 12、五福等重量級大促和活動，經(jīng)受住了大流量高并發(fā)場景下的考驗，托管在 SOFAServerless 的資源規(guī)模峰值在 22 萬核左右。

SOFAArk 的核心能力有兩個：

一、把應(yīng)用拆分成更細粒度的基座和模塊

各自生命周期獨立，研發(fā)運維操作解耦，提高協(xié)作效率。

二、分離了『代碼部署』、『服務(wù)注冊』

實現(xiàn)了類似 FaaS 觸發(fā)器的概念，即可以先安裝模塊，但不發(fā)布任何服務(wù)，而是在運行時接收指令，動態(tài)完成服務(wù)的發(fā)布/注銷，整個過程不需要代碼改動、應(yīng)用重啟，耗時只有幾秒。

這樣一來，『服務(wù)』自身變成了獨立靈活輕量的運維單元，業(yè)務(wù)可以按需快速『拆分』服務(wù)，圍繞『服務(wù)』進行更精細化的治理，比如將一個流量大的服務(wù)按來源拆成多個小服務(wù)隔離部署，或?qū)⒁恍┐我摹㈦x線的服務(wù)從原來應(yīng)用中拆出來，專門部署到一個集群，避免影響線上正式業(yè)務(wù)。如果基于之前『應(yīng)用』的研發(fā)運維模型要實現(xiàn)上述效果是相當繁瑣的，可能還會涉及到代碼變更，而現(xiàn)在成本大大下降，業(yè)務(wù)同學(xué)只需在界面上簡單配置一下即可。

基于這兩個能力，不同的業(yè)務(wù)的落地形態(tài)是不一樣的。根據(jù)我們的經(jīng)驗，一般來說有三種，從簡單到復(fù)雜依次是：『代碼片段』、『模塊應(yīng)用』和『中臺型業(yè)務(wù)』。

在職責(zé)劃分、研發(fā)流程上均有較大差異。

代碼片段

這種形態(tài)下模塊非常簡單，極簡情況下可能只有一小段代碼、一個類，承載一小段計算邏輯。基座對外暴露統(tǒng)一接口，所有流量進來之后會先由基座承載，進而分發(fā)到不同模塊執(zhí)行。同時基座還會提供一些通用的底層能力供模塊調(diào)用。這種形態(tài)和目前主流 FaaS 產(chǎn)品比較接近，適合形態(tài)比較簡單的業(yè)務(wù)，如計算型業(yè)務(wù)、BFF，它的研發(fā)流程相對比較簡單，甚至可能沒有迭代的概念，可以隨時改動測試一把，立馬發(fā)布上線。

模塊應(yīng)用

顧名思義，每個模塊獨立承載一個稍微復(fù)雜、比較獨立的業(yè)務(wù)，直接對外提供服務(wù)。基座一般不暴露服務(wù)，只為上層模塊提供基礎(chǔ)能力。模塊應(yīng)用適合同一個業(yè)務(wù)域內(nèi)的多個小業(yè)務(wù)，大量的底層能力可以共享。研發(fā)模式上跟傳統(tǒng)應(yīng)用類似，只不過研發(fā)對象變成了輕量的模塊，而不是一整個大的應(yīng)用。不同模塊之間的研發(fā)流程完全解耦，避免了發(fā)布卡點、等待、環(huán)境搶占等協(xié)作上的問題。

中臺型業(yè)務(wù)

模塊不會直接對外提供服務(wù)，只會提供原子組件，組件是對基座暴露的擴展點的實現(xiàn)。基座會承接所有的流量，通過統(tǒng)一的對外接口暴露服務(wù)，收到調(diào)用后再串聯(lián)編排模塊里的組件，完成一次完整的業(yè)務(wù)邏輯的執(zhí)行。

中臺業(yè)務(wù)是目前最復(fù)雜的形態(tài)，一方面它需要模塊成組做發(fā)布運維，業(yè)務(wù)和模塊是多對多關(guān)系，研發(fā)過程中涉及到多個模塊同時發(fā)布、一個模塊同時發(fā)布到多個業(yè)務(wù)，需要好好設(shè)計相關(guān)流程體驗；另一方面它用到了動態(tài)拆分服務(wù)的特性，不同業(yè)務(wù)基于基座提供的同一套接口，各自獨立發(fā)布服務(wù)。

案例-模塊應(yīng)用-社交游戲

社交游戲是模塊應(yīng)用的典型案例，模塊承載不同的小游戲，具有不同的生命周期，業(yè)務(wù)上可以快速試錯頻繁迭代，又不會互相影響。不同游戲通用的邏輯、基礎(chǔ)設(shè)施下沉到基座，比如通用模型、統(tǒng)一的存儲依賴/下游依賴、事件驅(qū)動框架等等，相對穩(wěn)定，迭代較慢。資源層面每個小游戲有一套獨立集群部署，集群內(nèi)的 Pod 不會安裝其他模塊。

模塊應(yīng)用不管從研發(fā)還是運維層面，都相對簡單。

案例-中臺業(yè)務(wù)-營銷玩法

營銷玩法是一個典型的中臺系統(tǒng)，它負責(zé)營銷整個支付寶 APP 內(nèi)的日常、大促的營銷活動，整體架構(gòu)如下：

從下往上看，基座除了提供營銷相關(guān)的通用服務(wù)，最核心的是流程引擎，它根據(jù)一筆調(diào)用的業(yè)務(wù)屬性定位到對應(yīng)流程模板，編排模塊內(nèi)的組件執(zhí)行。模塊按玩法組織，提供原子組件，由不同的業(yè)務(wù)團隊開發(fā)，其中通用模塊是中臺同學(xué)維護的，提供不同玩法都可能會用到的通用組件，這樣劃分下來模塊變得非常輕量，構(gòu)建后的 Jar 小于 1M，啟動時間 5s 內(nèi)。

最后，上層業(yè)務(wù)按需要將多個模塊組合起來，并通過基座的統(tǒng)一接口發(fā)布自己的服務(wù)。

以『助力玩法』為例，它需要的組件由助力玩法模塊、通用模塊提供，同時會基于基座提供的接口（PlayTriggerFacade）發(fā)布打上了『助力玩法』標簽的 RPC 服務(wù)。更具體一點，當我們發(fā)布『助力玩法』這個業(yè)務(wù)時，可以簡單理解成將助力玩法、通用模塊兩個模塊安裝到基座上，再推送指令給基座，發(fā)布帶有『助力玩法』標簽的 RPC 服務(wù)。

一旦我們在研發(fā)、服務(wù)層面，按照業(yè)務(wù)進行了拆分，就可以很方便地做業(yè)務(wù)之間的資源隔離和資源調(diào)度。

線上劃分兩個業(yè)務(wù)集群，『網(wǎng)商銀行集群』只安裝網(wǎng)商助力玩法相關(guān)模塊，發(fā)布網(wǎng)商助力玩法的服務(wù)，『日常營銷集群』則部署夏至玩法、翻牌玩法兩個業(yè)務(wù)。

同時我們在上游應(yīng)用的 sidecar（MOSN）里實現(xiàn)了業(yè)務(wù)解參和服務(wù)路由能力，這樣上游調(diào)用時看到的是統(tǒng)一的 PlayTriggerFacade 接口，不用任何代碼改造。但最終在 MOSN 按配置的業(yè)務(wù)規(guī)則，將流量正確路由到玩法中臺相應(yīng)集群。

Ark 技術(shù)棧下，集群間的資源騰挪是個很輕量的操作。如果要從『網(wǎng)商銀行集群』騰挪 Pod 到『日常營銷集群』，不需要重啟進程，只需要將 Pod 上的模塊、服務(wù)都卸載掉變成空基座，更改 Pod 和集群的歸屬關(guān)系，再將新模塊、服務(wù)部署上去即可，整個過程耗時在 10s 內(nèi)。如果的確需要從 0 到 1 拉起新 Pod，我們也提供了一個 buffer 池來繞過基座重啟的耗時，集群縮容的資源會先進入 buffer 池，并不直接銷毀，其他集群擴容時可以直接從 buffer 池借調(diào)資源。

目前集群伸縮需要人工決策和觸發(fā)，還不夠智能。今年，我們會重點建設(shè)自動化彈性伸縮、非對等部署模式、機器冷啟動優(yōu)化等能力，讓業(yè)務(wù)只關(guān)注服務(wù)的實例數(shù)和伸縮策略，提供更 Serverless 的體驗。

玩法中臺雙 12 期間完全接入了 SOFAServerless，從大促研發(fā)開始到活動結(jié)束，相關(guān)模塊線上發(fā)布 15 次，線下發(fā)布了 737 次，平均耗時小于 10 秒，做到了『改完即發(fā)，發(fā)完即測』，這對業(yè)務(wù)的開發(fā)聯(lián)調(diào)是一個極大的提效。同時整個研發(fā)周期內(nèi)只改動了雙 12 玩法相關(guān)的模塊，對其他玩法沒有影響。

總結(jié)

最后再簡單總結(jié)一下 SOFAServerless 相對其他 Serverless 產(chǎn)品的核心技術(shù)優(yōu)勢：

1.遷移成本低
普通的 SOFABoot、SpringBoot 應(yīng)用只需增加一些 starter 依賴即可接入 SOFAServerless 體系，擁有熱部署模塊、動態(tài)發(fā)布服務(wù)的能力，而如果要將存量 Java 應(yīng)用遷移到其他 FaaS 產(chǎn)品，將面臨極大的改造成本；

2.進程內(nèi)多模塊合并部署的形態(tài)，更適合表達復(fù)雜業(yè)務(wù)邏輯

3.秒級研發(fā)部署，通信開銷幾乎零增加，部署密度更高，成本降低

相對其他 Serverless 產(chǎn)品，我們實現(xiàn)了進程內(nèi)多模塊的合并部署，并沒有采用 1 Pod 1 模塊的方式，好處是模塊間是進程內(nèi)通信，無通信開銷，拆分后一筆調(diào)用可能涉及到模塊、基座間幾十次調(diào)用。如果走 Pod 間跨進程通信或者遠程 RPC，帶來的開銷是不可接受的。此外還能做到更高的部署密度，一些長尾、流量很低的業(yè)務(wù)可以密集地部署到同一批 Pod 上，成本更低；

4.低成本精細化流量隔離，路由對上游無感
可以利用動態(tài)發(fā)布服務(wù)的能力，在不改代碼的前提下將原來粗粒度的服務(wù)拆的更細，低成本實現(xiàn)業(yè)務(wù)資源隔離，更精細化地治理流量，而這一切對上游是無感的，無需任何改造。

SOFAArk 關(guān)于開源

SOFAArk 2.0 框架已經(jīng)發(fā)布了，相對于 1.0 我們在 ClassLoader 體系、運行時性能、啟動速度等諸多方面都做了較大的升級和優(yōu)化，有興趣的同學(xué)可以訪問 GitHub 倉庫翻閱源碼。
https://github.com/sofastack/sofa-ark

同時 SOFAServerless 整套研發(fā)運維體系相關(guān)的組件也在逐漸開源中，我們將在 10 月份落地第一個開源版本，包括 Serverless 管控平臺、Ark Scheduler 兩個系統(tǒng)。

我們也在積極擁抱開源社區(qū)，開源版本將支持 SpringBoot 應(yīng)用模塊化熱部署的發(fā)布運維能力，能夠?qū)硬渴鹪谠?Kubernetes Deployment 之上的基座應(yīng)用。

最后，希望大家踴躍參與到 SOFAServerless 技術(shù)體系的開源能力建設(shè)，一起幫助業(yè)界應(yīng)用平滑開啟 Serverless 研發(fā)體驗！

總結(jié)

以上是生活随笔為你收集整理的SOFAServerless 体系助力业务极速研发的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。