文｜趙真靈（花名：有濟）螞蟻集團技術專家 劉晶（花名：飛廉） 螞蟻集團技術專家
以下內容整理自 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，它的研發流程相對比較簡單，甚至可能沒有迭代的概念，可以隨時改動測試一把，立馬釋出上線。
模組應用
顧名思義，每個模組獨立承載一個稍微複雜、比較獨立的業務，直接對外提供服務。基座一般不暴露服務，只為上層模組提供基礎能力。模組應用適合同一個業務域內的多個小業務，大量的底層能力可以共享。研發模式上跟傳統應用類似，只不過研發物件變成了輕量的模組，而不是一整個大的應用。不同模組之間的研發流程完全解耦，避免了釋出卡點、等待、環境搶佔等協作上的問題。
中臺型業務
模組不會直接對外提供服務，只會提供原子元件，元件是對基座暴露的擴充套件點的實現。基座會承接所有的流量，通過統一的對外介面暴露服務，收到呼叫後再串聯編排模組裡的元件，完成一次完整的業務邏輯的執行。
中臺業務是目前最複雜的形態，一方面它需要模組成組做釋出運維，業務和模組是多對多關係，研發過程中涉及到多個模組同時釋出、一個模組同時釋出到多個業務，需要好好設計相關流程體驗；另一方面它用到了動態拆分服務的特性，不同業務基於基座提供的同一套介面，各自獨立釋出服務。
案例-模組應用-社交遊戲
社交遊戲是模組應用的典型案例，模組承載不同的小遊戲，具有不同的生命週期，業務上可以快速試錯頻繁迭代，又不會互相影響。不同遊戲通用的邏輯、基礎設施下沉到基座，比如通用模型、統一的儲存依賴/下游依賴、事件驅動框架等等，相對穩定，迭代較慢。資源層面每個小遊戲有一套獨立叢集部署，叢集內的 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/...
同時 SOFAServerless 整套研發運維體系相關的元件也在逐漸開源中，我們將在 10 月份落地第一個開源版本，包括 Serverless 管控平臺、Ark Scheduler 兩個系統。
我們也在積極擁抱開源社群，開源版本將支援 SpringBoot 應用模組化熱部署的釋出運維能力，能夠對接部署在原生 Kubernetes Deployment 之上的基座應用。
最後，希望大家踴躍參與到 SOFAServerless 技術體系的開源能力建設，一起幫助業界應用平滑開啟 Serverless 研發體驗！