酷扯兒
《酷扯兒》官方帳號
「來源: ｜前端迷 ID：love_frontend」
總第447篇
2021年 第017篇
Serverless是目前比較熱門的技術話題，各大雲平台以及互聯網大廠內部都在積極建設Serverless產品。本文將介紹美團Serverless產品在落地過程中的一些實踐經驗，其中包括技術選型的考量、系統的詳細設計、系統穩定性優化、產品的周邊生態建設以及在美團的落地情況。雖然各個公司的背景不盡相同，但總有一些可以相互借鑒的思路或方法，希望能給大家帶來一些啟發或者幫助。
1 背景2 快速驗證，落地MVP版本2.1 技術選型2.2 架構設計2.3 流程設計2.4 函數觸發2.5 函數執行2.6 彈性伸縮3 優化核心技術，保障業務穩定性3.1 彈性伸縮優化3.2 冷啟動優化3.3 高可用保障3.4 容器穩定性優化4 完善生態，落實收益4.1 提供研發工具4.2 融合技術生態4.3 開放平台能力4.4 支持合並部署5 落地場景、收益5.1 落地場景5.2 落地收益6 未來規劃作者簡介招聘信息1 背景
Serverless一詞於2012年被提出，2014年由於亞馬遜的AWS Lambda無服務器計算服務的興起，而被大家廣泛認知。Serverless通常被直譯成“無服務器”，無服務器計算是可以讓用戶在不考慮服務器的情況下構建並運行應用程序。使用無服務器計算，應用程序仍在服務器上運行，但所有服務器管理工作均由Serverless平台負責。如機器申請、代碼發布、機器宕機、實例擴縮容、機房容災等都由平台幫助自動完成，業務開發只需考慮業務邏輯的實現即可。
回顧計算行業的發展歷程，基礎設施從物理機到虛擬機，再從虛擬機到容器；服務架構從傳統單體應用架構到SOA架構，再從SOA架構到微服務架構。從基礎設施和服務架構兩條主線來看整體技術發展趨勢，大家可能會發現，不論是基礎設施還是服務架構，都是從大往小或者由巨到微的方向上演進，這種演變的本質原則無非是解決資源成本或者研發效率的問題。當然，Serverless也不例外，它也是用來解決這兩個方面的問題：
資源利用率
：Serverless產品支持快速彈性伸縮能力，能夠幫助業務提升資源利用率，在業務流量高峰時，業務的計算能力、容量自動擴容，承載更多的用戶請求，而在業務流量下降時，所使用的資源也會同時收縮，避免資源浪費。研發運維效率
：在Serverless上開發人員一般只需要填寫代碼路徑或者上傳代碼包，平台能夠幫助完成構建、部署的工作。開發人員不直接面對機器，對於機器的管理，機器是否正常以及流量高低峰的是否需要擴縮容等問題，這些統統不需要去考慮，由Serverless產品幫助研發人員去完成。這樣就能使他們從繁瑣的運維工作中解放出來，從DevOps轉向NoOps，更加專注於業務邏輯的實現。雖然AWS在2014年就推出了第一個Serverless產品Lambda，但Serverless技術在國內的應用一直不溫不火。不過近兩三年，在容器、Kubernetes以及雲原生等技術的推動下，Serverless技術迅速發展，國內各大互聯網公司都在積極建設Serverless相關產品，探索Serverless技術的落地。在這種背景下，美團也於2019年初開始了Serverless平台的建設，內部項目名稱為Nest
。
截止到目前，Nest平台已經過兩年的建設，回顧整體的建設過程，主要經歷了以下三個階段：
快速驗證，落地MVP版本
：我們通過技術選型、產品與架構設計、開發迭代，快速落地了Serverless產品的基本的能力，如構建、發布、彈性伸縮、對接觸發源、執行函數等。上線後，我們推進了一些業務的試點接入，幫助驗證打磨產品。優化核心技術，保障業務穩定性
：有了前期的試點業務驗證，我們很快發現產品的存在的一些穩定性相關的問題，主要有彈性伸縮的穩定性、冷啟動的速度、系統與業務的可用性、容器的穩定性。針對這些問題我們對各個問題涉及的技術點做了專項的優化改進。完善技術生態，落實收益
：優化了核心技術點後，產品逐漸成熟穩定，但依然面臨生態性問題，如研發工具欠缺，上下遊產品沒有打通、平台開放能力不足等問題，影響或阻礙了產品的推廣使用。因此，我們繼續完善產品的技術生態，掃清業務接入使用障礙，落實產品的業務收益。2 快速驗證，落地MVP版本
2.1 技術選型
建設Nest平台，首要解決的就是技術選型問題，Nest主要涉及三個關鍵點的選型：演進路線、基礎設施、開發語言。
2.1.1 演進路線
起初Serverless服務主要包含FaaS（Function as a Service）和BaaS（Backend as a Service），近幾年Serverless的產品領域有所擴張，它還包含面向應用的Serverless服務。
FaaS
：是運行在一個無狀態的計算容器中的函數服務，函數通常是事件驅動、生命周期很短（甚至只有一次調用）、完全由第三方管理的。業界相關FaaS產品有AWS的Lambda、阿裏雲的函數計算等。BaaS
：是建立在雲服務生態之上的後端服務。業界相關BaaS產品包括AWS的S3、DynamoDB等。面向應用的Serverless服務：如Knative，它提供了從代碼包到鏡像的構建、部署以及實例彈性伸縮等全面的服務托管能力，公有雲產品有Google Cloud Run（基於Knative）、阿裏雲的SAE（Serverless Application Engine）。
在美團內部，BaaS產品其實就是內部的中間件以及底層服務等，它們經過多年的發展，已經非常豐富且成熟了。因此，在美團的Serverless產品演進主要在函數計算服務和面向應用的Serverless服務兩個方向上。那究竟該如何演進呢？當時主要考慮到在業界FaaS函數計算服務相對於面向應用的Serverless服務來說，更加成熟且確定。因此，我們決定“先建設FaaS函數計算服務，再建設面向應用的Serverless服務
”這樣一條演進路線。
2.1.2 基礎設施
由於彈性伸縮是Serverless平台必備的能力，因此Serverless必然涉及到底層資源的調度和管理。這也是為什麼當前業界有很多開源的Serverless產品（如OpenFaaS、Fission、Nuclio、Knative等）是基於Kubernetes來實現的，因為這種選型能夠充分利用Kubernetes的基礎設施的管理能力。在美團內部基礎設施產品是Hulk，雖然Hulk是基於Kubernetes封裝後的產品，但Hulk在落地之初考慮到落地難度以及各種原因，最終未按照原生的方式來使用Kubernetes，並且在容器層采用的也是富容器模式。
在這種歷史背景下，我們在做基礎設施選型時就面臨兩種選項：一是使用公司的Hulk來作為Nest的基礎設施（非原生Kubernetes），二是采用原生Kubernetes基礎設施。我們考慮到當前業界使用原生Kubernetes是主流趨勢並且使用原生Kubernetes還能充分利用Kubernetes原生能力，可以減少重複開發。因此，最終考量的結果是我們采用了原生Kubernetes作為我們的基礎設施
。
2.1.3 開發語言
雖然無論在雲原生領域，還是Kubernetes的生態中，Golang都更加主流，但在美團Java才是使用最廣泛的語言，相比Golang，Java在公司內部生態比較好。因此，在語言的選型上我們選擇了Java語言
。在Nest產品開發之初，Kubernetes社區的Java客戶端還不夠完善，但隨著項目的推進，社區的Java客戶端也逐漸豐富了起來，目前已經完全夠用了。另外，我們也在使用過程中，也貢獻了一些Pull Request，反哺了社區。
2.2 架構設計
基於以上的演進路線、基礎設施、開發語言的選型，我們進行了Nest產品的架構設計。
在整體的架構上，流量由EventTrigger（事件觸發源，如Nginx、應用網關、定時任務、消息隊列、RPC調用等）觸發到Nest平台，Nest平台內會根據流量的特征路由到具體函數實例，觸發函數執行，而函數內部代碼邏輯可以調用公司內的各個BaaS服務，最終完成函數的執行，返回結果。
圖1 FaaS架構圖在技術實現上，Nest平台使用Kubernetes作為基礎底座並適當參考了一些Knative的優秀設計，在其架構內部主要由以下幾個核心部分組成：
事件網關
：核心能力是負責對接外部事件源的流量，然後路由到函數實例上；另外，網關還負責統計各個函數的進出流量信息，為彈性伸縮模塊提供伸縮決策的數據支撐。彈性伸縮
：核心能力是負責函數實例的彈性伸縮，伸縮主要根據函數運行的流量數據以及實例閾值配置計算函數目標實例個數，然後借助Kubernetes的資源控制能力，調整函數實例的個數。控制器
：核心能力是負責Kubernetes CRD（Custom Resource Definition）的控制邏輯實現。函數實例
：函數的運行實例。當事件網關流量觸發過來，會在函數實例內執行相應的函數代碼邏輯。治理平台
：面向用戶使用的平台，負責函數的構建、版本、發布以及一些函數元信息的管理等。
圖2 Nest架構圖2.3 流程設計
在具體的CI/CD流程上，Nest又與傳統的模式有何區別呢？為了說明這個問題，我們先來看一看在Nest平台上函數的整體生命周期怎樣的？具體有以下四個階段：構建、版本、部署、伸縮。
構建
：開發的代碼和配置通過構建生成鏡像或可執行文件。版本
：構建生成的鏡像或可執行文件加上發布配置形成一個不可變的版本。部署
：將版本發布，即完成部署。伸縮
：根據函數實例的流量以及負載等信息，來進行實例的彈性擴縮容。就這四個階段來看，Nest與傳統的CI/CD流程本質區別在於部署和伸縮：傳統的部署是感知機器的，一般是將代碼包發布到確定的機器上，但Serverless是要向用戶屏蔽機器的（在部署時，可能函數的實例數還是0）；另外，傳統的模式一般是不具備動態擴縮容的，而Serverless則不同，Serverless平台會根據業務的自身流量需要，進行動態擴縮容。後續章節會詳細講解彈性伸縮，因此這裏我們只探討部署的設計。
部署的核心點在於如何向用戶屏蔽機器？對於這個問題，我們抽象了機器，提出了分組
的概念，分組是由SET（單元化架構的標識，機器上會帶有該標識）、泳道（測試環境隔離標識，機器上會帶有該標識）、區域（上海、北京等）三個信息組成。用戶部署只需在相應的分組上進行操作，而不用涉及到具體機器。能夠做到這些的背後，是由Nest平台幫助用戶管理了機器資源，每次部署會根據分組信息來實時初始化相應的機器實例。
圖3 函數生命周期2.4 函數觸發
函數的執行是由事件觸發的。完成函數的觸發，需要實現以下四個流程：
流量引入
：向事件源注冊事件網關的信息，將流量引入到事件網關。如針對MQ事件源，通過注冊MQ的消費組，引入MQ的流量到事件網關。流量適配
：事件網關對事件源進入的流量進行適配對接。函數發現
：對函數元數據（函數實例信息、配置信息等）的獲取過程，類似微服務的服務發現過程。事件網關接受的事件流量需要發送到具體的函數實例，這就需要對函數進行發現。這裏發現實質是獲取Kubernetes中的內置資源或者CRD資源中存儲的信息。函數路由
：事件流量的路由過程，路由到特定的函數實例上。這裏為了支持傳統路由邏輯（如SET、泳道、區域路由等）以及版本路由能力，我們采用了多層路由，第一層路由到分組（SET、泳道、區域路由），第二層路由到具體版本。同版本內的實例，通過負載均衡器選擇出具體實例。另外，通過該版本路由，我們很輕松的支持了金絲雀、藍綠發布。
圖4 函數觸發2.5 函數執行
函數不同於傳統的服務，傳統的服務是個可執行的程序，但函數不同，函數是代碼片段，自身是不能單獨執行的。那流量觸發到函數實例後，函數是如何執行的呢？
函數的執行的首要問題是函數的運行環境：由於Nest平台是基於Kubernetes實現的，因此函數一定是運行在Kubernetes的Pod（實例）內，Pod內部是容器，容器的內部是運行時，運行時是函數流量接收的入口，最終也是由運行時來觸發函數的執行。一切看起來是那麼的順利成章，但我們在落地時是還是遇到了一些困難，最主要的困難是讓開發同學可以在函數內無縫的使用公司內的組件
，如OCTO（服務框架）、Celler（緩存系統）、DB等。
在美團的技術體系中，由於多年的技術沉澱，很難在一個純粹的容器（沒有任何其他依賴）中運行公司的業務邏輯。因為公司的容器中沉澱了很多環境或服務治理等能力，如服務治理的Agent服務以及實例環境配置、網絡配置等。
因此，為了業務在函數內無縫的使用公司內的組件，我們複用公司的容器體系來降低業務編寫函數的成本。但複用公司的容器體系也沒那麼簡單，因為在公司內沒有人試過這條路，Nest是公司第一個基於原生Kubernetes建設的平台，“第一個吃螃蟹的人”總會遇到一些坑。對於這些坑，我們只能在推進過程中“逢山開路，遇水搭橋”，遇到一個解決一個。總結下來，其中最核心的是在容器的啟動環節打通的CMDB等技術體系，讓運行函數的容器與開發同學平時申請的機器用起來沒有任何區別。
圖5 函數執行2.6 彈性伸縮
彈性伸縮的核心問題主要有三個：什麼時候伸縮，伸縮多少，伸縮的速度快不快？也就是伸縮時機、伸縮算法、伸縮速度的問題。
伸縮時機
：根據流量Metrics實時計算函數期望實數，進擴縮。流量的Metrics數據來自於事件網關，這裏主要統計函數的並發度指標，彈性伸縮組件每秒中會主動從事件網關獲取一次Metrics數據。伸縮算法
：並發度/單實例閾值=期望實例數。根據收集的Metrics數據以及業務配置的閾值，通過算法計算出期望的實例數，然後通過Kubernetes接口設置具體實例數。整個算法看起來雖然簡單，但非常穩定、魯棒性好。伸縮速度
：主要取決於冷啟動時間，在下個章節會詳細講解這塊內容。除了基本的擴縮容能力，我們還支持了伸縮到0，支持配置最大、最小實例數（最小實例即預留實例）。伸縮到0的具體實現是，我們在事件網關內部增加了激活器模塊，當函數無實例時，會將函數的請求流量緩存在激活器內部，然後立即通過流量的Metrics去驅動彈性伸縮組件進行擴容，等擴容的實例啟動完成後，激活器再將緩存的請求重試到擴容的實例上觸發函數執行。
圖6 彈性伸縮3 優化核心技術，保障業務穩定性
3.1 彈性伸縮優化
上面提到的伸縮時機、伸縮算法、伸縮速度這三要素都是理想情況下的模型，尤其是伸縮速度，當前技術根本做不到毫秒級別的擴縮容。因此，在線上實際場景中，彈性伸縮會存在一些不符合預期的情況，比如實例伸縮比較頻繁或者擴容來不及，導致服務不太穩定的問題。
針對實例伸縮比較頻繁問題
，我們在彈性伸縮組件內維護了統計數據的滑動窗，通過計算均值來平滑指標，還通過延時縮容，實時擴容來緩解頻繁擴縮問題。另外，我們增加了基於QPS指標的伸縮策略，因為QPS指標相對並發度指標會更加穩定。針對擴容來不及問題
，我們采取提前擴容的手段，當達到實例閾值的70%就擴容，能夠比較好的緩解這個問題。除此之外，我們還支持了多指標混合伸縮（並發度、QPS、CPU、Memory），定時伸縮等策略，滿足各種業務需求。下圖展示的是線上彈性伸縮的真實案例（配置的最小實例數為4，單實例閾值100，閾值使用率0.7），其中上半部分是業務每秒的請求數，下半部分是擴縮實例的決策圖，可以看到在成功率100%的情況下，業務完美應對流量高峰。
圖7 彈性伸縮案例3.2 冷啟動優化
冷啟動是指在函數調用鏈路中包含了資源調度、鏡像/代碼下載、啟動容器、運行時初始化、用戶代碼初始化等環節。當冷啟動完成後，函數實例就緒，後續請求就能直接被函數執行。冷啟動在Serverless領域至關重要，它的耗時決定了彈性伸縮的速度。
所謂“天下武功，無堅不破，唯快不破”，這句話在Serverless領域也同樣受用。試想如果拉起一個實例足夠快，快到毫秒級別，那幾乎所有的函數實例都可以縮容到0，等有流量時，再擴容實例處理請求，這對於存在高低峰流量的業務將極大的節省機器資源成本。當然，理想很豐滿，現實很骨感。做到毫秒級別幾乎不可能。但只要冷啟動時間越來越短，成本自然就會越來越低，另外，極短的冷啟動時間對伸縮時函數的可用性以及穩定性都有莫大的好處。
圖8 冷啟動的各個階段冷啟動優化是個循序漸進的過程，我們對冷啟動優化主要經歷了三個階段：鏡像啟動優化、資源池優化、核心路徑優化。
鏡像啟動優化
：我們對鏡像啟動過程中的耗時環節（啟動容器和運行時初始化）進行了針對性優化，主要對容器IO限速、一些特殊Agent啟動耗時、啟動盤與數據盤數據拷貝等關鍵點的優化，最終將啟動過程中的系統耗時從42s優化到12s左右。
圖9 鏡像啟動優化成果資源池優化
：鏡像啟動耗時優化到12s，基本已經快達到瓶頸點，再繼續優化空間不大。因此，我們想能否繞開鏡像啟動的耗時環節？最終，我們采用了一個比較簡單思路“空間換時間”，用資源池方案：緩存一些已啟動的實例，當需要擴容時，直接從資源池獲取實例，繞開鏡像啟動容器的環節，最終效果很明顯，將啟動的系統耗時從12s優化到3s。這裏需要說明的是資源池自身也是通過Kubernetes的Depolyment進行管理，池中實例被取走會立即自動補充。
圖10 資源池優化成果核心路徑優化
：在資源池優化的基礎上，我們再次精益求精，針對啟動流程中的下載與解壓代碼兩個耗時環節進行優化，過程中我們采用了高性能的壓縮解壓算法（LZ4與Zstd）以及並行下載和解壓技術，效果非常好。另外，我們還支持了通用邏輯（中間件、依賴包等）下沉，通過預加載的方式，最終將函數端到端的啟動耗時優化到2s，這就意味著擴容一個函數實例只需要2s（包含函數啟動）。如果排除掉函數自身的初始化啟動耗時，平台側的耗時已在毫秒級別。3.3 高可用保障
說到高可用，對於一般的平台，指的就是平台自身的高可用，但Nest平台有所不同，Nest的高可用還包含托管在Nest平台上的函數。因此，Nest的高可用保障需要從平台和業務函數兩個方面著手。
3.3.1 平台高可用
對平台的高可用，Nest主要從架構層、服務層、監控運營層、業務視角層面都做了全面的保障。
架構層
：我們針對有狀態服務，如彈性伸縮模塊，采用了主從架構，當主節點異常時從節點會立即替換。另外，我們還實現了架構上的多層隔離。橫向地域隔離：Kubernetes兩地兩集群強隔離、服務（事件網關、彈性伸縮）集群內兩地弱隔離（上海的彈性伸縮只負責上海Kubernetes集群內的業務伸縮，事件網關存在兩地調用需求，需訪問兩地Kubernetes）。縱向業務線隔離：服務業務線強隔離，不同業務線使用不同集群服務；在Kubernetes層的資源用namespace實現業務線弱隔離。
圖11 部署架構
服務層
：主要指的是事件網關服務，由於所有的函數流量都經過事件網關，因此事件網關的可用性尤為重要，這層我們支持了限流和異步化，保障服務的穩定性。監控運營層
：主要通過完善系統監控告警、梳理核心鏈路並推動相關依賴方進行治理。另外，我們會定期梳理SOP並通過故障演練平台實施故障注入演練，發現系統隱患問題。業務視角層
：我們開發了在線不間斷實時巡檢服務，通過模擬用戶函數的請求流量，實時檢測系統的核心鏈路是否正常。3.3.2 業務高可用
對於業務高可用，Nest主要從服務層、平台層兩個層面做了相關的保障。
服務層
：支持了業務降級、限流能力：當後端函數故障時，可通過降級配置，返回降級結果。針對異常的函數流量，平台支持限制其流量，防止後端函數實例的被異常流量打垮。平台層
：支持了實例保活、多層級容災以及豐富的監控告警能力：當函數實例異常時，平台會自動隔離該實例並立即擴容新實例。平台支持業務多地區部署，在同地區將函數實例盡可能打散不同機房。當宿主機、機房、地區故障時，會立即在可用宿主機、可用機房或可用區重建新實例。另外，平台自動幫業務提供了函數在時延、成功率、實例伸縮、請求數等多種指標的監控，當在這些指標不符合預期時，自動觸發告警，通知業務開發和管理員。
圖12 業務監控
3.4 容器穩定性優化
前文已提到，Serverless與傳統模式在CI/CD流程上是不同的，傳統模式都是事先准備好機器然後部署程序，而Serverless則是根據流量的高低峰實時彈性擴縮容實例。當新實例擴容出來後，會立即處理業務流量。這聽起來貌似沒什麼毛病，但在富容器生態下是存在一些問題的：我們發現剛擴容的機器負載非常高，導致一些業務請求執行失敗，影響業務可用性。
分析後發現主要是因為容器啟動後，運維工具會進行Agent升級、配置修改等操作，這些操作非常耗CPU。同在一個富容器中，自然就搶占了函數進程的資源，導致用戶進程不穩定。另外，函數實例的資源配置一般比傳統服務的機器要小很多，這也加劇了該問題的嚴重性。基於此，我們參考業界，聯合容器設施團隊，落地了輕量級容器，將運維的所有Agent放到Sidecar容器中，而業務的進程單獨放到App容器中。采用這種容器的隔離機制，保障業務的穩定性。同時，我們也推動了容器裁剪計劃，去掉一些不必要的Agent。
圖13 輕量級容器4 完善生態，落實收益
Serverless是個系統工程，在技術上涉及到Kubernetes、容器、操作系統、JVM、運行時等各種技術，在平台能力上涉及到CI/CD各個流程的方方面面。
為了給用戶提供極致的開發體驗，我們為用戶提供了開發工具的支持，如CLI（Command Line Interface）、WebIDE等。為了解決現有上下遊技術產品的交互的問題，我們與公司現有的技術生態做了融合打通，方便開發同學使用。為了方便下遊的集成平台對接，我們開放了平台的API，實現Nest賦能各下遊平台。針對容器過重，系統開銷大，導致低頻業務函數自身資源利用率不高的問題，我們支持了函數合並部署，成倍提升資源利用率。
4.1 提供研發工具
開發工具能夠降低平台的使用成本，幫助開發同學快速的進行CI/CD流程。目前Nest提供了CLI工具，幫助開發同學快速完成創建應用、本地構建、本地測試、Debug、遠程發布等操作。Nest還提供了WebIDE，支持在線一站式完成代碼的修改、構建、發布、測試。
4.2 融合技術生態
僅支持這些研發工具還是不夠的，項目推廣使用後，我們很快就發現開發同學對平台有了新的需求，如無法在Pipeline流水線、線下服務實例編排平台上完成對函數的操作，這對我們項目的推廣也形成了一些阻礙。因此，我們融合這些公司的成熟技術生態，打通了Pipeline流水線等平台，融入到現有的上下遊技術體系內，解決用戶的後顧之憂。
4.3 開放平台能力
有很多Nest的下遊解決方案平台，如SSR（Server Side Render）、服務編排平台等，通過對接Nest的OpenAPI，實現了生產力的進一步解放。例如，不用讓開發同學自己去申請、管理和運維機器資源，就能夠讓用戶非常快速的實現一個SSR項目或者編排程序從0到1的創建、發布與托管。
Nest除了開放了平台的API，還對用戶提供了自定義資源池的能力，擁有了該項能力，開發同學可以定制自己的資源池，定制自己的機器環境，甚至可以下沉一些通用的邏輯，實現冷啟動的進一步優化。
4.4 支持合並部署
合並部署指的是將多個函數部署在一個機器實例內。合並部署的背景主要有兩個：
當前的容器較重，容器自身的系統開銷較大，導致業務進程資源利用率不高（尤其是低頻業務）。在冷啟動耗時不能滿足業務對時延的要求的情況下，我們通過預留實例來解決業務的需求。基於這兩個背景，我們考慮支持合並部署，將一些低頻的函數部署到同一個機器實例內，來提升預留實例中業務進程的資源利用率。
在具體實現上，我們參考Kubernetes的設計方案，設計了一套基於Sandbox的函數合並部署體系（每個Sandbox就是一個函數資源），將Pod類比成Kubernetes的Node資源，Sandbox類比成Kubernetes的Pod資源，Nest Sidecar類比成Kubelet。為了實現Sandbox特有的部署、調度等能力，我們還自定義了一些Kubernetes資源（如SandboxDeployment、SandboxReplicaSet、SandboxEndpoints等）來支持函數動態插拔到具體的Pod實例上。
圖14 合並部署架構除此之外，在合並部署的形態下，函數之間的隔離性
也是不可回避的問題。為了盡可能的解決函數（合並在同一個實例中）之間的互相干擾問題，在Runtime的實現上，我們針對Node.js和Java語言的特點采取了不同的策略：Node.js語言的函數使用不同的進程來實現隔離，而Java語言的函數，我們采用類加載隔離。采用這種策略的主要原因是由於Java進程占用內存空間相較於Node.js進程會大很多。
5 落地場景、收益
目前Nest產品在美團前端Node.js領域非常受歡迎，也是落地最廣泛的技術棧。當前Nest產品在美團前端已實現了規模化落地，幾乎涵蓋了所有業務線，接入了大量的B/C端的核心流量。
5.1 落地場景
具體的落地前端場景有：BFF（Backend For Frontend）、CSR（Client Side Render）/SSR（Server Side Render）、後台管理平台、定時任務、數據處理等。
BFF場景
：BFF層主要為前端頁面提供數據，采用Serverless模式，前端同學不需要考慮不擅長的運維環節，輕松實現了BFF向SFF（Serverless For Frontend）模式的轉變。CSR/SSR場景
：CSR/SSR指的是客戶端渲染和服務端渲染，有了Serverless平台，不用考慮運維環節，更多的前端業務來嘗試使用SSR來實現前端首屏的快速展現。後台管理平台場景
：公司有很多的後台管理平台的Web服務，它們雖然相較於函數是比較重的，但完全可以直接托管Serverless平台，充分享受Serverless平台極致的發布和運維效率。定時任務場景
：公司存在很多周期性任務，如每隔幾秒拉取數據，每天0點清理日志，每小時收集全量數據並生成報表等，Serverless平台直接與任務調度系統打通，只需寫好任務的處理邏輯並在平台上配置定時觸發器，即完成定時任務的接入，完全不用管理機器資源。數據處理場景
：將MQ Topic作為事件源接入Serverless平台，平台會自動訂閱Topic的消息，當有消息消費時，觸發函數執行，類似定時任務場景，作為用戶也只需寫好數據處理的邏輯並在平台上配置好MQ觸發器，即完成MQ消費端的接入，完全不用管理機器資源。5.2 落地收益
Serverless的收益是非常明顯的，尤其在前端領域，大量的業務接入已是最好的說明。具體收益，從以下兩個方面分別來看：
降成本
：通過Serverless的彈性伸縮能力，高頻業務資源利用率能提升到40%～50%；低頻業務函數通過合並部署，也能極大降低函數運行成本。提效率
：整體研發研發效率提升約40%。從代碼開發來看，提供完備的CLI、WebIDE等研發工具，能夠幫助開發同學生成代碼腳手架，聚焦編寫業務邏輯，快速完成本地測試；另外，讓業務服務零成本具備在線查看日志與監控的能力。從發布來看，通過雲原生的模式，業務無需申請機器，發布、回滾都是秒級別的體驗。另外，還能利用平台天然能力，配合事件網關，實現切流、完成金絲雀測試等。從日常運維來看，業務無需關注機器故障、資源不足、機房容災等傳統模式該考慮的問題，另外，當業務進程異常時，Nest能夠自動完成異常實例的隔離，迅速拉起新實例實現替換，降低業務影響。6 未來規劃
場景化解決方案
：接入Serverless的場景眾多，如SSR、後台管理端、BFF等，不同的場景有不同的項目模板、場景配置，如伸縮配置、觸發器配置等，另外，不同的語言，配置也有所不同。這無形中增加了業務的使用成本，給新業務的接入帶來了阻礙。因此，我們考慮場景化的思路來建設平台，將平台的能力與場景強關聯起來，平台深度沉澱各場景的基本配置和資源，這樣不同的場景，業務只需要簡單的配置就可以將Serverless玩轉起來。傳統微服務Serverless化：
即是路線選型中提到的面向應用的Serverless服務。在美團使用最廣的開發語言是Java，公司內部存在大量的傳統的微服務項目，這些項目如果都遷移到函數模式，顯然是不現實的。試想如果這些傳統的微服務項目不用改造，也能直接享受Serverless的技術紅利，其業務價值不言而喻。因此，傳統微服務的Serverless化是我們未來拓展業務的一個重要方向。在實施路徑上，我們會考慮將服務治理體系（如ServiceMesh）與Serverless做技術融合，服務治理組件為Serverless提供伸縮指標支持並在伸縮過程中實現精准的流量調配。冷啟動優化：
當前雖然函數的冷啟動優化已經取得了較好的成績，尤其是平台側的系統啟動耗時，提升空間已經非常有限，但業務代碼自身的啟動耗時還是非常突出，尤其是傳統Java微服務，基本是分鐘級別的啟動耗時。因此，後續我們的冷啟動優化會重點關注業務自身的啟動耗時，爭取極大降低業務自身的啟動時間。在具體優化方法上，我們會考慮采用AppCDS、GraalVM等技術，降低業務自身啟動耗時。其他規劃
豐富完善研發工具
，提升研發效率，如IDE插件等。打通上下遊技術生態，
深度融入公司現有技術體系，減少因上下遊平台帶來使用障礙。容器輕量化，
輕量化的容器能夠帶來更優的啟動耗時以及更佳的資源利用率，因此，容器輕量化一直是Serverless的不懈追求。在具體落地上，准備聯合容器設施團隊一起推進容器中的一些Agent采用DaemonSet方式部署，下沉到宿主機，提升容器的有效載荷。作者簡介
殷琦、華珅、飛飛、志洋、奕錕等，來自基礎架構部應用中間件團隊。佳文、凱鑫，亞輝等，來自金融技術平台大前端團隊。閱讀更多
---
前端|
算法 |
後端 |
數據
安全|
Android |
iOS |
運維 |
測試
---------- END ----------
招聘信息
美團基礎架構團隊誠招高級、資深技術專家，Base北京、上海。我們致力於建設美團全公司統一的高並發高性能分布式基礎架構平台，涵蓋數據庫、分布式監控、服務治理、高性能通信、消息中間件、基礎存儲、容器化、集群調度等基礎架構主要的技術領域。歡迎有興趣的同學投送簡歷到：tech@meituan.com。
