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

以下內容整理自 SOFAStack 四周年的分享

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

核心方式是通過類隔離和熱部署技術，將應用從代碼結構和開發者陣型拆分為兩個層次：業務模塊和基座，基座為業務模塊提供計算環境并屏蔽基礎設施，模塊開發者不感知機器、容量等基礎設施，專注于業務研發幫助業務快速向前發展。

背 景

當前 Serverless 的發展有兩個演進方向，一個是從面向函數計算的架構往在線應用演進，另一種是面向在線應用的架構往類函數計算方向演進。

SOFAServerless 體系選擇了后者，是從面向應用研發運維過程中遇到的一些問題展開的。在應用架構領域，不可避免的問題是應用隨著業務的復雜度不斷增加，研發運維的過程中的問題會不斷暴露出來。

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

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

但當業務復雜度不斷增加，普通應用迭代過程在會出現一些新的問題，如下圖：

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

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

變更風險高：一次變更涉及所有代碼； 一次變更涉及所有機器

可擴展性不夠

另外，由于這些問題是因為多業務單元與研發任務耦合在某些單點上導致的，這些研發運維的成本隨著業務的復雜度，呈現出指數增長的特點。

SOFAServerless 研發運維體系解決方案介紹

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

1.研發運維力度的細化

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

2.屏蔽基礎設施

屏蔽基礎設施，讓業務開發同學只關注代碼服務和流量。

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

基座和模塊

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

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

如何共享和通信

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

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

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

如何解決業務痛點

管理成本

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

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

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

時間成本

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

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

可擴展性

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

變更風險

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

高可用和配套能力

SOFAServerless 體系在解決業務研發運維痛點基礎上，建設了高可用和配套的能力。

資源隔離

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

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

流量隔離能力

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

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

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

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

業務的落地形態

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

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

SOFAArk 的核心能力有兩個：

一、把應用拆分成更細粒度的基座和模塊

各自生命周期獨立，研發運維操作解耦，提高協作效率。

二、分離了『代碼部署』、『服務注冊』

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

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

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

在職責劃分、研發流程上均有較大差異。

代碼片段

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

模塊應用

顧名思義，每個模塊獨立承載一個稍微復雜、比較獨立的業務，直接對外提供服務?；话悴槐┞斗?#xff0c;只為上層模塊提供基礎能力。模塊應用適合同一個業務域內的多個小業務，大量的底層能力可以共享。研發模式上跟傳統應用類似，只不過研發對象變成了輕量的模塊，而不是一整個大的應用。不同模塊之間的研發流程完全解耦，避免了發布卡點、等待、環境搶占等協作上的問題。

中臺型業務

模塊不會直接對外提供服務，只會提供原子組件，組件是對基座暴露的擴展點的實現?；鶗薪铀械牧髁?#xff0c;通過統一的對外接口暴露服務，收到調用后再串聯編排模塊里的組件，完成一次完整的業務邏輯的執行。

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

案例-模塊應用-社交游戲

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

模塊應用不管從研發還是運維層面，都相對簡單。

案例-中臺業務-營銷玩法

營銷玩法是一個典型的中臺系統，它負責營銷整個支付寶 APP 內的日常、大促的營銷活動，整體架構如下：

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

最后，上層業務按需要將多個模塊組合起來，并通過基座的統一接口發布自己的服務。

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

一旦我們在研發、服務層面，按照業務進行了拆分，就可以很方便地做業務之間的資源隔離和資源調度。

線上劃分兩個業務集群，『網商銀行集群』只安裝網商助力玩法相關模塊，發布網商助力玩法的服務，『日常營銷集群』則部署夏至玩法、翻牌玩法兩個業務。

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

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

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

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

總結

最后再簡單總結一下 SOFAServerless 相對其他 Serverless 產品的核心技術優勢：

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

2.進程內多模塊合并部署的形態，更適合表達復雜業務邏輯

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

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

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

SOFAArk 關于開源

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

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

我們也在積極擁抱開源社區，開源版本將支持 SpringBoot 應用模塊化熱部署的發布運維能力，能夠對接部署在原生 Kubernetes Deployment 之上的基座應用。

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

總結

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

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