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
總結
以上是生活随笔為你收集整理的Serverless 如何在阿里巴巴实现规模化落地？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Kubernetes 稳定性保障手册 -
- 下一篇： Kubernetes 稳定性保障手册 -