阿里巴巴中間件在 Serverless 技術領域的探索

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臺實例之間波動。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。