[[268510]]

AWS Lambda 是 Serverless 領(lǐng)域的標(biāo)志性產(chǎn)品，但如果將其應(yīng)用于核心業(yè)務(wù)，可能會(huì)遇到以下難題：(僅代表作者個(gè)人觀點(diǎn))

• 要求用戶以 Function 為單位進(jìn)行開發(fā)，全新的開發(fā)框架，云廠商強(qiáng)綁定，社區(qū)主流技術(shù)棧遷移成本高;
• Function 啟動(dòng)速度要足夠快，毫秒級(jí)或者秒級(jí)，這個(gè)限制對(duì)適用場(chǎng)景有很強(qiáng)的約束;
• Function 之間的調(diào)用通過 API Gateway，響應(yīng)時(shí)間更長(zhǎng)。

Cloud Service Engine 云服務(wù)引擎(以下簡(jiǎn)稱CSE)，是阿里云中間件團(tuán)隊(duì)開發(fā)的面向通用 Serverless 計(jì)算的中間件產(chǎn)品，目的是具備 AWS Lambda 的各種優(yōu)勢(shì)，同時(shí)可以解決用戶在使用 AWS Lambda 時(shí)遇到的難題。

什么是 Serverless?

AWS 對(duì) Serverless 定義是：(摘自 AWS 官網(wǎng))

AWS 無服務(wù)器平臺(tái)提供的功能：(摘自 AWS 官網(wǎng))

AWS 的整套 Serverless 方案非常完善，但是沒有解決存量應(yīng)用如何遷移到 Serverless 架構(gòu)的問題。僅僅是針對(duì)新開發(fā)的應(yīng)用，建議用戶使用 FaaS 方式開發(fā)，才有機(jī)會(huì)轉(zhuǎn)向 Serverless 架構(gòu)。筆者認(rèn)為，要將 Serverless 架構(gòu)大規(guī)模推廣，必須要能有針對(duì)存量業(yè)務(wù)的解決方案。

Serverless 對(duì)云計(jì)算的價(jià)值

云計(jì)算，歸根結(jié)底是一種 IT 服務(wù)提供模式，不論是公共云還是專有云(以 IT 設(shè)備的歸屬不同分類)，其本質(zhì)都是幫助 IT 的最終使用者隨時(shí)隨地，并且簡(jiǎn)便快速地，獲取 IT 服務(wù)，目前，IaaS、PaaS 都已經(jīng)做到了按需付費(fèi)，PaaS 甚至做到了按請(qǐng)求付費(fèi)，如 DB，CACHE，MQ 等，但是 IaaS 的付費(fèi)粒度仍然是時(shí)間維度，最快按照小時(shí)付費(fèi)，以分鐘來交付。

因此，當(dāng)下的云計(jì)算場(chǎng)景，應(yīng)用的開發(fā)維護(hù)方式相比傳統(tǒng) IDC 時(shí)代的開發(fā)維護(hù)，差別還不是很大。但 AWS Lambda 提供了一種全新的開發(fā)維護(hù)方式，用戶只需要寫好業(yè)務(wù)代碼，提交到云上，所有和機(jī)器容量、可用性、機(jī)器為單位的運(yùn)維工作可以全部交給了云平臺(tái)，這種模式極大地釋放了云的彈性價(jià)值，真正做到了按需付費(fèi)。

CSE 試圖提供一種更規(guī)?；慕鉀Q方案，像 AWS Lambda 一樣，能進(jìn)一步釋放云的彈性價(jià)值，并且可以平滑遷移存量應(yīng)用。

存量在線業(yè)務(wù)實(shí)現(xiàn) Serverless 架構(gòu)的挑戰(zhàn)

存量在線應(yīng)用程序具有以下特點(diǎn)：

• 資源分配速度 = 分鐘級(jí)
• 應(yīng)用程序啟動(dòng)速度 = 10分鐘+

基于以上客觀條件，通常做法是提前預(yù)定好機(jī)器數(shù)量來應(yīng)對(duì)任意時(shí)刻的流量峰值，假設(shè)上述技術(shù)參數(shù)變?yōu)楹撩爰?jí)，就有機(jī)會(huì)將應(yīng)用程序架構(gòu)演變成下圖所示方式。

上圖中，Service A 在調(diào)用 Service B 時(shí)，如果 B 的容量充足，則調(diào)用成功;如果 B 的容量不足，這時(shí)候如果線程池滿，則直接觸發(fā)限流閥值，A 會(huì)收到一個(gè)錯(cuò)誤碼，然后直接調(diào)用資源總控系統(tǒng)，資源總控系統(tǒng)負(fù)責(zé)新分配一個(gè) Service B 實(shí)例，這個(gè)分配的速度非?？欤臅r(shí)幾十毫秒，同時(shí)把 B 的服務(wù)地址直接返回給 A，A 會(huì)將之前未完成的請(qǐng)求發(fā)送到新創(chuàng)建的 Service B。

以上過程對(duì)于開發(fā)者完全透明，具備了以下價(jià)值：

