CSE：阿里在線應用如何演進成Serverless架構

Cloud Service Engine，簡稱CSE，是中間件部門研發的面向通用Serverless計算的中間件產品，目標是具有AWS Lambda的各類優點，同時能夠解決AWS Lambda的關鍵技術缺陷。

AWS Lambda若是用於核心業務，可能會有如下缺陷：（僅表明我的觀點）

• 要求用戶以Function爲單位開發，全新的開發框架，雲廠商強綁定。社區主流技術棧遷移成本高。
• Function啓動速度要足夠快，毫秒級或者秒級，這個限制對適用場景有很強的約束。
• Function之間的調用經過API Gateway，響應時間更長。

CSE目前在集團內測中，本文非完整產品介紹，Serverless話題涉及範圍極廣，幾乎包含了代碼管理，測試，發佈，運維，擴容等與應用生命週期關聯的全部環節。本文主要回答我的在探索這個方向時的思考以及中間件部門正在作的解決方案，目標是儘量讓開發者少改代碼，甚至不改代碼，就能具有AWS Lambda的技術優點。

我認爲的Serverless是什麼？

AWS對Serverless的定義

以上觀點來自AWS官網  連接

AWS 定義的Serverless包含了哪些功能項

我的的補充觀點

我的對Serverless的觀點僅在AWS上補充，AWS的整個方案很是完善，可是沒有解決存量應用如何遷移到Serverless架構，僅僅針對新開發的應用，建議用戶用FaaS方式開發，纔有機會變成Serverless架構。

要將Serverless架構大規模推廣，必需要能有針對存量業務的解決方案。

Serverless在雲計算中的位置是什麼？

雲計算歸根結底是一種IT服務提供模式，不管是公共雲仍是專有云（以IT設備的歸屬不一樣分類），其本質都是IT的最終使用者能夠隨時隨地而且簡便快速地獲取IT服務，並以獲取服務的層次分爲IaaS、PaaS、SaaS。目前看IaaS、PaaS都已經作到了按需付費。PaaS甚至作到了按請求付費，如DB，CACHE，MQ等，可是IaaS的付費粒度仍然是時間維度，最快按照小時付費，按照分鐘來交付。

基於以上現狀，應用的開發維護方式相比傳統IDC模式的開發維護差異還不是很大，而AWS Lambda提供了一種全新的方式，只須要用戶寫業務代碼，提交到雲上，全部和機器容量，可用性，機器爲單位的運維工做所有交給了雲平臺，這種模式極大的放大了雲的彈性價值，真正作到了按需付費。

本文試圖提供一種更規模化的解決方案，像AWS Lambda同樣，能繼續放大雲的彈性價值，而且是能夠兼容存量應用。

現存在線業務演變成Serverless架構的關鍵挑戰是什麼？

當前的在線應用程序具備如下特色

• 資源分配速度 = 分鐘級
• 應用程序啓動速度 = 10分鐘+

基於以上客觀條件，一般作法是提早預約好機器數量來應對任意時刻的流量峯值，假設上述技術參數變爲毫秒級，就有機會將應用程序架構演變成下圖所示方式。

上圖中Service A在調用Service B時，若是B的容量充足，調用成功，若是B容量不足，這時候多是線程池滿，可能直接觸發限流閥值，A會收到一個錯誤碼，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問題，如開發者但願應用每一個實例啓動都賦值一個UUID給一個靜態變量，而經過fork會致使每一個實例的這個靜態變量都相同，與開發者預期不符。
  優點是整個方案更易實現，語言無關，成本效果更優。

適合FaaS、盒馬NBF這類場景或者開發者本身定義開發框架，能避免UUID這種狀況的 場景使用。

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

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

與AWS Lambda方案對比

Lambda爲了作到快速擴縮容，要求用戶的應用以Function爲單位開發，Lambda Runtime動態加載Function來快速增長實例。

CSE經過將一個應用的多個實例啓動後，共享相同的指令數據，抽取出不一樣的指令數據，每次啓動實例只須要加載多實例的差別部分。所以能夠透明兼容社區主流技術棧，如Spring Boot，PHP/Java/Python/NodeJS等。

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的成功案例

• 盒馬p0級服務，文描在雙十二場景驗證中，機器數量從11臺到2臺（2~10臺之間波動）。

3.8女王節的最新數據，盒馬導購域的P0級服務流量峯值從4000+瞬間飆到12萬，CSE瞬間彈性擴容，從2臺-->5臺-->10臺，流量峯值回落後又縮容到2臺。

• 盒馬p0級服務，天氣在雙十二場景驗證中，機器數量從4臺到2臺（2~10臺之間波動）。
• 1688的buyer-tools應用，以前固定4臺機器，serverless化完成後，機器數量變成1臺（1~4臺之間波動）。預發可實現0 ~ 1臺實例之間波動。

CSE的約束和限制

• 高脈衝型流量業務消耗的成本會更高。
• 應用盡量避免後臺活動線程的CPU消耗。
• 應用盡量無狀態。
• 應用盡量使用短鏈接，長連接要能支持斷線毫秒級重連能力。

CSE引用瞭如下合做團隊的代碼，特此致謝。

• 使用了操做系統團隊開發的 fork2技術，感謝 @啓翾 @喻望 @笑哲
• 使用了JVM團隊開發的 APPCDS技術，感謝 @三紅 @傳勝 @QI, Yumin @在弦
• 姬風團隊幫助優化了中間件SDK啓動速度，感謝 @姬風以及他的團隊同窗
• Pouch團隊作了大量容器適配Serverless的優化，感謝 @華敏 @沈凌

---

本文做者：王小瑞

閱讀原文

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