• 1 背景

• 2 快速驗證，落地MVP版本

• 2.1 技術(shù)選型

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

• 2.3 流程設(shè)計

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

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

• 2.6 彈性伸縮

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

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

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

• 3.3 高可用保障

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

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

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

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

• 4.3 開放平臺能力

• 4.4 支持合并部署

• 5 落地場景、收益

• 5.1 落地場景

• 5.2 落地收益

• 6 未來規(guī)劃

• 作者簡介

• 招聘信息

1 背景

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

回顧計算行業(yè)的發(fā)展歷程，基礎(chǔ)設(shè)施從物理機到虛擬機，再從虛擬機到容器；服務(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ā)展趨勢，大家可能會發(fā)現(xiàn)，不論是基礎(chǔ)設(shè)施還是服務(wù)架構(gòu)，都是從大往小或者由巨到微的方向上演進，這種演變的本質(zhì)原則無非是解決資源成本或者研發(fā)效率的問題。當然，Serverless也不例外，它也是用來解決這兩個方面的問題：

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

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

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

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

2 快速驗證，落地MVP版本

2.1 技術(shù)選型

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

2.1.1 演進路線

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

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

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

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

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

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

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

2.1.3 開發(fā)語言

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

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

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

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

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

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

2.3 流程設(shè)計

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

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

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

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

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

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

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

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

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

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

在美團的技術(shù)體系中，由于多年的技術(shù)沉淀，很難在一個純粹的容器（沒有任何其他依賴）中運行公司的業(yè)務(wù)邏輯。因為公司的容器中沉淀了很多環(huán)境或服務(wù)治理等能力，如服務(wù)治理的Agent服務(wù)以及實例環(huán)境配置、網(wǎng)絡(luò)配置等。

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

2.6 彈性伸縮

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

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

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

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

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

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

• 針對實例伸縮比較頻繁問題，我們在彈性伸縮組件內(nèi)維護了統(tǒng)計數(shù)據(jù)的滑動窗?，通過計算均值來平滑指標，還通過延時縮容，實時擴容來緩解頻繁擴縮問題。另外，我們增加了基于QPS指標的伸縮策略，因為QPS指標相對并發(fā)度指標會更加穩(wěn)定。
• 針對擴容來不及問題，我們采取提前擴容的手段，當達到實例閾值的70%就擴容，能夠比較好的緩解這個問題。除此之外，我們還支持了多指標混合伸縮（并發(fā)度、QPS、CPU、Memory），定時伸縮等策略，滿足各種業(yè)務(wù)需求。

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

3.2 冷啟動優(yōu)化

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

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

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

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

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

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

3.3 高可用保障

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

3.3.1 平臺高可用

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

• 架構(gòu)層：我們針對有狀態(tài)服務(wù)，如彈性伸縮模塊，采用了主從架構(gòu)，當主節(jié)點異常時從節(jié)點會立即替換。另外，我們還實現(xiàn)了架構(gòu)上的多層隔離。橫向地域隔離：Kubernetes兩地兩集群強隔離、服務(wù)（事件網(wǎng)關(guān)、彈性伸縮）集群內(nèi)兩地弱隔離（上海的彈性伸縮只負責上海Kubernetes集群內(nèi)的業(yè)務(wù)伸縮，事件網(wǎng)關(guān)存在兩地調(diào)用需求，需訪問兩地Kubernetes）?？v向業(yè)務(wù)線隔離：服務(wù)業(yè)務(wù)線強隔離，不同業(yè)務(wù)線使用不同集群服務(wù)；在Kubernetes層的資源用namespace實現(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)控運營層：主要通過完善系統(tǒng)監(jiān)控告警、梳理核心鏈路并推動相關(guān)依賴方進行治理。另外，我們會定期梳理SOP并通過故障演練平臺實施故障注入演練，發(fā)現(xiàn)系統(tǒng)隱患問題。
• 業(yè)務(wù)視角層：我們開發(fā)了在線不間斷實時巡檢服務(wù)，通過模擬用戶函數(shù)的請求流量，實時檢測系統(tǒng)的核心鏈路是否正常。

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

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

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

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

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

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

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

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

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

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

4.1 提供研發(fā)工具

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

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

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

4.3 開放平臺能力

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

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

4.4 支持合并部署

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

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

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

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

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

5 落地場景、收益

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

5.1 落地場景

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

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

5.2 落地收益

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

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

6 未來規(guī)劃

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

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

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

作者簡介

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