Serverless 話題涉及範圍極廣，幾乎包含了程式碼管理、測試、釋出、運維和擴容等與應用生命週期關聯的所有環節。AWS Lambda 是 Serverless 領域的標誌性產品，但如果將其應用於核心業務，可能會遇到以下難題：（僅代表作者個人觀點）首度揭祕：

• 要求使用者以 Function 為單位進行開發，全新的開發框架，雲廠商強繫結，社群主流技術棧遷移成本高；

• Function 啟動速度要足夠快，毫秒級或者秒級，這個限制對適用場景有很強的約束；

• Function 之間的呼叫通過 API Gateway，響應時間更長。

本文將介紹阿里雲中間件團隊在探索 Serverless 過程中的思考以及正在做的事，目的是儘可能讓開發者少改程式碼，甚至不改程式碼，就能具備 AWS Lambda 的技術優勢。

Cloud Service Engine 雲服務引擎（以下簡稱CSE），是阿里雲中間件團隊開發的面向通用 Serverless 計算的中介軟體產品，目的是具備 AWS Lambda 的各種優勢，同時可以解決使用者在使用 AWS Lambda 時遇到的難題。

什麼是 Serverless

AWS 對 Serverless 定義是：（摘自 AWS 官網）

AWS 無伺服器平臺提供的功能：（摘自 AWS 官網）

AWS 的整套 Serverless 方案非常完善，但是沒有解決存量應用如何遷移到 Serverless 架構的問題。僅僅是針對新開發的應用，建議使用者使用 FaaS 方式開發，才有機會轉向 Serverless 架構。筆者認為，要將 Serverless 架構大規模推廣，必須要能有針對存量業務的解決方案。

Serverless 對雲端計算的價值

雲端計算，歸根結底是一種 IT 服務提供模式，不論是公共雲還是專有云（以IT裝置的歸屬不同分類），其本質都是幫助 IT 的最終使用者隨時隨地，並且簡便快速地，獲取 IT 服務，目前，IaaS、PaaS都已經做到了按需付費，PaaS 甚至做到了按請求付費，如DB，CACHE，MQ等，但是 IaaS 的付費粒度仍然是時間維度，最快按照小時付費，以分鐘來交付。

因此，當下的雲端計算場景，應用的開發維護方式相比傳統 IDC 時代的開發維護，差別還不是很大。但 AWS Lambda 提供了一種全新的開發維護方式，使用者只需要寫好業務程式碼，提交到雲上，所有和機器容量、可用性、機器為單位的運維工作可以全部交給了雲平臺，這種模式極大的釋放了雲的彈性價值，真正做到了按需付費。

CSE 試圖提供一種更規模化的解決方案，像 AWS Lambda 一樣，能進一步釋放雲的彈性價值，並且可以平滑遷移存量應用。

存量線上業務實現 Serverless 架構的挑戰

存量線上應用程式具有以下特點

• 資源分配速度 = 分鐘級

• 應用程式啟動速度 = 10分鐘+

基於以上客觀條件，通常做法是提前預定好機器數量來應對任意時刻的流量峰值，假設上述技術引數變為毫秒級，就有機會將應用程式架構演變成下圖所示方式。

上圖中，Service A 在呼叫 Service B 時，如果 B 的容量充足，則呼叫成功；如果 B 的容量不足，這時候如果執行緒池滿，則直接觸發限流閥值，A 會收到一個錯誤碼，然後直接呼叫資源總控系統，資源總控系統負責新分配一個 Service B 例項，這個分配的速度非常快，耗時幾十毫秒，同時把 B 的服務地址直接返回給 A，A 會將之前未完成的請求傳送到新建立的 Service B。

以上過程對於開發者完全透明，具備了以下價值：

• 價值一：無需管理伺服器，即無需容量評估；容量評估這件事情對於應用負責人一直是一個極難解的問題，因為我們很難預測未來的峰值是什麼。

• 價值二：持續擴充套件；之前的做法是每個應用程式獨佔一定數量的資源，如果變成Serverless 模式，所有應用程式可以共享資源池，每個應用程式幾乎可以無限擴充套件。

• 價值三：按照請求計費；因為每個例項的啟動時間甚至比 FaaS 的函式啟動時間還快，就可以像 FaaS 一樣來核算成本，成本只與以下因素有關

  • 請求數量（QPS）

  • 每次請求CPU執行時間，例如100ms

  • 每個例項的記憶體規格

綜上所述：為了做到以上描述的分散式架構，關鍵技術點在於應用啟動速度，這裡的應用啟動速度是指應用可以正常處理流量為止。

如何將應用啟動速度提高到毫秒級？

應用在啟動過程中通常會初始化多個元件，如各種中介軟體、資料結構，以及網路呼叫外部服務。在阿里內部廣泛使用 SOA 和微服務的情況下，應用在啟動過程中會大量載入共享業務 SDK，存在啟動過程達到10分鐘量級的情況，個別應用可能會更長。因此，這個啟動過程必須提前完成，才有機會以“臨陣磨槍”的方式去建立新例項。

