• 1 背景

• 2 快速驗(yàn)證，落地MVP版本

• 2.1 技術(shù)選型

• 2.2 架構(gòu)設(shè)計(jì)

• 2.3 流程設(shè)計(jì)

• 2.4 函數(shù)觸發(fā)

• 2.5 函數(shù)執(zhí)行

• 2.6 彈性伸縮

• 3 優(yōu)化核心技術(shù)，保障業(yè)務(wù)穩(wěn)定性

• 3.1 彈性伸縮優(yōu)化

• 3.2 冷啟動(dòng)優(yōu)化

• 3.3 高可用保障

• 3.4 容器穩(wěn)定性優(yōu)化

• 4 完善生態(tài)，落實(shí)收益

• 4.1 提供研發(fā)工具

• 4.2 融合技術(shù)生態(tài)

• 4.3 開放平臺(tái)能力

• 4.4 支持合并部署

• 5 落地場景、收益

• 5.1 落地場景

• 5.2 落地收益

• 6 未來規(guī)劃

• 作者簡介

• 招聘信息

1 背景

Serverless一詞于2012年被提出，2014年由于亞馬遜的AWS Lambda無服務(wù)器計(jì)算服務(wù)的興起，而被大家廣泛認(rèn)知。Serverless通常被直譯成“無服務(wù)器”，無服務(wù)器計(jì)算是可以讓用戶在不考慮服務(wù)器的情況下構(gòu)建并運(yùn)行應(yīng)用程序。使用無服務(wù)器計(jì)算，應(yīng)用程序仍在服務(wù)器上運(yùn)行，但所有服務(wù)器管理工作均由Serverless平臺(tái)負(fù)責(zé)。如機(jī)器申請(qǐng)、代碼發(fā)布、機(jī)器宕機(jī)、實(shí)例擴(kuò)縮容、機(jī)房容災(zāi)等都由平臺(tái)幫助自動(dòng)完成，業(yè)務(wù)開發(fā)只需考慮業(yè)務(wù)邏輯的實(shí)現(xiàn)即可。

回顧計(jì)算行業(yè)的發(fā)展歷程，基礎(chǔ)設(shè)施從物理機(jī)到虛擬機(jī)，再從虛擬機(jī)到容器；服務(wù)架構(gòu)從傳統(tǒng)單體應(yīng)用架構(gòu)到SOA架構(gòu)，再從SOA架構(gòu)到微服務(wù)架構(gòu)。從基礎(chǔ)設(shè)施和服務(wù)架構(gòu)兩條主線來看整體技術(shù)發(fā)展趨勢，大家可能會(huì)發(fā)現(xiàn)，不論是基礎(chǔ)設(shè)施還是服務(wù)架構(gòu)，都是從大往小或者由巨到微的方向上演進(jìn)，這種演變的本質(zhì)原則無非是解決資源成本或者研發(fā)效率的問題。當(dāng)然，Serverless也不例外，它也是用來解決這兩個(gè)方面的問題：

• 資源利用率：Serverless產(chǎn)品支持快速彈性伸縮能力，能夠幫助業(yè)務(wù)提升資源利用率，在業(yè)務(wù)流量高峰時(shí)，業(yè)務(wù)的計(jì)算能力、容量自動(dòng)擴(kuò)容，承載更多的用戶請(qǐng)求，而在業(yè)務(wù)流量下降時(shí)，所使用的資源也會(huì)同時(shí)收縮，避免資源浪費(fèi)。
• 研發(fā)運(yùn)維效率：在Serverless上開發(fā)人員一般只需要填寫代碼路徑或者上傳代碼包，平臺(tái)能夠幫助完成構(gòu)建、部署的工作。開發(fā)人員不直接面對(duì)機(jī)器，對(duì)于機(jī)器的管理，機(jī)器是否正常以及流量高低峰的是否需要擴(kuò)縮容等問題，這些統(tǒng)統(tǒng)不需要去考慮，由Serverless產(chǎn)品幫助研發(fā)人員去完成。這樣就能使他們從繁瑣的運(yùn)維工作中解放出來，從DevOps轉(zhuǎn)向NoOps，更加專注于業(yè)務(wù)邏輯的實(shí)現(xiàn)。

雖然AWS在2014年就推出了第一個(gè)Serverless產(chǎn)品Lambda，但Serverless技術(shù)在國內(nèi)的應(yīng)用一直不溫不火。不過近兩三年，在容器、Kubernetes以及云原生等技術(shù)的推動(dòng)下，Serverless技術(shù)迅速發(fā)展，國內(nèi)各大互聯(lián)網(wǎng)公司都在積極建設(shè)Serverless相關(guān)產(chǎn)品，探索Serverless技術(shù)的落地。在這種背景下，美團(tuán)也于2019年初開始了Serverless平臺(tái)的建設(shè)，內(nèi)部項(xiàng)目名稱為Nest。

截止到目前，Nest平臺(tái)已經(jīng)過兩年的建設(shè)，回顧整體的建設(shè)過程，主要經(jīng)歷了以下三個(gè)階段：

• 快速驗(yàn)證，落地MVP版本：我們通過技術(shù)選型、產(chǎn)品與架構(gòu)設(shè)計(jì)、開發(fā)迭代，快速落地了Serverless產(chǎn)品的基本的能力，如構(gòu)建、發(fā)布、彈性伸縮、對(duì)接觸發(fā)源、執(zhí)行函數(shù)等。上線后，我們推進(jìn)了一些業(yè)務(wù)的試點(diǎn)接入，幫助驗(yàn)證打磨產(chǎn)品。
• 優(yōu)化核心技術(shù)，保障業(yè)務(wù)穩(wěn)定性：有了前期的試點(diǎn)業(yè)務(wù)驗(yàn)證，我們很快發(fā)現(xiàn)產(chǎn)品的存在的一些穩(wěn)定性相關(guān)的問題，主要有彈性伸縮的穩(wěn)定性、冷啟動(dòng)的速度、系統(tǒng)與業(yè)務(wù)的可用性、容器的穩(wěn)定性。針對(duì)這些問題我們對(duì)各個(gè)問題涉及的技術(shù)點(diǎn)做了專項(xiàng)的優(yōu)化改進(jìn)。
• 完善技術(shù)生態(tài)，落實(shí)收益：優(yōu)化了核心技術(shù)點(diǎn)后，產(chǎn)品逐漸成熟穩(wěn)定，但依然面臨生態(tài)性問題，如研發(fā)工具欠缺，上下游產(chǎn)品沒有打通、平臺(tái)開放能力不足等問題，影響或阻礙了產(chǎn)品的推廣使用。因此，我們繼續(xù)完善產(chǎn)品的技術(shù)生態(tài)，掃清業(yè)務(wù)接入使用障礙，落實(shí)產(chǎn)品的業(yè)務(wù)收益。

