Serverless 話題涉及范圍極廣，幾乎包含了代碼管理、測試、發(fā)布、運(yùn)維和擴(kuò)容等與應(yīng)用生命周期關(guān)聯(lián)的所有環(huán)節(jié)。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ì)適用場景有很強(qiáng)的約束；
• Function 之間的調(diào)用通過 API Gateway，響應(yīng)時(shí)間更長。

本文將介紹阿里云中間件團(tuán)隊(duì)在探索?Serverless 過程中的思考以及正在做的事，目的是盡可能讓開發(fā)者少改代碼，甚至不改代碼，就能具備 AWS Lambda 的技術(shù)優(yōu)勢。

Cloud Service Engine 云服務(wù)引擎（以下簡稱CSE），是阿里云中間件團(tuán)隊(duì)開發(fā)的面向通用 Serverless 計(jì)算的中間件產(chǎn)品，目的是具備 AWS Lambda 的各種優(yōu)勢，同時(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í)隨地，并且簡便快速地，獲取 IT 服務(wù)，目前，IaaS、PaaS都已經(jīng)做到了按需付費(fèi)，PaaS 甚至做到了按請求付費(fèi)，如DB，CACHE，MQ等，但是 IaaS 的付費(fèi)粒度仍然是時(shí)間維度，最快按照小時(shí)付費(fèi)，以分鐘來交付。

因此，當(dāng)下的云計(jì)算場景，應(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è)分配的速度非?？?#xff0c;耗時(shí)幾十毫秒，同時(shí)把 B 的服務(wù)地址直接返回給 A，A 會(huì)將之前未完成的請求發(fā)送到新創(chuàng)建的 Service B。


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

• 價(jià)值一：無需管理服務(wù)器，即無需容量評(píng)估；容量評(píng)估這件事情對(duì)于應(yīng)用負(fù)責(zé)人一直是一個(gè)極難解的問題，因?yàn)槲覀兒茈y預(yù)測未來的峰值是什么。
• 價(jià)值二：持續(xù)擴(kuò)展；之前的做法是每個(gè)應(yīng)用程序獨(dú)占一定數(shù)量的資源，如果變成Serverless 模式，所有應(yīng)用程序可以共享資源池，每個(gè)應(yīng)用程序幾乎可以無限擴(kuò)展。

• 價(jià)值三：按照請求計(jì)費(fèi)；因?yàn)槊總€(gè)實(shí)例的啟動(dòng)時(shí)間甚至比 FaaS 的函數(shù)啟動(dòng)時(shí)間還快，就可以像 FaaS 一樣來核算成本，成本只與以下因素有關(guān)

  • 請求數(shù)量（QPS）
  • 每次請求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ì)更長。因此，這個(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í)現(xiàn)、和語言無關(guān)、成本效果更優(yōu)，適合 FaaS、NBF 這類場景或者開發(fā)者自己定義的開發(fā)框架，能避免 UUID 的問題。

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

和 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)勢

理論模型：

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

量化分析：

Serverless 的成本優(yōu)勢是可以和 CPU Share &離在線混部等調(diào)度技術(shù)的成本優(yōu)勢做疊加，能給最終用戶一個(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 {@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 的生產(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)。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。