方案一：應用冷啟動資源壓縮方案

L1 彈效能力是指在一臺物理機或者大規格的 ECS 上部署同一個應用的多個例項，通過作業系統和 JVM 的優化，一個佔用 4G 記憶體的應用，即使部署10份，僅需佔用2.2G RAM。

L1 總結來看是一種高密度部署方式，由於應用已經提前啟動，並且對容器進行凍結，意味著這個應用例項 CPU 佔用率為0，RAM 佔用相當於之前的1/20，但是具備了毫秒級彈性的能力。L1的特點是啟動速度極快，但是需要消耗資源，且只能垂直彈性。

L2 是通過將應用程式啟動後在 RAM 中的指令和資料結構 dump 到磁碟檔案，只需要在機器之間拷貝檔案即可以達到橫向彈性的能力，這個時間消耗主要是資料的網路傳輸時間+記憶體拷貝時間，大約在5秒左右就可以完成。L2 的成本開銷只有網路磁碟容量，開銷極低，可忽略不計。

L2 的每個 SNAOSHOT 對應一個可執行的例項，例如預計一個應用需要最大啟動100個例項，那麼需要提前生成100個 SNAOSHOT，每個 SNAOSHOT 對應一個執行例項，需要啟動時，從遠端磁碟載入這個 SNAPSHOT。

此方案通過 L1 和 L2 的組合來達到加速應用啟動的目的，在支援一定流量脈衝能力下，可以最大50ms內啟動任意應用，平均在10ms內完成。

方案二：應用熱複製啟動加速方案

L1 採用通過 fork 種子程序達到快速啟動的效果，作業系統團隊專門為此開發了 fork2 技術，與 Linux Native fork 的關鍵區別在於可以指定 PID 來 fork 一個程序。

pid_t fork2(pid_t pid);

L2 的單個 SNAPSHOT 可以建立多個程序，一對多關係。

兩種自研方案的對比

• 方案一：不存在 UUID 問題，但是每種語言的 VM 要單獨定製，成本效果相比方案二略差。

• 方案二：會存在 UUID 問題，若開發者希望應用的每個例項啟動時，都賦值一個 UUID 給一個靜態變數，但通過 fork 會導致每個例項的這個靜態變數都相同，這與開發者預期不符。方案二的優勢是更易實現、和語言無關、成本效果更優，適合 FaaS、NBF 這類場景或者開發者自己定義的開發框架，能避免 UUID 的問題。

整體來看，方案一的適用場景更廣，但是實現成本更高，方案二較適合 FaaS、NBF 這類場景。

和 AWS Lambda 相比

Lambda 為了做到快速擴縮容，要求使用者的應用以 Function 為單位開發，Lambda Runtime 動態載入 Function 來快速增加例項。

CSE 則通過將一個應用的多個例項啟動後，共享相同的指令資料，抽取出不同的指令資料，每次啟動例項只需要載入多例項的差異部分。因此可以透明相容社群主流技術棧，如Spring Boot，PHP/Java/Python/Node.JS 等。

CSE 的成本優勢

理論模型：

Serverless 方式應用佔用的例項數隨時在變化，因此可以多個應用錯峰使用同一臺機器。

量化分析：

Serverless 的成本優勢是可以和 CPU Share &離線上混部等排程技術的成本優勢做疊加，能給終端使用者一個更優的總體成本。

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 的生產實踐

某電商業務 A：Serverless 化後，機器數量從11臺降低到2臺（2~10臺之間波動），某促銷節，服務流量峰值從數千瞬間飆到十多萬，CSE 瞬間彈性擴容，從2臺-->5臺-->10臺，流量峰值回落後又縮容到2臺。

某電商業務 B：Serverless 化後，機器數量從4臺到2臺（2~10臺之間波動）。

某電商業務 C：之前固定4臺機器，Serverless 化完成後，機器數量變成1臺（1~4臺之間波動），預發可實現0 - 1臺例項之間波動。

本文作者：
王小瑞，花名：誓嘉，阿里巴巴資深技術專家，Apache RocketMQ 創始人&Chair，近期負責推動阿里巴巴線上業務向 Serverless 架構的演進，以及訊息中介軟體產品線的雲端計算方向，是阿里巴巴中介軟體創新專案實驗室&訊息中介軟體團隊負責人。

中介軟體團隊社招：
中介軟體創新專案實驗室&訊息中介軟體團隊正在招聘中介軟體分散式系統研發專家，杭州/北京/深圳，P7/P8/P9，簡歷直達 shijia.wxr#taobao.com 。詳情請點這裡。

本文作者：中介軟體小哥

原文連結

本文為雲棲社群原創內容，未經