2 快速驗(yàn)證，落地MVP版本

2.1 技術(shù)選型

建設(shè)Nest平臺(tái)，首要解決的就是技術(shù)選型問題，Nest主要涉及三個(gè)關(guān)鍵點(diǎn)的選型：演進(jìn)路線、基礎(chǔ)設(shè)施、開發(fā)語言。

2.1.1 演進(jìn)路線

起初Serverless服務(wù)主要包含F(xiàn)aaS（Function as a Service）和BaaS（Backend as a Service），近幾年Serverless的產(chǎn)品領(lǐng)域有所擴(kuò)張，它還包含面向應(yīng)用的Serverless服務(wù)。

• FaaS：是運(yùn)行在一個(gè)無狀態(tài)的計(jì)算容器中的函數(shù)服務(wù)，函數(shù)通常是事件驅(qū)動(dòng)、生命周期很短（甚至只有一次調(diào)用）、完全由第三方管理的。業(yè)界相關(guān)FaaS產(chǎn)品有AWS的Lambda、阿里云的函數(shù)計(jì)算等。
• BaaS：是建立在云服務(wù)生態(tài)之上的后端服務(wù)。業(yè)界相關(guān)BaaS產(chǎn)品包括AWS的S3、DynamoDB等。

面向應(yīng)用的Serverless服務(wù)：如Knative，它提供了從代碼包到鏡像的構(gòu)建、部署以及實(shí)例彈性伸縮等全面的服務(wù)托管能力，公有云產(chǎn)品有Google Cloud Run（基于Knative）、阿里云的SAE（Serverless Application Engine）。

在美團(tuán)內(nèi)部，BaaS產(chǎn)品其實(shí)就是內(nèi)部的中間件以及底層服務(wù)等，它們經(jīng)過多年的發(fā)展，已經(jīng)非常豐富且成熟了。因此，在美團(tuán)的Serverless產(chǎn)品演進(jìn)主要在函數(shù)計(jì)算服務(wù)和面向應(yīng)用的Serverless服務(wù)兩個(gè)方向上。那究竟該如何演進(jìn)呢？當(dāng)時(shí)主要考慮到在業(yè)界FaaS函數(shù)計(jì)算服務(wù)相對(duì)于面向應(yīng)用的Serverless服務(wù)來說，更加成熟且確定。因此，我們決定“先建設(shè)FaaS函數(shù)計(jì)算服務(wù)，再建設(shè)面向應(yīng)用的Serverless服務(wù)”這樣一條演進(jìn)路線。

2.1.2 基礎(chǔ)設(shè)施

由于彈性伸縮是Serverless平臺(tái)必備的能力，因此Serverless必然涉及到底層資源的調(diào)度和管理。這也是為什么當(dāng)前業(yè)界有很多開源的Serverless產(chǎn)品（如OpenFaaS、Fission、Nuclio、Knative等）是基于Kubernetes來實(shí)現(xiàn)的，因?yàn)檫@種選型能夠充分利用Kubernetes的基礎(chǔ)設(shè)施的管理能力。在美團(tuán)內(nèi)部基礎(chǔ)設(shè)施產(chǎn)品是Hulk，雖然Hulk是基于Kubernetes封裝后的產(chǎn)品，但Hulk在落地之初考慮到落地難度以及各種原因，最終未按照原生的方式來使用Kubernetes，并且在容器層采用的也是富容器模式。

在這種歷史背景下，我們?cè)谧龌A(chǔ)設(shè)施選型時(shí)就面臨兩種選項(xiàng)：一是使用公司的Hulk來作為Nest的基礎(chǔ)設(shè)施（非原生Kubernetes），二是采用原生Kubernetes基礎(chǔ)設(shè)施。我們考慮到當(dāng)前業(yè)界使用原生Kubernetes是主流趨勢并且使用原生Kubernetes還能充分利用Kubernetes原生能力，可以減少重復(fù)開發(fā)。因此，最終考量的結(jié)果是我們采用了原生Kubernetes作為我們的基礎(chǔ)設(shè)施。

2.1.3 開發(fā)語言

雖然無論在云原生領(lǐng)域，還是Kubernetes的生態(tài)中，Golang都更加主流，但在美團(tuán)Java才是使用最廣泛的語言，相比Golang，Java在公司內(nèi)部生態(tài)比較好。因此，在語言的選型上我們選擇了Java語言。在Nest產(chǎn)品開發(fā)之初，Kubernetes社區(qū)的Java客戶端還不夠完善，但隨著項(xiàng)目的推進(jìn)，社區(qū)的Java客戶端也逐漸豐富了起來，目前已經(jīng)完全夠用了。另外，我們也在使用過程中，也貢獻(xiàn)了一些Pull Request，反哺了社區(qū)。

2.2 架構(gòu)設(shè)計(jì)

基于以上的演進(jìn)路線、基礎(chǔ)設(shè)施、開發(fā)語言的選型，我們進(jìn)行了Nest產(chǎn)品的架構(gòu)設(shè)計(jì)。

在整體的架構(gòu)上，流量由EventTrigger（事件觸發(fā)源，如Nginx、應(yīng)用網(wǎng)關(guān)、定時(shí)任務(wù)、消息隊(duì)列、RPC調(diào)用等）觸發(fā)到Nest平臺(tái)，Nest平臺(tái)內(nèi)會(huì)根據(jù)流量的特征路由到具體函數(shù)實(shí)例，觸發(fā)函數(shù)執(zhí)行，而函數(shù)內(nèi)部代碼邏輯可以調(diào)用公司內(nèi)的各個(gè)BaaS服務(wù)，最終完成函數(shù)的執(zhí)行，返回結(jié)果。

在技術(shù)實(shí)現(xiàn)上，Nest平臺(tái)使用Kubernetes作為基礎(chǔ)底座并適當(dāng)參考了一些Knative的優(yōu)秀設(shè)計(jì)，在其架構(gòu)內(nèi)部主要由以下幾個(gè)核心部分組成：

