美團早期業務快速發展，各業務在 Node 應用上各取所長，但在可用性和運維上需要付出額外的維護成本。隨着美團建設了 Serverless 平台，前端也緊隨其後，將 Node 應用由傳統架構向 Serverless 架構演進，通過 Serverless 方式升級 Node 基礎設施。
本次分享將介紹美團建設 Serverless 前端研發體系的建設思路，並與大家分享如何為各業務提供統一的 Serverless 平台，支持業務向 Serverless 遷移，最後分享了美團的部分具體業務案例，希望給大家在 Serverless 技術轉型和實踐帶來一些啟發。
本文整理自美團前端技術專家張方成在 ArchSummit 全球架構師峰會（深圳站）上的演講分享，主題為「美團基於 Serverless 的前端研發體系建設和業務實踐」。分享主要分為四部分：1. 背景；2. 美團 Serverless 前端建設；3. 前端交付實踐；4. 未來規劃。
首先我們為什麼要做 Serverless？美團是一個一站式的生活服務平台，為消費者提供外賣旅遊等服務，為商戶提供營銷、配送等服務。作為美團技術團隊，我們需要為消費者、商戶還有內部的開發者提供很多的技術平台。隨着美團業務複雜度不斷增加，技術團隊面臨的挑戰也越來越大。
我們的技術架構演進可以分為三個階段，整體趨勢是複雜度下沉並服務化。
第一個階段，我們稱為基礎設施的服務化，這一階段由基礎技術平台負責基礎設施的維護工作，業務同學需要負責業務應用，以及一些平台軟件的開發和維護工作。
第二個階段，我們稱為平台服務化，這時候我們將業務應用原來維護的平台軟件部分下沉到技術基礎平台，由技術基礎平台統一負責平台和基礎設施的維護工作。
第三個階段，我們稱為業務邏輯託管服務化，這個時候我們將業務應用當中大量的通用邏輯下沉到技術基礎平台，由技術基礎平台統一負責基礎設施、平台軟件、業務應用底座相關的一些維護工作，業務開發者只需要維護相應的業務邏輯即可。
目前我們正處在由平台服務化向業務邏輯託管架構演進的階段，在這個時候，Serverless 是一個很重要的技術點。
2019 年我們上線了 Serverless 平台，Serverless 使業務開發者聚焦業務邏輯開發工作，主要幫助前端解決 Web 應用場景下的問題。美團的 Node 主要應用在 B 端、C 端以及工具型產品：B 端產品的特點是系統本身很複雜，更關注研發的效率；C 端產品的特點是訪問量比較大，更關注服務的穩定性；工具型產品的特點是訪問量比較低，但仍然需要占用大量的機器，更關注機器的費用問題。總結下來業務面臨的痛點主要有三個：
1、研發效率低，體現在研發過程當中，開發者仍然需要負責很多業務無關的工作；
2、運維成本比較高，體現在開發者需要在穩定性保障上做很多事情；
3、機器費用比較高，比如說機器需要冗餘部署，資源利用率整體也比較低。
Serverless 是如何幫助我們解決這些問題的？假如我們現在要開發一個 Node 應用，通常會涉及到基礎設施、平台軟件等工作，當然在業務應用層還需要考慮框架還有服務的可用性，包括性能、高並發這些問題，整體下來我們的運維成本從上至下越來越高。
Serverless 對前端開發者屏蔽了基礎設施、平台軟件，以及業務應用底座當中一些複雜的事情，使前端開發者可以聚焦在業務邏輯開發當中。
這是我們 Serverless 前端的全景，主要包括研發套件、PaaS 平台、技術組件，以及業務層的解決方案。我們通過研發套件的建設和技術組件的建設來提升業務的開發效率，通過 PaaS 平台的建設來為業務提供服務的架構和穩定保障能力，同時 PaaS 的彈性特點，可以很好解決原來系統與部署的問題。
研發套件主要是指研發流程當中需要的一些工具，比如說框架、開發工具和部署工具等等。在前端研發與 Serverless 結合的背景下，我們面臨的主要問題是，原有的研發流程當中一些工具不好用甚至是用不了，這些工具面臨重構。公司內開發就有很多研發框架，在 Serverless 下，我們需要的是一個開箱即用的 Serverless 研發框架。在調試階段，我們希望可以去調試 Serverless 下的雲函數能力；在構建部署階段，Serverless 當中我們部署的是函數，原有的發布工具支持也不是很好，我們希望可以去部署對函數友好的項目；在線上運維階段，我們也希望去提供 Serverless 架構下的一些運維工具，幫助業務降低在 Serverless 架構下的運維成本。
我們的整體思路展開來說，第一是在開發階段，通過開放能力的建設，去集成業務研發框架，使已有的框架可以低成本地在 Serverless 架構下運行起來；第二是提供整個研發流程中一些必要的工具，比如說在調試階段，提供本地 / 遠程的調試能力，在構建部署階段，提供部署組件、灰度組件，在線上運維階段，提供服務的監控、鏈路追蹤以及性能診斷等運維工具。
下面來看一下我們通過開放能力集成業務的框架，和在雲端開發體驗上的一些探索。
首先看一下我們如何通過開放的能力集成已有的框架。我們的策略是與公司內框架的提供者團隊合作共建，使已有的業務框架遵循相關的規範，沉澱到我們 Serverless 研發套件中來，這樣就可以面向公司範圍去提供框架服務，我們制訂了架構規範和部署規範，以及運維相關的規範。
同時我們基於 Serverless 架構，正在探索雲端的開發體驗，探索完全在線的開發結構模式，開發者只需要打開瀏覽器就可以實現項目的開發部署、運維等相關所有的事情，雲端開發可以幫助我們實現整個開發周期的閉環，包括項目的創建、開發、調試、部署，還有運維當中的一系列工作。
與傳統的本地開發模式相比，雲端開發幫助我們消除了本地線上頻繁的切換動作，提高了開發效率，同時雲端開發可以幫助我們實現高效的同步合作，雲端開發提供一致的橫向配置，以及可共享的開發環境，可以使代碼協作就像在線文檔協作一樣簡單，提高整體的協作效率。有了雲端開發並不意味着我們放棄了傳統的開發模式，兩者是可以互補的，目前我們也在探索實踐當中。
下面我們來看一下基礎組件，主要是指 PaaS 產品和運維產品。我們面臨的主要問題是學習和使用的成本比較高，主要體現在 SDK 同步、配置比較零散。我們有幾十個技術組件，比如數據庫、對象存儲、文件存儲等等，我們原有的使用方式是需要在代碼當中引入技術組件的 SDK，通過一系列的配置還有調試工作，使代碼和組件正常跑起來，整個流程下來的成本還是比較高的。我們的策略是為業務提供兩種簡化的使用方式：第一種是基於事件模式的使用方式，開發者只需要在 FaaS 管理端去配置化啟用相關的組件，不需要引入 SDK，開發者只需要提供一些 API 方法，我們去處理相關的邏輯即可，技術組件的 SDK 調用還有事件的觸發都由事件網關這一層來負責。第二種是基於運行時的使用方式，我們在函數運行時內部提供技術組件加載器，主要負責加載這些技術組件，開發者只需要在文件當中去配置相應的組件，同時也不需要引入 SDK，就可以在函數上下文當中去調用相應的實例以及相應的 API 方法。
我們下面來看一下 FaaS 平台，即雲函數平台。我們大體上可以把它分為運行態和管理態，運行態要負責事件流轉的過程。首先由觸發源來產生事件，經過事件網關分發到具體的業務實例當中的函數裡去處理，業務函數會對我們的事件做處理和響應。事件網關除了分發流量之外，還會做一些限流降級、流量統計等相關的工作。在實例這一層提供了函數沙箱，裡面運行的是業務函數，對業務函數起隔離的作用，在管理系統里提供函數的管理、發布以及監控等運維能力。
下面我們來看三個問題，首先是我們如何應對高並發問題，第二是我們如何降低機器的費用，第三個我們在穩定性保證建設方面做了哪些事情。
首先看一下我們是如何應對高並發的。Serverless 架構下，彈性的特點可以幫助我們在需要的時候得到更多的實例來承擔流量，事件網關會將我們的請求分散到不同的實例上，達到負載均衡的作用。我們支持高並發的一個關鍵是需要支持快速擴容，需要在短時間之內擴容到所有的實例，這樣服務才是足夠穩定的。支持快速擴容的關鍵就是減小整體的冷啟動時間，冷啟動時間長意味着我們需要更多的時間來得到足夠的實例，我們的服務就會有風險。
我們看一下冷啟動優化治理，整體流程包括容器啟動、鏡像下載、業務代碼下載、啟動容器、業務函數運行，以及代碼加載這麼多過程。其中容器啟動里包含了美團的一些定製化的流程。我們做了一些相應的優化，第一個方式是消除實例初始化的時間，主要的策略是提供資源池的方案，提前啟動好一批常用配置的機器，當業務需要的時候從資源池當中調度和分配給相應的業務即可。第二個優化方式是減小業務代碼體積來降低業務代碼的下載和加載時間。
下面我們來看一下如何降低機器費用。Serverless 架構下彈性的特點可以幫助我們把傳統模式下機器浪費的問題給解決掉，這裡我們要說的是如何進一步降低機器的費用，主要有四種方式：
第一種是提供單實例、多並發的能力
第二種是減小沙箱的配置
第三種是提供實例為 0 的能力
第四種方式是提供合併部署的方式
下面我們來看一下穩定性保障，我們整體的策略是穩定性和建設下沉，使業務專注於解決自身的調整。作為 PaaS 平台的提供方，我們希望為業務承擔更多業務無關的工作。這是我們穩定性保障的全景，整體分為 7 層，下面的三層主要是與故障的識別、風險規避和故障處理相關。上面的四層主要是與軟件的開發和產品的發布流程相關，我們在各個方面都做了一些建設，這裡我們主要看一下在高可用架構、可觀測性，以及灰度發布部分的工作。
首先在高可用架構上，我們提供了部署架構、彈性伸縮、容災降級等方面的保障。在部署架構這裡，我們為不同的業務線提供了一些獨立的集群來運行相關業務，這樣可以做到業務線的隔離。在業務的獨立集群內我們做了多機房的部署，做到了按地域隔離。在彈性伸縮這裡我們支持定時伸縮、預留實例，以及提前擴容，提前擴容是指當流量達到擴容條件的時候，提前準備實例來承接流量。在平台降級這一塊，我們在事件網關這一層提供了業務層的降級能力，配合着我們對業務提供的限流和熔斷這些能力，整體保障業務服務的可用性。
下面我們來看一下可觀測性，可觀測性主要是指發現問題和定位問題的能力。發現問題方面，我們希望提供 Serverless 架構下的服務交換能力，幫助業務更好地觀測雲函數的運行狀態，在定位問題方面，我們提供了服務日誌與性能診斷等平台，來幫助業務去排查業務問題，還有代碼的性能問題，在服務監控方面，基於公司統一的無監控平台，定製了 Serverless 架構下的系統監控、應用監控還有健康監控。系統監控提供的是實例緯度的 CPU、磁盤這些監控數據，應用監控提供的是應用粒度的訪問量、QPS 等監控的數據，進程的監控提供的是代碼實際運行進程內的 CPU 和內存相關的數據。進程監控可以幫助開發者更清晰地看到函數實際運行進程內的情況。
在 Serverless 架構下，函數平台內部的事件網關還有函數運行時成為請求鏈路當中的關鍵節點，我們也提供了一些平台內部的日誌，幫助業務去排查問題。同時結合業務的用戶端日誌還有業務函數相關的日誌，我們將所有的日誌全部下沉到日誌系統，為用戶提供統一查詢的能力，以及鏈路拓撲全鏈路日誌等日誌分析的能力，幫助業務在遇到問題時更快速排查問題。
PaaS 平台同時為我們提供了灰度發布的能力，灰度發布的策略主要有流量百分比，還有一些自定義的條件。通過流量百分比還有自定義條件，業務可以實現比如平滑發布、AB 測試等靈活的灰度方式。平滑發布可以幫助我們在日常發布的過程中保障服務整體可用性。
下面來看兩個業務案例，看一看我們為業務實際解決了哪些具體的問題。
首先第一個案例是一個流量波動比較大的服務，這個服務提供的是 SSR 頁面和 API 服務，業務的特點是平時流量比較小，在高峰的時候流量突然增加，QPS 最高和最低差距能達到 30 倍以上，這是一個一體化的漏斗服務，部署在我們傳統的容器當中，需要我們開發者去維護機器。業務面臨的痛點主要有三個：
服務器的成本比較高
運維成本比較高
應急響應不及時
我們為業務提供了一個低成本的遷移方式，主要思路是在平台側提供一個 Web 適配器的能力，來解決傳統架構和 Serverless 架構的差異點，使傳統架構更平滑過渡到 Serverless 架構當中來，後面逐步引導新的需求甚至原有的服務慢慢遷移到標準的 Serverless 架構下。業務經過了一些適配和改造，最終接入到了我們 Serverless 架構，並帶來了一些改變。首先實例是可以自動伸縮的，通過自動擴容、定時擴容，可以應對流量高峰場景；其次是有全面的監控能力，包括系統、流量、性能監控等監控數據會有一站式的解決方案。體現在收益上有以下幾個方面：
服務器成本降低：資源利用率由 10% 提升到 35% 以上；
運維成本降低：一站式監控，遷移後零運維；
應急響應：秒級發布、實例異常自動隔離，系統層面的緊急情況由平台承擔。
我們看一下案例 2，這是一個訪問 SSR 頁面的場景，業務已經由傳統的架構遷移到我們的 Serverless 架構，但仍然面臨着一些問題。它的業務特點是：
頁面粒度部署
日常流量較小
流量有波峰波谷
業務的痛點主要有兩個，首先是因為隔離性比較差，所有的頁面全部部署在一個沙箱之內，之間的穩定性相互影響。第二個痛點是發布回滾耦合在一起，整體的發布時間比較長。業務針對這些痛點做了一些演進，每個頁面部署在一個沙箱之內，同時每個頁面需要一個實例，原來是僅需要一個實例，現在是需要更多的實例來承擔同樣的服務。體現在收益上，因為頁面間做到了沙箱的隔離，在發布效率上有所提升。這時候業務面臨一個新的痛點，就是整體的資源利用率比較低，大約是在 10%。最終針對於業務這種情況，我們為業務提供了合併部署的方式，將業務演進為多頁面每個頁面部署在一個沙箱當中，這些沙箱部署在一個實例之內，將業務原有的發布 / 回滾時長的 10 分鐘級別，降低到了發布只需要五秒，回滾只需要 0 秒，頁面間原來是耦合的，現在依然可以做到沙箱的隔離。
在這個業務場景下，我們沉澱了滿足業務對隔離性相關需求的能力：
函數運行時支持插件能力
業務定製 SSR 運行時
支持多框架擴展
冷啟動時間降低
未來我們首先要提升 Serverless 架構下整體的資源利用率，希望將資源利用率推到 65% 以上，這是一個很有挑戰的目標，涉及到我們在穩定性保障、穩定性能優化，以及各個方面的優化和提升。其次是繼續提升我們的研發效率，在工具建設還有組件集成上做進一步的努力，來幫助業務去做更多的事情，降低業務的開發成本，進而提升業務的研發效率。最後是迎接 Serverless 架構下的運維挑戰，在 Serverless 架構下，當函數體量比較小的時候，對業務來說幾乎是 0 運維的，當我們又把傳統的大應用全部拆分成函數，部署到我們 Serverless 架構下，我們需要運維的函數或者服務會越來越多，未來一定會有一些挑戰，目前我們還在探索 Serverless 架構下函數服務體量的過程中。
12 月 2-3 日，ArchSummit 全球架構師峰會將再次落地北京富力萬麗酒店。來自百度、京東、華為、騰訊、鬥魚、中國信通院等企業與學術界的技術專家，將就數字化業務架構、低代碼實踐、國產化替代方案、分布式架構等主題展開分享討論。
目前已上線數字化場景下的業務架構、低代碼實踐與應用、國產化替代解決方案探索、分布式架構落地實踐、智能化軟件測試、技術 - 產品 - 業務、高並發架構實現、如何成為優秀的架構師、大數據和人工智能融合、大規模微服務架構演進、可觀測技術落地、雲原生大數據實踐等專題，更多專題正在持續上線中... 點擊閱讀原文去官網查看更多內容。
現在購票還可享受 9 折特惠，單人立減 880 元，團隊購票優惠更多。購票或諮詢其他問題請聯繫票務同學：15600537884（微信同電話）
留言列表