作者 | 趙慶傑（盧令）
來源 |
Serverless 公衆号一、Serverless 規模化落地集團的成果
2020 年，我們在 Serverless 底層基建上做了非常大的更新，比如計算更新到了第四代神龍架構，存儲上更新到了盤古 2.0，網絡上進入了百 G 洛神網絡，整體更新之後性能提升兩倍；BaaS 層面也進行了很大的拓展，比如支援了 Event Bridge、Serverless Workflow，進一步提升了系統能力。
除此以外，我們還與集團内十幾個 BU 進行了合作共建，幫助業務方落地 Serverless 産品，其中包含 雙11 核心的應用場景，幫助其順利通過 雙11 流量峰值大考，證明了 Serverless 在核心的應用場景下，依然表現得非常穩定。
二、兩大背景，兩大優勢 – 加速 Serverless 落地
1. Serverless 兩大背景
為什麼在集團内部能快速實作規模化地落地 Serverless？首先我們有兩大前提背景：
第一個背景是上雲，集團上雲是重要的前提，隻有上雲才能享受到雲上的彈性紅利，如果還是自己内部的一朵雲，後續的起效降本其實非常難達成，是以 2019 年雙十一阿裡實作了核心系統 100% 上雲，有了上雲前提，Serverless 才有了發揮非常作用的空間。
第二個背景是全面雲原生化，打造了一個強大的雲原生産品的雲家族，對集團内部業務進行賦能，幫助業務達成了在上雲基礎上的兩個主要目标：提高效能和降低成本， 2020 年天貓雙十一核心系統全面雲原生化，效率提升 100%，成本降低 80%。
2. Serverless 兩大優勢
- 提高效能
一個标準的雲原生應用，從研發到上線到運維，需要完成上圖中所有标橙色的工作項，才能完成正式的微服務應用上線，首先是 CI/CD 代碼建構，另外是系統運維的可視化工作項目，不僅要配置、對接，還需對整體資料鍊路進行流量評估、安全評估、流量管理等，這顯然對人力門檻要求已經非常高。除此以外，為了提升資源使用率，我們還需要對各個業務進行混部，門檻會進一步的提高。
可以看出，整體的雲原生傳統應用，要實作微服務上線所需要完成的工作項，對于開發者來說非常艱難，需要由多個角色進行完成，但是如果到 Serverless 時代，開發者隻要完成上圖中标藍色的框 coding，後續剩下的所有工作項，Serverless 的研發平台可以直接幫助業務完成上線。
- 降低成本
提高效能主要指的是人力成本的節省，而降低成本則針對的是應用的資源使用率。普通應用我們需要為峰值預留資源，但波谷就會造成極大浪費。在 Serverless 場景下，我們隻需要按需付費，拒絕為峰值預留資源，這是 Serverless 降低成本的最大優勢。
以上兩大背景和兩大優勢，符合技術上雲的趨勢，是以集團内部的業務方一拍即合，一些大的 BU 已經把 Serverless 落地更新為戰役層面，加速業務落地的 Serverless 場景。目前在集團落地的 Serverless 場景已經非常豐富，涉及到了核心的一些應用、個性化推薦、視訊處理，還有 AI 推理、業務巡檢等等。
三、Serverless 落地場景 – 前端輕應用
目前，集團内前端場景是應用 Serverless 最快、最廣的場景，包含淘系、高德、飛豬、優酷、閑魚等 10+ 以上 BU。那為什麼前端場景适合 Serverless 呢？
上圖是全棧工程師的能力模型圖，一般的微應用中需要有三個角色：前端工程師、後端開發工程師，運維工程師，三者共同完成應用的上線釋出。為了提高效能，最近幾年出現了全棧工程師的角色，作為全棧工程師，他要具備這三個角色的能力，不僅需要前端的應用開發技術，還需要後端系統層面的開發技能，并且要關注底層的核心、系統資源管理等，這對于前端工程師來說門檻顯然非常高。
最近幾年 Node.js 技術興起，能夠替代後端開發工程師角色，前端工程師隻要具備前端開發能力，就可以充當兩個角色，即前端工程師和後端開發工程師，但運維工程師仍然無法被取代。
而 Serverless 平台，解決的就是上圖三角形結構中的底部三層，極大降低了前端工程師轉變為全棧工程師的門檻，這對前端業務開發者來說非常有誘惑力。
另外一個原因是業務特性符合，大部分的前端應用具有流量洪峰的特性，需要業務評估前置，存在評估成本；同時前端場景更新疊代快，快上快下，運維成本高；且缺乏動态擴縮能力，存在資源碎片及資源浪費。而如果使用 Serverless，平台會自動幫你解決以上所有的後顧之憂，是以 Serverless 對前端場景的誘惑力非常大。
1. 前端落地場景
上圖列舉了前端落地的幾個主要場景和技術點：
BFF 轉換成 SFF 層：BFF 主要是 Backend For Frontend，前端工程師做主要運維，但到了 Serverless 時代，運維完全交于 Serverless 平台，前端工程師隻需要寫業務代碼，就可以完成這項工作。
瘦身：把前端的業務邏輯下沉到 SFF 層，由 SFF 層去做邏輯的複用，把運維的能力也交給 Serverless 平台，實作用戶端輕量化，提效功能下沉。
雲端一體化：一處代碼多端應用，這是非常流行的開發架構，同樣需要 SFF 作為支撐。
CSR/SSR：通過 Serverless 滿足服務端渲染、用戶端渲染等，來實作前端首屏的快速展現，Serverless 結合 CDN 整體可以作為前端加速的解決方案。
NoCode：相當于在 Serverless 平台上做了封裝，隻需拖拽幾個元件，就可以搭建一個前端頁面，每個元件都可以用 Serverless 進行包裝、功能聚合等，達到 NoCode 的效果。
中背景場景：主要是單體的富應用場景，單體應用可以完全用 Serverless 模式進行托管，完成中背景應用上線，這同樣也可以節省運維能力、減少成本。
2. 前端 Coding 變化
在前端場景應用 Serverless 之後，coding 有哪些變化呢？
對前端有一定了解的都知道，前端一般分三層：State、View 和 Logic Engine，同時會把一些抽象的業務邏輯下沉到 FaaS 層雲函數上，然後用雲函數作為 FaaS API 來提供服務，在代碼編寫上可以抽象各類 Aaction，每個 Aaction 可以有 FaaS 函數 API 提供服務。
以一個簡單的頁面為例，頁面左側是一些渲染接口，可以擷取商品詳情、收貨位址等，這是基于 Faas API 實作的；右側的是一些互動邏輯，比如購買、添加等，這也是 Faas API 可以繼續完成的任務。
頁面設計中，所有的 Faas API 不是隻能為一個頁面所使用，它可以為多個頁面複用。複用這些 API 或者進行拖拽之後，就可以完成前端頁面的組裝，這對于前端來說是非常友善的。
3. 前端輕應用研發提效：1-5-10
在前端應用 Serverless 之後，我們把 Serverless 對前端的研發效能的提效簡單總結為 1-5-10，其含義是：
1 分鐘的快速開始：我們把各類主要場景做一個總結，将其歸類為應用模闆，每個使用者或者業務方新起一個業務時，隻需要選擇相應的應用啟動模闆，就會幫助使用者快速生成業務代碼，使用者隻需要寫自己的業務函數代碼就可以快速開始。
5 分鐘上線應用：完全複用 Serverless 的運維平台，利用平台天然能力，幫助使用者完成灰階釋出等能力；并且配合前端網關、切流等完成金絲雀測試等功能。
10 分鐘排查問題：基于上線之後的 Serverless 函數，提供業務名額或系統名額的展示，通過名額不僅可以設定報警，還可以在控制台上給使用者推送錯誤日志等，幫助使用者快速定位問題、分析問題，10 分鐘内掌握整個 Serverless 函數的健康狀态。
4. 前端落地 Serverless 效果
前端實作 Serverless 的場景後效果如何？我們将 3 款 APP 在傳統應用研發模式下所需要的性能和工時與應用 Faas 場景之後進行對比，可以明顯看到，在原有的雲原生基礎上，效能還能提升 38.89%，這對于 Serverless 應用或前端應用來說效果非常可觀，目前 Serverless 場景已經幾乎覆寫整個集團内部，幫助業務方實作 Serverless 化，實作提高效能和降低成本兩個主要目标。
四、技術輸出，拓展新場景
在集團的 Serverless 落地過程中，我們發現了很多新的業務訴求，比如存量業務如何快速實作遷移并節省成本？執行時間是否可以調大或者調長？資源配置是否可以調高？等等，針對這些問題我們提出了一些解決方案，基于這些解決方案我們抽象出了産品的一些功能，接下來介紹幾個比較重要的功能：
1. 自定義鏡像
自定義鏡像主要目的是實作存量業務的無縫遷移，幫助使用者實作零代碼改造，并且把業務代碼完全遷移到 Serverless 平台上。
存量業務的遷移是非常大的痛點，在一個團隊内，不可能長期存在兩種研發模式，這會造成極大内耗。想讓業務方遷移到 Serverless 研發體系下，必須推出徹底的改造方案，幫助使用者實作 Serverless 體系改造，不僅需要支援新業務使用 Serverless，還要幫助存量業務實作零成本快速遷移，是以我們推出了自定義容器功能。
傳統 Web 單體應用場景特性：
- 應用現代化細粒度責任拆分、服務治理等運維負擔；
- 曆史包袱不易 Serverless 化：雲上雲下業務代碼，依賴、配置不統一；
- 容量規劃，自建運維、監控體系；
- 資源使用率低 （低流量服務獨占資源）。
函數計算 + 容器鏡像優勢：
- 低成本遷移單體應用；
- 免運維；
- 無需容量規劃，自動伸縮；
- 100% 資源使用率，優化閑置成本。
自定義容器功能，可以讓傳統 Web 單體應用（比如 SpringBoot、Wordpress、Flask、Express、Rails 等架構）不需任何改造，就可以以鏡像的方式遷移到函數計算上，避免低流量業務獨占伺服器造成資源浪費。同時也可以享受到無需為應用做容量規劃、自動伸縮、免運費等效益。
2. 性能執行個體
高性能執行個體，減少使用限制，拓展更多場景。比如：代碼包從原來的 50M 上升到 500M，執行時間從原來的 10 分鐘提高到 2 小時，性能規格比原先提升 4 倍多，能夠最大支援 16G 和 32G 的大規格執行個體，來幫助使用者運作一些非常耗時的長任務等等。
函數計算服務了很多場景，在服務過程中我們收到了很多訴求，比如限制條件多、使用門檻高、計算場景資源不足等問題。是以針對這些場景，我們推出了性能執行個體功能，目标是減少函數計算應用場景的使用限制，降低使用門檻，并且在執行時長上、各種名額上，使用者可以靈活配置、按需配置。
目前我們支援的 16 核 32G 完全具備與同規格 ECS 一模一樣的計算能力，可以适用于高性能的業務場景如 AI 推理、音視訊轉碼等。這個功能對後續拓展應用場景來說非常重要。
挑戰：
- 彈性執行個體限制條件多，有一定使用門檻，如執行時長、執行個體規格等；
- 傳統單體應用、音視訊等重計算場景下，業務需要拆分改造，增加負擔；
- vCPU、記憶體、帶寬等資源次元，彈性執行個體未給出明确承諾。
目标：
- 減小函數計算的使用限制，降低企業使用門檻；
- 相容傳統應用和重計算場景；
- 給使用者明确的資源承諾。
做法：
- 推出更高規格、資源承諾更明确的性能執行個體；
- 未來，性能執行個體将具備更高的穩定性 SLA、更豐富的功能配置。
主打場景：
計算型任務、long-running 任務、彈性伸縮不敏感任務。
- 音視訊轉碼處理；
- AI 推理；
- 其它需求高規格的計算場景。
優勢：
性能執行個體除放寬限制外，仍保留目前函數計算産品所具備的所有能力：按量付費、預留模式、單執行個體多請求、多種事件源內建、多可用區容災、自動伸縮、應用的建構部署及免運維等。
3. 鍊路追蹤
鍊路追蹤功能包括：鍊路還原、拓撲分析、問題定位。
一個正常的微服務，不是一個函數就能完成所有工作，需要依賴上下遊服務。在上下遊業務都是正常的情況下，一般不需要鍊路追蹤，但是如果下遊服務出現了異常，如何定位問題？這時就可以依賴鍊路追蹤功能，迅速分析上下遊的性能瓶頸或者定位問題的發生點等。
函數計算也調研了很多集團内外的開源技術方案，目前已經支援 X-trace 功能，并且相容了開源方案，擁抱開源，提供了相容 OpenTracing 的産品能力。
上圖是鍊路追蹤的 Demo 圖，通過計算 tracing 可以可視化看到後端服務的資料庫通路開銷，避免大量服務間的複雜校驗關系增加問題排查的難度等。函數計算還支援函數代碼級的鍊路分析能力，幫助使用者優化冷啟動、關鍵代碼實作等。
Serverless 産品在業務角度上帶來了巨大收益，但是封裝也帶來了一個階段性難題——黑盒問題。當我們向使用者提供鍊路追蹤技術，同時也把黑盒問題暴露給使用者，使用者也可以通過這些黑盒問題提升自身的業務能力。這也是 Serverless 未來提高使用者體驗的方向，後續我們會在這方面繼續加大投入，降低使用者使用 Serverless 的成本。
- Serverless 産品在業務角度有巨大收益，但封裝帶來黑盒問題；
- Serverless 連接配接雲生态，大量的雲服務造成調用關系複雜；
- Serverless 開發者依然有鍊路還原、拓撲分析、問題定位等需求。
FC + x-trace 主要優勢：
- 函數代碼級鍊路分析，幫助優化冷啟動等關鍵代碼實作；
- 服務調用級鍊路追蹤，幫助串聯雲生态服務，分布式鍊路分析。
4. 異步配置
在 Serverless 場景下，我們提供了離線任務處理、消息對立消費等功能，在函數計算中這類功能的使用率占比 50% 左右。在大量消息消費中，存在很多異步配置問題經常被業務方挑戰，比如，這些消息是從哪裡來？又去到哪裡？被什麼服務消費？消費的時間？消費的成功率如何？等等。這些問題的可視化/可配置，是目前需要主要解決的重要課題。
上圖為異步配置的工作原理，首先從使用者指定的事件源開始觸發異步調用，函數計算立即傳回請求 ID，同時也可以調用執行函數，傳回執行結果到函數計算或者消息隊列 MNS 裡面。然後通過事件源可配置觸發器等等，這些效果或者主題消費，可以進行消息的再次消費。比如，如果一個消息處理失敗了，可以配置一下進行二次處理。
典型的應用場景：
- 一是事件閉環，比如對投遞結果（如收集監控名額、報警配置）進行結果分析；生産事件上客戶不僅可以利用 FC 消費事件，也可以利用 FC 主動生産事件。
- 二是日常的異常處理，比如失敗處理、重試政策等。
- 三是資源回收，使用者可以自定義存貨時間，及時丢棄無用消息，節省資源，這是異步場景非常大的優化。
作者簡介：
趙慶傑（盧令），目前就職于阿裡雲雲原生 Serverless 團隊，專注于 Serverless 、PaaS，分布式系統架構等方向，緻力于打造新一代的 Serverless 技術平台，把平台技術做到更加普惠。曾就職于百度，負責内部最大的 PaaS 平台，承接了 80% 的線上業務，在 PaaS 方向，後端分布式系統架構等領域有豐富的經驗。
本文整理自【Serverless Live 系列直播】1 月 26 日場
直播回看連結：
https://developer.aliyun.com/topic/serverless/practices