• 事件網(wǎng)關(guān)：核心能力是負(fù)責(zé)對(duì)接外部事件源的流量，然后路由到函數(shù)實(shí)例上；另外，網(wǎng)關(guān)還負(fù)責(zé)統(tǒng)計(jì)各個(gè)函數(shù)的進(jìn)出流量信息，為彈性伸縮模塊提供伸縮決策的數(shù)據(jù)支撐。
• 彈性伸縮：核心能力是負(fù)責(zé)函數(shù)實(shí)例的彈性伸縮，伸縮主要根據(jù)函數(shù)運(yùn)行的流量數(shù)據(jù)以及實(shí)例閾值配置計(jì)算函數(shù)目標(biāo)實(shí)例個(gè)數(shù)，然后借助Kubernetes的資源控制能力，調(diào)整函數(shù)實(shí)例的個(gè)數(shù)。
• 控制器：核心能力是負(fù)責(zé)Kubernetes CRD（Custom Resource Definition）的控制邏輯實(shí)現(xiàn)。
• 函數(shù)實(shí)例：函數(shù)的運(yùn)行實(shí)例。當(dāng)事件網(wǎng)關(guān)流量觸發(fā)過來，會(huì)在函數(shù)實(shí)例內(nèi)執(zhí)行相應(yīng)的函數(shù)代碼邏輯。
• 治理平臺(tái)：面向用戶使用的平臺(tái)，負(fù)責(zé)函數(shù)的構(gòu)建、版本、發(fā)布以及一些函數(shù)元信息的管理等。

2.3 流程設(shè)計(jì)

在具體的CI/CD流程上，Nest又與傳統(tǒng)的模式有何區(qū)別呢？為了說明這個(gè)問題，我們先來看一看在Nest平臺(tái)上函數(shù)的整體生命周期怎樣的？具體有以下四個(gè)階段：構(gòu)建、版本、部署、伸縮。

• 構(gòu)建：開發(fā)的代碼和配置通過構(gòu)建生成鏡像或可執(zhí)行文件。
• 版本：構(gòu)建生成的鏡像或可執(zhí)行文件加上發(fā)布配置形成一個(gè)不可變的版本。
• 部署：將版本發(fā)布，即完成部署。
• 伸縮：根據(jù)函數(shù)實(shí)例的流量以及負(fù)載等信息，來進(jìn)行實(shí)例的彈性擴(kuò)縮容。

就這四個(gè)階段來看，Nest與傳統(tǒng)的CI/CD流程本質(zhì)區(qū)別在于部署和伸縮：傳統(tǒng)的部署是感知機(jī)器的，一般是將代碼包發(fā)布到確定的機(jī)器上，但Serverless是要向用戶屏蔽機(jī)器的（在部署時(shí)，可能函數(shù)的實(shí)例數(shù)還是0）；另外，傳統(tǒng)的模式一般是不具備動(dòng)態(tài)擴(kuò)縮容的，而Serverless則不同，Serverless平臺(tái)會(huì)根據(jù)業(yè)務(wù)的自身流量需要，進(jìn)行動(dòng)態(tài)擴(kuò)縮容。后續(xù)章節(jié)會(huì)詳細(xì)講解彈性伸縮，因此這里我們只探討部署的設(shè)計(jì)。

部署的核心點(diǎn)在于如何向用戶屏蔽機(jī)器？對(duì)于這個(gè)問題，我們抽象了機(jī)器，提出了分組的概念，分組是由SET（單元化架構(gòu)的標(biāo)識(shí)，機(jī)器上會(huì)帶有該標(biāo)識(shí)）、泳道（測試環(huán)境隔離標(biāo)識(shí)，機(jī)器上會(huì)帶有該標(biāo)識(shí)）、區(qū)域（上海、北京等）三個(gè)信息組成。用戶部署只需在相應(yīng)的分組上進(jìn)行操作，而不用涉及到具體機(jī)器。能夠做到這些的背后，是由Nest平臺(tái)幫助用戶管理了機(jī)器資源，每次部署會(huì)根據(jù)分組信息來實(shí)時(shí)初始化相應(yīng)的機(jī)器實(shí)例。

2.4 函數(shù)觸發(fā)

函數(shù)的執(zhí)行是由事件觸發(fā)的。完成函數(shù)的觸發(fā)，需要實(shí)現(xiàn)以下四個(gè)流程：

• 流量引入：向事件源注冊(cè)事件網(wǎng)關(guān)的信息，將流量引入到事件網(wǎng)關(guān)。如針對(duì)MQ事件源，通過注冊(cè)MQ的消費(fèi)組，引入MQ的流量到事件網(wǎng)關(guān)。
• 流量適配：事件網(wǎng)關(guān)對(duì)事件源進(jìn)入的流量進(jìn)行適配對(duì)接。
• 函數(shù)發(fā)現(xiàn)：對(duì)函數(shù)元數(shù)據(jù)（函數(shù)實(shí)例信息、配置信息等）的獲取過程，類似微服務(wù)的服務(wù)發(fā)現(xiàn)過程。事件網(wǎng)關(guān)接受的事件流量需要發(fā)送到具體的函數(shù)實(shí)例，這就需要對(duì)函數(shù)進(jìn)行發(fā)現(xiàn)。這里發(fā)現(xiàn)實(shí)質(zhì)是獲取Kubernetes中的內(nèi)置資源或者CRD資源中存儲(chǔ)的信息。
• 函數(shù)路由：事件流量的路由過程，路由到特定的函數(shù)實(shí)例上。這里為了支持傳統(tǒng)路由邏輯（如SET、泳道、區(qū)域路由等）以及版本路由能力，我們采用了多層路由，第一層路由到分組（SET、泳道、區(qū)域路由），第二層路由到具體版本。同版本內(nèi)的實(shí)例，通過負(fù)載均衡器選擇出具體實(shí)例。另外，通過該版本路由，我們很輕松的支持了金絲雀、藍(lán)綠發(fā)布。

2.5 函數(shù)執(zhí)行