• 價(jià)值一：無需管理服務(wù)器，即無需容量評(píng)估;容量評(píng)估這件事情對(duì)于應(yīng)用負(fù)責(zé)人一直是一個(gè)極難解的問題，因?yàn)槲覀兒茈y預(yù)測(cè)未來的峰值是什么。
• 價(jià)值二：持續(xù)擴(kuò)展;之前的做法是每個(gè)應(yīng)用程序獨(dú)占一定數(shù)量的資源，如果變成Serverless 模式，所有應(yīng)用程序可以共享資源池，每個(gè)應(yīng)用程序幾乎可以***擴(kuò)展。
• 價(jià)值三：按照請(qǐng)求計(jì)費(fèi);因?yàn)槊總€(gè)實(shí)例的啟動(dòng)時(shí)間甚至比 FaaS 的函數(shù)啟動(dòng)時(shí)間還快，就可以像 FaaS 一樣來核算成本，成本只與以下因素有關(guān)：
  • 請(qǐng)求數(shù)量(QPS)
  • 每次請(qǐng)求CPU執(zhí)行時(shí)間，例如100ms
  • 每個(gè)實(shí)例的內(nèi)存規(guī)格

綜上所述：為了做到以上描述的分布式架構(gòu)，關(guān)鍵技術(shù)點(diǎn)在于應(yīng)用啟動(dòng)速度，這里的應(yīng)用啟動(dòng)速度是指應(yīng)用可以正常處理流量為止。

如何將應(yīng)用啟動(dòng)速度提高到毫秒級(jí)?

應(yīng)用在啟動(dòng)過程中通常會(huì)初始化多個(gè)組件，如各種中間件、數(shù)據(jù)結(jié)構(gòu)，以及網(wǎng)絡(luò)調(diào)用外部服務(wù)。在阿里內(nèi)部廣泛使用 SOA 和微服務(wù)的情況下，應(yīng)用在啟動(dòng)過程中會(huì)大量加載共享業(yè)務(wù) SDK，存在啟動(dòng)過程達(dá)到10分鐘量級(jí)的情況，個(gè)別應(yīng)用可能會(huì)更長(zhǎng)。因此，這個(gè)啟動(dòng)過程必須提前完成，才有機(jī)會(huì)以“臨陣磨槍”的方式去創(chuàng)建新實(shí)例。

方案一：應(yīng)用冷啟動(dòng)資源壓縮方案

L1 彈性能力是指在一臺(tái)物理機(jī)或者大規(guī)格的 ECS 上部署同一個(gè)應(yīng)用的多個(gè)實(shí)例，通過操作系統(tǒng)和 JVM 的優(yōu)化，一個(gè)占用 4G 內(nèi)存的應(yīng)用，即使部署10份，僅需占用2.2G RAM。

L1 總結(jié)來看是一種高密度部署方式，由于應(yīng)用已經(jīng)提前啟動(dòng)，并且對(duì)容器進(jìn)行凍結(jié)，意味著這個(gè)應(yīng)用實(shí)例 CPU 占用率為0，RAM 占用相當(dāng)于之前的1/20，但是具備了毫秒級(jí)彈性的能力。L1的特點(diǎn)是啟動(dòng)速度極快，但是需要消耗資源，且只能垂直彈性。

L2 是通過將應(yīng)用程序啟動(dòng)后在 RAM 中的指令和數(shù)據(jù)結(jié)構(gòu) dump 到磁盤文件，只需要在機(jī)器之間拷貝文件即可以達(dá)到橫向彈性的能力，這個(gè)時(shí)間消耗主要是數(shù)據(jù)的網(wǎng)絡(luò)傳輸時(shí)間+內(nèi)存拷貝時(shí)間，大約在5秒左右就可以完成。L2 的成本開銷只有網(wǎng)絡(luò)磁盤容量，開銷極低，可忽略不計(jì)。

L2 的每個(gè) SNAOSHOT 對(duì)應(yīng)一個(gè)可運(yùn)行的實(shí)例，例如預(yù)計(jì)一個(gè)應(yīng)用需要***啟動(dòng)100個(gè)實(shí)例，那么需要提前生成100個(gè) SNAOSHOT，每個(gè) SNAOSHOT 對(duì)應(yīng)一個(gè)運(yùn)行實(shí)例，需要啟動(dòng)時(shí)，從遠(yuǎn)程磁盤加載這個(gè) SNAPSHOT。

此方案通過 L1 和 L2 的組合來達(dá)到加速應(yīng)用啟動(dòng)的目的，在支持一定流量脈沖能力下，可以***50ms內(nèi)啟動(dòng)任意應(yīng)用，平均在10ms內(nèi)完成。

方案二：應(yīng)用熱復(fù)制啟動(dòng)加速方案

L1 采用通過 fork 種子進(jìn)程達(dá)到快速啟動(dòng)的效果，操作系統(tǒng)團(tuán)隊(duì)專門為此開發(fā)了 fork2 技術(shù)，與 Linux Native fork 的關(guān)鍵區(qū)別在于可以指定 PID 來 fork 一個(gè)進(jìn)程。

pid_t fork2(pid_t pid); 

