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 實例，這個分配的速度非?？?#xff0c;耗時幾十毫秒，同時把 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 {@Overridepublic 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 ignoredreturn "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臺實例之間波動。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的阿里巴巴中间件在 Serverless 技术领域的探索的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。