函數(shù)不同于傳統(tǒng)的服務(wù)，傳統(tǒng)的服務(wù)是個(gè)可執(zhí)行的程序，但函數(shù)不同，函數(shù)是代碼片段，自身是不能單獨(dú)執(zhí)行的。那流量觸發(fā)到函數(shù)實(shí)例后，函數(shù)是如何執(zhí)行的呢？

函數(shù)的執(zhí)行的首要問題是函數(shù)的運(yùn)行環(huán)境：由于Nest平臺(tái)是基于Kubernetes實(shí)現(xiàn)的，因此函數(shù)一定是運(yùn)行在Kubernetes的Pod（實(shí)例）內(nèi)，Pod內(nèi)部是容器，容器的內(nèi)部是運(yùn)行時(shí)，運(yùn)行時(shí)是函數(shù)流量接收的入口，最終也是由運(yùn)行時(shí)來觸發(fā)函數(shù)的執(zhí)行。一切看起來是那么的順利成章，但我們?cè)诼涞貢r(shí)是還是遇到了一些困難，最主要的困難是讓開發(fā)同學(xué)可以在函數(shù)內(nèi)無縫的使用公司內(nèi)的組件，如OCTO（服務(wù)框架）、Celler（緩存系統(tǒng)）、DB等。

在美團(tuán)的技術(shù)體系中，由于多年的技術(shù)沉淀，很難在一個(gè)純粹的容器（沒有任何其他依賴）中運(yùn)行公司的業(yè)務(wù)邏輯。因?yàn)楣镜娜萜髦谐恋砹撕芏喹h(huán)境或服務(wù)治理等能力，如服務(wù)治理的Agent服務(wù)以及實(shí)例環(huán)境配置、網(wǎng)絡(luò)配置等。

因此，為了業(yè)務(wù)在函數(shù)內(nèi)無縫的使用公司內(nèi)的組件，我們復(fù)用公司的容器體系來降低業(yè)務(wù)編寫函數(shù)的成本。但復(fù)用公司的容器體系也沒那么簡單，因?yàn)樵诠緝?nèi)沒有人試過這條路，Nest是公司第一個(gè)基于原生Kubernetes建設(shè)的平臺(tái)，“第一個(gè)吃螃蟹的人”總會(huì)遇到一些坑。對(duì)于這些坑，我們只能在推進(jìn)過程中“逢山開路，遇水搭橋”，遇到一個(gè)解決一個(gè)?？偨Y(jié)下來，其中最核心的是在容器的啟動(dòng)環(huán)節(jié)打通的CMDB等技術(shù)體系，讓運(yùn)行函數(shù)的容器與開發(fā)同學(xué)平時(shí)申請(qǐng)的機(jī)器用起來沒有任何區(qū)別。

2.6 彈性伸縮

彈性伸縮的核心問題主要有三個(gè)：什么時(shí)候伸縮，伸縮多少，伸縮的速度快不快？也就是伸縮時(shí)機(jī)、伸縮算法、伸縮速度的問題。

• 伸縮時(shí)機(jī)：根據(jù)流量Metrics實(shí)時(shí)計(jì)算函數(shù)期望實(shí)例數(shù)，進(jìn)?擴(kuò)縮。流量的Metrics數(shù)據(jù)來自于事件網(wǎng)關(guān)，這里主要統(tǒng)計(jì)函數(shù)的并發(fā)度指標(biāo)，彈性伸縮組件每秒中會(huì)主動(dòng)從事件網(wǎng)關(guān)獲取一次Metrics數(shù)據(jù)。
• 伸縮算法：并發(fā)度/單實(shí)例閾值=期望實(shí)例數(shù)。根據(jù)收集的Metrics數(shù)據(jù)以及業(yè)務(wù)配置的閾值，通過算法計(jì)算出期望的實(shí)例數(shù)，然后通過Kubernetes接口設(shè)置具體實(shí)例數(shù)。整個(gè)算法看起來雖然簡單，但非常穩(wěn)定、魯棒性好。
• 伸縮速度：主要取決于冷啟動(dòng)時(shí)間，在下個(gè)章節(jié)會(huì)詳細(xì)講解這塊內(nèi)容。

除了基本的擴(kuò)縮容能力，我們還支持了伸縮到0，支持配置最大、最小實(shí)例數(shù)（最小實(shí)例即預(yù)留實(shí)例）。伸縮到0的具體實(shí)現(xiàn)是，我們?cè)谑录W(wǎng)關(guān)內(nèi)部增加了激活器模塊，當(dāng)函數(shù)無實(shí)例時(shí)，會(huì)將函數(shù)的請(qǐng)求流量緩存在激活器內(nèi)部，然后立即通過流量的Metrics去驅(qū)動(dòng)彈性伸縮組件進(jìn)行擴(kuò)容，等擴(kuò)容的實(shí)例啟動(dòng)完成后，激活器再將緩存的請(qǐng)求重試到擴(kuò)容的實(shí)例上觸發(fā)函數(shù)執(zhí)行。

3 優(yōu)化核心技術(shù)，保障業(yè)務(wù)穩(wěn)定性

3.1 彈性伸縮優(yōu)化

上面提到的伸縮時(shí)機(jī)、伸縮算法、伸縮速度這三要素都是理想情況下的模型，尤其是伸縮速度，當(dāng)前技術(shù)根本做不到毫秒級(jí)別的擴(kuò)縮容。因此，在線上實(shí)際場景中，彈性伸縮會(huì)存在一些不符合預(yù)期的情況，比如實(shí)例伸縮比較頻繁或者擴(kuò)容來不及，導(dǎo)致服務(wù)不太穩(wěn)定的問題。

• 針對(duì)實(shí)例伸縮比較頻繁問題，我們?cè)趶椥陨炜s組件內(nèi)維護(hù)了統(tǒng)計(jì)數(shù)據(jù)的滑動(dòng)窗?，通過計(jì)算均值來平滑指標(biāo)，還通過延時(shí)縮容，實(shí)時(shí)擴(kuò)容來緩解頻繁擴(kuò)縮問題。另外，我們?cè)黾恿嘶赒PS指標(biāo)的伸縮策略，因?yàn)镼PS指標(biāo)相對(duì)并發(fā)度指標(biāo)會(huì)更加穩(wěn)定。
• 針對(duì)擴(kuò)容來不及問題，我們采取提前擴(kuò)容的手段，當(dāng)達(dá)到實(shí)例閾值的70%就擴(kuò)容，能夠比較好的緩解這個(gè)問題。除此之外，我們還支持了多指標(biāo)混合伸縮（并發(fā)度、QPS、CPU、Memory），定時(shí)伸縮等策略，滿足各種業(yè)務(wù)需求。