L2 的單個(gè) SNAPSHOT 可以創(chuàng)建多個(gè)進(jìn)程，一對(duì)多關(guān)系。

兩種自研方案的對(duì)比

• 方案一：不存在 UUID 問題，但是每種語言的 VM 要單獨(dú)定制，成本效果相比方案二略差。
• 方案二：會(huì)存在 UUID 問題，若開發(fā)者希望應(yīng)用的每個(gè)實(shí)例啟動(dòng)時(shí)，都賦值一個(gè) UUID 給一個(gè)靜態(tài)變量，但通過 fork 會(huì)導(dǎo)致每個(gè)實(shí)例的這個(gè)靜態(tài)變量都相同，這與開發(fā)者預(yù)期不符。方案二的優(yōu)勢(shì)是更易實(shí)現(xiàn)、和語言無關(guān)、成本效果更優(yōu)，適合 FaaS、NBF 這類場(chǎng)景或者開發(fā)者自己定義的開發(fā)框架，能避免 UUID 的問題。

整體來看，方案一的適用場(chǎng)景更廣，但是實(shí)現(xiàn)成本更高，方案二較適合 FaaS、NBF 這類場(chǎng)景。

和 AWS Lambda 相比

Lambda 為了做到快速擴(kuò)縮容，要求用戶的應(yīng)用以 Function 為單位開發(fā)，Lambda Runtime 動(dòng)態(tài)加載 Function 來快速增加實(shí)例。

CSE 則通過將一個(gè)應(yīng)用的多個(gè)實(shí)例啟動(dòng)后，共享相同的指令數(shù)據(jù)，抽取出不同的指令數(shù)據(jù)，每次啟動(dòng)實(shí)例只需要加載多實(shí)例的差異部分。因此可以透明兼容社區(qū)主流技術(shù)棧，如 Spring Boot，PHP/Java/Python/Node.JS 等。

CSE 的成本優(yōu)勢(shì)

理論模型：

Serverless 方式應(yīng)用占用的實(shí)例數(shù)隨時(shí)在變化，因此可以多個(gè)應(yīng)用錯(cuò)峰使用同一臺(tái)機(jī)器。

量化分析：

Serverless 的成本優(yōu)勢(shì)是可以和 CPU Share &離在線混部等調(diào)度技術(shù)的成本優(yōu)勢(shì)做疊加，能給最終用戶一個(gè)更優(yōu)的總體成本。

CSE 的代碼樣例

HSF demo

package com.test.pandora.hsf; 
 
import com.alibaba.boot.hsf.annotation.HSFProvider; 
 
@HSFProvider(serviceInterface = HelloWorldService.class) 
public class HelloWorldServiceImpl implements HelloWorldService { 
    @Override 
    public String sayHello(String name) { 
        return "hello : " + name; 
    } 
} 

Spring Boot demo

package com.example.java.gettingstarted; 
 
import org.springframework.boot.SpringApplication; 
import org.springframework.boot.autoconfigure.SpringBootApplication; 
import org.springframework.web.bind.annotation.RequestMapping; 
import org.springframework.web.bind.annotation.RestController; 
 
@SpringBootApplication 
@RestController 
public class HelloworldApplication { 
  @RequestMapping("/") 
  public String home() { 
    return "Hello World!"; 
  } 
 
 
  @RequestMapping("/health") 
  public String healthy() { 
    // Message body required though ignored 
    return "Still surviving."; 
  } 
 
  public static void main(String[] args) { 
    SpringApplication.run(HelloworldApplication.class, args); 
  } 
} 

CSE 的生產(chǎn)實(shí)踐

某電商業(yè)務(wù) A：Serverless 化后，機(jī)器數(shù)量從11臺(tái)降低到2臺(tái)(2~10臺(tái)之間波動(dòng))，某促銷節(jié)，服務(wù)流量峰值從數(shù)千瞬間飆到十多萬，CSE 瞬間彈性擴(kuò)容，從2臺(tái)-->5臺(tái)-->10臺(tái)，流量峰值回落后又縮容到2臺(tái)。

某電商業(yè)務(wù) B：Serverless 化后，機(jī)器數(shù)量從4臺(tái)到2臺(tái)(2~10臺(tái)之間波動(dòng))。

某電商業(yè)務(wù) C：之前固定4臺(tái)機(jī)器，Serverless 化完成后，機(jī)器數(shù)量變成1臺(tái)(1~4臺(tái)之間波動(dòng))，預(yù)發(fā)可實(shí)現(xiàn)0 - 1臺(tái)實(shí)例之間波動(dòng)。

本文作者：

王小瑞：花名誓嘉，阿里巴巴資深技術(shù)專家，Apache RocketMQ 創(chuàng)始人&Chair，近期負(fù)責(zé)推動(dòng)阿里巴巴在線業(yè)務(wù)向 Serverless 架構(gòu)的演進(jìn)，以及消息中間件產(chǎn)品線的云計(jì)算方向，是阿里巴巴中間件創(chuàng)新項(xiàng)目實(shí)驗(yàn)室&消息中間件團(tuán)隊(duì)負(fù)責(zé)人。