下圖展示的是線上彈性伸縮的真實(shí)案例（配置的最小實(shí)例數(shù)為4，單實(shí)例閾值100，閾值使用率0.7），其中上半部分是業(yè)務(wù)每秒的請(qǐng)求數(shù)，下半部分是擴(kuò)縮實(shí)例的決策圖，可以看到在成功率100%的情況下，業(yè)務(wù)完美應(yīng)對(duì)流量高峰。

3.2 冷啟動(dòng)優(yōu)化

冷啟動(dòng)是指在函數(shù)調(diào)用鏈路中包含了資源調(diào)度、鏡像/代碼下載、啟動(dòng)容器、運(yùn)行時(shí)初始化、用戶代碼初始化等環(huán)節(jié)。當(dāng)冷啟動(dòng)完成后，函數(shù)實(shí)例就緒，后續(xù)請(qǐng)求就能直接被函數(shù)執(zhí)行。冷啟動(dòng)在Serverless領(lǐng)域至關(guān)重要，它的耗時(shí)決定了彈性伸縮的速度。

所謂“天下武功，無堅(jiān)不破，唯快不破”，這句話在Serverless領(lǐng)域也同樣受用。試想如果拉起一個(gè)實(shí)例足夠快，快到毫秒級(jí)別，那幾乎所有的函數(shù)實(shí)例都可以縮容到0，等有流量時(shí)，再擴(kuò)容實(shí)例處理請(qǐng)求，這對(duì)于存在高低峰流量的業(yè)務(wù)將極大的節(jié)省機(jī)器資源成本。當(dāng)然，理想很豐滿，現(xiàn)實(shí)很骨感。做到毫秒級(jí)別幾乎不可能。但只要冷啟動(dòng)時(shí)間越來越短，成本自然就會(huì)越來越低，另外，極短的冷啟動(dòng)時(shí)間對(duì)伸縮時(shí)函數(shù)的可用性以及穩(wěn)定性都有莫大的好處。

冷啟動(dòng)優(yōu)化是個(gè)循序漸進(jìn)的過程，我們對(duì)冷啟動(dòng)優(yōu)化主要經(jīng)歷了三個(gè)階段：鏡像啟動(dòng)優(yōu)化、資源池優(yōu)化、核心路徑優(yōu)化。

• 鏡像啟動(dòng)優(yōu)化：我們對(duì)鏡像啟動(dòng)過程中的耗時(shí)環(huán)節(jié)（啟動(dòng)容器和運(yùn)行時(shí)初始化）進(jìn)行了針對(duì)性優(yōu)化，主要對(duì)容器IO限速、一些特殊Agent啟動(dòng)耗時(shí)、啟動(dòng)盤與數(shù)據(jù)盤數(shù)據(jù)拷貝等關(guān)鍵點(diǎn)的優(yōu)化，最終將啟動(dòng)過程中的系統(tǒng)耗時(shí)從42s優(yōu)化到12s左右。

• 資源池優(yōu)化：鏡像啟動(dòng)耗時(shí)優(yōu)化到12s，基本已經(jīng)快達(dá)到瓶頸點(diǎn)，再繼續(xù)優(yōu)化空間不大。因此，我們想能否繞開鏡像啟動(dòng)的耗時(shí)環(huán)節(jié)？最終，我們采用了一個(gè)比較簡單思路“空間換時(shí)間”，用資源池方案：緩存一些已啟動(dòng)的實(shí)例，當(dāng)需要擴(kuò)容時(shí)，直接從資源池獲取實(shí)例，繞開鏡像啟動(dòng)容器的環(huán)節(jié)，最終效果很明顯，將啟動(dòng)的系統(tǒng)耗時(shí)從12s優(yōu)化到3s。這里需要說明的是資源池自身也是通過Kubernetes的Depolyment進(jìn)行管理，池中實(shí)例被取走會(huì)立即自動(dòng)補(bǔ)充。

• 核心路徑優(yōu)化：在資源池優(yōu)化的基礎(chǔ)上，我們?cè)俅尉媲缶?，針?duì)啟動(dòng)流程中的下載與解壓代碼兩個(gè)耗時(shí)環(huán)節(jié)進(jìn)行優(yōu)化，過程中我們采用了高性能的壓縮解壓算法（LZ4與Zstd）以及并行下載和解壓技術(shù)，效果非常好。另外，我們還支持了通用邏輯（中間件、依賴包等）下沉，通過預(yù)加載的方式，最終將函數(shù)端到端的啟動(dòng)耗時(shí)優(yōu)化到2s，這就意味著擴(kuò)容一個(gè)函數(shù)實(shí)例只需要2s（包含函數(shù)啟動(dòng)）。如果排除掉函數(shù)自身的初始化啟動(dòng)耗時(shí)，平臺(tái)側(cè)的耗時(shí)已在毫秒級(jí)別。

3.3 高可用保障

說到高可用，對(duì)于一般的平臺(tái)，指的就是平臺(tái)自身的高可用，但Nest平臺(tái)有所不同，Nest的高可用還包含托管在Nest平臺(tái)上的函數(shù)。因此，Nest的高可用保障需要從平臺(tái)和業(yè)務(wù)函數(shù)兩個(gè)方面著手。

3.3.1 平臺(tái)高可用

對(duì)平臺(tái)的高可用，Nest主要從架構(gòu)層、服務(wù)層、監(jiān)控運(yùn)營層、業(yè)務(wù)視角層面都做了全面的保障。

• 架構(gòu)層：我們針對(duì)有狀態(tài)服務(wù)，如彈性伸縮模塊，采用了主從架構(gòu)，當(dāng)主節(jié)點(diǎn)異常時(shí)從節(jié)點(diǎn)會(huì)立即替換。另外，我們還實(shí)現(xiàn)了架構(gòu)上的多層隔離。橫向地域隔離：Kubernetes兩地兩集群強(qiáng)隔離、服務(wù)（事件網(wǎng)關(guān)、彈性伸縮）集群內(nèi)兩地弱隔離（上海的彈性伸縮只負(fù)責(zé)上海Kubernetes集群內(nèi)的業(yè)務(wù)伸縮，事件網(wǎng)關(guān)存在兩地調(diào)用需求，需訪問兩地Kubernetes）。縱向業(yè)務(wù)線隔離：服務(wù)業(yè)務(wù)線強(qiáng)隔離，不同業(yè)務(wù)線使用不同集群服務(wù)；在Kubernetes層的資源用namespace實(shí)現(xiàn)業(yè)務(wù)線弱隔離。

• 服務(wù)層：主要指的是事件網(wǎng)關(guān)服務(wù)，由于所有的函數(shù)流量都經(jīng)過事件網(wǎng)關(guān)，因此事件網(wǎng)關(guān)的可用性尤為重要，這層我們支持了限流和異步化，保障服務(wù)的穩(wěn)定性。
• 監(jiān)控運(yùn)營層：主要通過完善系統(tǒng)監(jiān)控告警、梳理核心鏈路并推動(dòng)相關(guān)依賴方進(jìn)行治理。另外，我們會(huì)定期梳理SOP并通過故障演練平臺(tái)實(shí)施故障注入演練，發(fā)現(xiàn)系統(tǒng)隱患問題。
• 業(yè)務(wù)視角層：我們開發(fā)了在線不間斷實(shí)時(shí)巡檢服務(wù)，通過模擬用戶函數(shù)的請(qǐng)求流量，實(shí)時(shí)檢測系統(tǒng)的核心鏈路是否正常。

3.3.2 業(yè)務(wù)高可用

對(duì)于業(yè)務(wù)高可用，Nest主要從服務(wù)層、平臺(tái)層兩個(gè)層面做了相關(guān)的保障。

• 服務(wù)層：支持了業(yè)務(wù)降級(jí)、限流能力：當(dāng)后端函數(shù)故障時(shí)，可通過降級(jí)配置，返回降級(jí)結(jié)果。針對(duì)異常的函數(shù)流量，平臺(tái)支持限制其流量，防止后端函數(shù)實(shí)例的被異常流量打垮。

• 平臺(tái)層：支持了實(shí)例?；睢⒍鄬蛹?jí)容災(zāi)以及豐富的監(jiān)控告警能力：當(dāng)函數(shù)實(shí)例異常時(shí)，平臺(tái)會(huì)自動(dòng)隔離該實(shí)例并立即擴(kuò)容新實(shí)例。平臺(tái)支持業(yè)務(wù)多地區(qū)部署，在同地區(qū)將函數(shù)實(shí)例盡可能打散不同機(jī)房。當(dāng)宿主機(jī)、機(jī)房、地區(qū)故障時(shí)，會(huì)立即在可用宿主機(jī)、可用機(jī)房或可用區(qū)重建新實(shí)例。另外，平臺(tái)自動(dòng)幫業(yè)務(wù)提供了函數(shù)在時(shí)延、成功率、實(shí)例伸縮、請(qǐng)求數(shù)等多種指標(biāo)的監(jiān)控，當(dāng)在這些指標(biāo)不符合預(yù)期時(shí)，自動(dòng)觸發(fā)告警，通知業(yè)務(wù)開發(fā)和管理員。

3.4 容器穩(wěn)定性優(yōu)化

前文已提到，Serverless與傳統(tǒng)模式在CI/CD流程上是不同的，傳統(tǒng)模式都是事先準(zhǔn)備好機(jī)器然后部署程序，而Serverless則是根據(jù)流量的高低峰實(shí)時(shí)彈性擴(kuò)縮容實(shí)例。當(dāng)新實(shí)例擴(kuò)容出來后，會(huì)立即處理業(yè)務(wù)流量。這聽起來貌似沒什么毛病，但在富容器生態(tài)下是存在一些問題的：我們發(fā)現(xiàn)剛擴(kuò)容的機(jī)器負(fù)載非常高，導(dǎo)致一些業(yè)務(wù)請(qǐng)求執(zhí)行失敗，影響業(yè)務(wù)可用性。

分析后發(fā)現(xiàn)主要是因?yàn)槿萜鲉?dòng)后，運(yùn)維工具會(huì)進(jìn)行Agent升級(jí)、配置修改等操作，這些操作非常耗CPU。同在一個(gè)富容器中，自然就搶占了函數(shù)進(jìn)程的資源，導(dǎo)致用戶進(jìn)程不穩(wěn)定。另外，函數(shù)實(shí)例的資源配置一般比傳統(tǒng)服務(wù)的機(jī)器要小很多，這也加劇了該問題的嚴(yán)重性?；诖?，我們參考業(yè)界，聯(lián)合容器設(shè)施團(tuán)隊(duì)，落地了輕量級(jí)容器，將運(yùn)維的所有Agent放到Sidecar容器中，而業(yè)務(wù)的進(jìn)程單獨(dú)放到App容器中。采用這種容器的隔離機(jī)制，保障業(yè)務(wù)的穩(wěn)定性。同時(shí)，我們也推動(dòng)了容器裁剪計(jì)劃，去掉一些不必要的Agent。

4 完善生態(tài)，落實(shí)收益

Serverless是個(gè)系統(tǒng)工程，在技術(shù)上涉及到Kubernetes、容器、操作系統(tǒng)、JVM、運(yùn)行時(shí)等各種技術(shù)，在平臺(tái)能力上涉及到CI/CD各個(gè)流程的方方面面。

為了給用戶提供極致的開發(fā)體驗(yàn)，我們?yōu)橛脩籼峁┝碎_發(fā)工具的支持，如CLI（Command Line Interface）、WebIDE等。為了解決現(xiàn)有上下游技術(shù)產(chǎn)品的交互的問題，我們與公司現(xiàn)有的技術(shù)生態(tài)做了融合打通，方便開發(fā)同學(xué)使用。為了方便下游的集成平臺(tái)對(duì)接，我們開放了平臺(tái)的API，實(shí)現(xiàn)Nest賦能各下游平臺(tái)。針對(duì)容器過重，系統(tǒng)開銷大，導(dǎo)致低頻業(yè)務(wù)函數(shù)自身資源利用率不高的問題，我們支持了函數(shù)合并部署，成倍提升資源利用率。

4.1 提供研發(fā)工具

開發(fā)工具能夠降低平臺(tái)的使用成本，幫助開發(fā)同學(xué)快速的進(jìn)行CI/CD流程。目前Nest提供了CLI工具，幫助開發(fā)同學(xué)快速完成創(chuàng)建應(yīng)用、本地構(gòu)建、本地測試、Debug、遠(yuǎn)程發(fā)布等操作。Nest還提供了WebIDE，支持在線一站式完成代碼的修改、構(gòu)建、發(fā)布、測試。

4.2 融合技術(shù)生態(tài)

僅支持這些研發(fā)工具還是不夠的，項(xiàng)目推廣使用后，我們很快就發(fā)現(xiàn)開發(fā)同學(xué)對(duì)平臺(tái)有了新的需求，如無法在Pipeline流水線、線下服務(wù)實(shí)例編排平臺(tái)上完成對(duì)函數(shù)的操作，這對(duì)我們項(xiàng)目的推廣也形成了一些阻礙。因此，我們?nèi)诤线@些公司的成熟技術(shù)生態(tài)，打通了Pipeline流水線等平臺(tái)，融入到現(xiàn)有的上下游技術(shù)體系內(nèi)，解決用戶的后顧之憂。

4.3 開放平臺(tái)能力

有很多Nest的下游解決方案平臺(tái)，如SSR（Server Side Render）、服務(wù)編排平臺(tái)等，通過對(duì)接Nest的OpenAPI，實(shí)現(xiàn)了生產(chǎn)力的進(jìn)一步解放。例如，不用讓開發(fā)同學(xué)自己去申請(qǐng)、管理和運(yùn)維機(jī)器資源，就能夠讓用戶非?？焖俚膶?shí)現(xiàn)一個(gè)SSR項(xiàng)目或者編排程序從0到1的創(chuàng)建、發(fā)布與托管。

Nest除了開放了平臺(tái)的API，還對(duì)用戶提供了自定義資源池的能力，擁有了該項(xiàng)能力，開發(fā)同學(xué)可以定制自己的資源池，定制自己的機(jī)器環(huán)境，甚至可以下沉一些通用的邏輯，實(shí)現(xiàn)冷啟動(dòng)的進(jìn)一步優(yōu)化。

4.4 支持合并部署

合并部署指的是將多個(gè)函數(shù)部署在一個(gè)機(jī)器實(shí)例內(nèi)。合并部署的背景主要有兩個(gè)：

• 當(dāng)前的容器較重，容器自身的系統(tǒng)開銷較大，導(dǎo)致業(yè)務(wù)進(jìn)程資源利用率不高（尤其是低頻業(yè)務(wù)）。
• 在冷啟動(dòng)耗時(shí)不能滿足業(yè)務(wù)對(duì)時(shí)延的要求的情況下，我們通過預(yù)留實(shí)例來解決業(yè)務(wù)的需求。

基于這兩個(gè)背景，我們考慮支持合并部署，將一些低頻的函數(shù)部署到同一個(gè)機(jī)器實(shí)例內(nèi)，來提升預(yù)留實(shí)例中業(yè)務(wù)進(jìn)程的資源利用率。

在具體實(shí)現(xiàn)上，我們參考Kubernetes的設(shè)計(jì)方案，設(shè)計(jì)了一套基于Sandbox的函數(shù)合并部署體系（每個(gè)Sandbox就是一個(gè)函數(shù)資源），將Pod類比成Kubernetes的Node資源，Sandbox類比成Kubernetes的Pod資源，Nest Sidecar類比成Kubelet。為了實(shí)現(xiàn)Sandbox特有的部署、調(diào)度等能力，我們還自定義了一些Kubernetes資源（如SandboxDeployment、SandboxReplicaSet、SandboxEndpoints等）來支持函數(shù)動(dòng)態(tài)插拔到具體的Pod實(shí)例上。

除此之外，在合并部署的形態(tài)下，函數(shù)之間的隔離性也是不可回避的問題。為了盡可能的解決函數(shù)（合并在同一個(gè)實(shí)例中）之間的互相干擾問題，在Runtime的實(shí)現(xiàn)上，我們針對(duì)Node.js和Java語言的特點(diǎn)采取了不同的策略：Node.js語言的函數(shù)使用不同的進(jìn)程來實(shí)現(xiàn)隔離，而Java語言的函數(shù)，我們采用類加載隔離。采用這種策略的主要原因是由于Java進(jìn)程占用內(nèi)存空間相較于Node.js進(jìn)程會(huì)大很多。

5 落地場景、收益

目前Nest產(chǎn)品在美團(tuán)前端Node.js領(lǐng)域非常受歡迎，也是落地最廣泛的技術(shù)棧。當(dāng)前Nest產(chǎn)品在美團(tuán)前端已實(shí)現(xiàn)了規(guī)?；涞兀瑤缀鹾w了所有業(yè)務(wù)線，接入了大量的B/C端的核心流量。

5.1 落地場景

具體的落地前端場景有：BFF（Backend For Frontend）、CSR（Client Side Render）/SSR（Server Side Render）、后臺(tái)管理平臺(tái)、定時(shí)任務(wù)、數(shù)據(jù)處理等。

• BFF場景：BFF層主要為前端頁面提供數(shù)據(jù)，采用Serverless模式，前端同學(xué)不需要考慮不擅長的運(yùn)維環(huán)節(jié)，輕松實(shí)現(xiàn)了BFF向SFF（Serverless For Frontend）模式的轉(zhuǎn)變。
• CSR/SSR場景：CSR/SSR指的是客戶端渲染和服務(wù)端渲染，有了Serverless平臺(tái)，不用考慮運(yùn)維環(huán)節(jié)，更多的前端業(yè)務(wù)來嘗試使用SSR來實(shí)現(xiàn)前端首屏的快速展現(xiàn)。
• 后臺(tái)管理平臺(tái)場景：公司有很多的后臺(tái)管理平臺(tái)的Web服務(wù)，它們雖然相較于函數(shù)是比較重的，但完全可以直接托管Serverless平臺(tái)，充分享受Serverless平臺(tái)極致的發(fā)布和運(yùn)維效率。
• 定時(shí)任務(wù)場景：公司存在很多周期性任務(wù)，如每隔幾秒拉取數(shù)據(jù)，每天0點(diǎn)清理日志，每小時(shí)收集全量數(shù)據(jù)并生成報(bào)表等，Serverless平臺(tái)直接與任務(wù)調(diào)度系統(tǒng)打通，只需寫好任務(wù)的處理邏輯并在平臺(tái)上配置定時(shí)觸發(fā)器，即完成定時(shí)任務(wù)的接入，完全不用管理機(jī)器資源。
• 數(shù)據(jù)處理場景：將MQ Topic作為事件源接入Serverless平臺(tái)，平臺(tái)會(huì)自動(dòng)訂閱Topic的消息，當(dāng)有消息消費(fèi)時(shí)，觸發(fā)函數(shù)執(zhí)行，類似定時(shí)任務(wù)場景，作為用戶也只需寫好數(shù)據(jù)處理的邏輯并在平臺(tái)上配置好MQ觸發(fā)器，即完成MQ消費(fèi)端的接入，完全不用管理機(jī)器資源。

5.2 落地收益

Serverless的收益是非常明顯的，尤其在前端領(lǐng)域，大量的業(yè)務(wù)接入已是最好的說明。具體收益，從以下兩個(gè)方面分別來看：

• 降成本：通過Serverless的彈性伸縮能力，高頻業(yè)務(wù)資源利用率能提升到40%～50%；低頻業(yè)務(wù)函數(shù)通過合并部署，也能極大降低函數(shù)運(yùn)行成本。
• 提效率：整體研發(fā)研發(fā)效率提升約40%。
• 從代碼開發(fā)來看，提供完備的CLI、WebIDE等研發(fā)工具，能夠幫助開發(fā)同學(xué)生成代碼腳手架，聚焦編寫業(yè)務(wù)邏輯，快速完成本地測試；另外，讓業(yè)務(wù)服務(wù)零成本具備在線查看日志與監(jiān)控的能力。
• 從發(fā)布來看，通過云原生的模式，業(yè)務(wù)無需申請(qǐng)機(jī)器，發(fā)布、回滾都是秒級(jí)別的體驗(yàn)。另外，還能利用平臺(tái)天然能力，配合事件網(wǎng)關(guān)，實(shí)現(xiàn)切流、完成金絲雀測試等。
• 從日常運(yùn)維來看，業(yè)務(wù)無需關(guān)注機(jī)器故障、資源不足、機(jī)房容災(zāi)等傳統(tǒng)模式該考慮的問題，另外，當(dāng)業(yè)務(wù)進(jìn)程異常時(shí)，Nest能夠自動(dòng)完成異常實(shí)例的隔離，迅速拉起新實(shí)例實(shí)現(xiàn)替換，降低業(yè)務(wù)影響。

6 未來規(guī)劃

• 場景化解決方案：接入Serverless的場景眾多，如SSR、后臺(tái)管理端、BFF等，不同的場景有不同的項(xiàng)目模板、場景配置，如伸縮配置、觸發(fā)器配置等，另外，不同的語言，配置也有所不同。這無形中增加了業(yè)務(wù)的使用成本，給新業(yè)務(wù)的接入帶來了阻礙。因此，我們考慮場景化的思路來建設(shè)平臺(tái)，將平臺(tái)的能力與場景強(qiáng)關(guān)聯(lián)起來，平臺(tái)深度沉淀各場景的基本配置和資源，這樣不同的場景，業(yè)務(wù)只需要簡單的配置就可以將Serverless玩轉(zhuǎn)起來。
• 傳統(tǒng)微服務(wù)Serverless化：即是路線選型中提到的面向應(yīng)用的Serverless服務(wù)。在美團(tuán)使用最廣的開發(fā)語言是Java，公司內(nèi)部存在大量的傳統(tǒng)的微服務(wù)項(xiàng)目，這些項(xiàng)目如果都遷移到函數(shù)模式，顯然是不現(xiàn)實(shí)的。試想如果這些傳統(tǒng)的微服務(wù)項(xiàng)目不用改造，也能直接享受Serverless的技術(shù)紅利，其業(yè)務(wù)價(jià)值不言而喻。因此，傳統(tǒng)微服務(wù)的Serverless化是我們未來拓展業(yè)務(wù)的一個(gè)重要方向。在實(shí)施路徑上，我們會(huì)考慮將服務(wù)治理體系（如ServiceMesh）與Serverless做技術(shù)融合，服務(wù)治理組件為Serverless提供伸縮指標(biāo)支持并在伸縮過程中實(shí)現(xiàn)精準(zhǔn)的流量調(diào)配。
• 冷啟動(dòng)優(yōu)化：當(dāng)前雖然函數(shù)的冷啟動(dòng)優(yōu)化已經(jīng)取得了較好的成績，尤其是平臺(tái)側(cè)的系統(tǒng)啟動(dòng)耗時(shí)，提升空間已經(jīng)非常有限，但業(yè)務(wù)代碼自身的啟動(dòng)耗時(shí)還是非常突出，尤其是傳統(tǒng)Java微服務(wù)，基本是分鐘級(jí)別的啟動(dòng)耗時(shí)。因此，后續(xù)我們的冷啟動(dòng)優(yōu)化會(huì)重點(diǎn)關(guān)注業(yè)務(wù)自身的啟動(dòng)耗時(shí)，爭取極大降低業(yè)務(wù)自身的啟動(dòng)時(shí)間。在具體優(yōu)化方法上，我們會(huì)考慮采用AppCDS、GraalVM等技術(shù)，降低業(yè)務(wù)自身啟動(dòng)耗時(shí)。
• 其他規(guī)劃
• 豐富完善研發(fā)工具，提升研發(fā)效率，如IDE插件等。

• 打通上下游技術(shù)生態(tài)，深度融入公司現(xiàn)有技術(shù)體系，減少因上下游平臺(tái)帶來使用障礙。

• 容器輕量化，輕量化的容器能夠帶來更優(yōu)的啟動(dòng)耗時(shí)以及更佳的資源利用率，因此，容器輕量化一直是Serverless的不懈追求。在具體落地上，準(zhǔn)備聯(lián)合容器設(shè)施團(tuán)隊(duì)一起推進(jìn)容器中的一些Agent采用DaemonSet方式部署，下沉到宿主機(jī)，提升容器的有效載荷。

作者簡介

• 殷琦、華珅、飛飛、志洋、奕錕等，來自基礎(chǔ)架構(gòu)部應(yīng)用中間件團(tuán)隊(duì)。
• 佳文、凱鑫，亞輝等，來自金融技術(shù)平臺(tái)大前端團(tuán)隊(duì)。