Serverless 如何在阿里巴巴實現規模化落地？

做者 | 趙慶傑（盧令）
來源 | Serverless 公衆號

1、Serverless 規模化落地集團的成果

2020 年，咱們在 Serverless 底層基建上作了很是大的升級，好比計算升級到了第四代神龍架構，存儲上升級到了盤古 2.0，網絡上進入了百 G 洛神網絡，總體升級以後性能提高兩倍；BaaS 層面也進行了很大的拓展，好比支持了 Event Bridge、Serverless Workflow，進一步提高了系統能力。

除此之外，咱們還與集團內十幾個 BU 進行了合做共建，幫助業務方落地 Serverless 產品，其中包含 雙11 核心的應用場景，幫助其順利經過 雙11 流量峯值大考，證實了 Serverless 在覈心的應用場景下，依然表現得很是穩定。

2、兩大背景，兩大優點 – 加速 Serverless 落地

1. Serverless 兩大背景

爲何在集團內部能快速實現規模化地落地 Serverless？首先咱們有兩大前提背景：

第一個背景是上雲，集團上雲是重要的前提，只有上雲才能享受到雲上的彈性紅利，若是仍是本身內部的一朵雲，後續的起效降本其實很是難達成，因此 2019 年雙十一阿里實現了核心系統 100% 上雲，有了上雲前提，Serverless 纔有了發揮很是做用的空間。

第二個背景是全面雲原生化，打造了一個強大的雲原生產品的雲家族，對集團內部業務進行賦能，幫助業務達成了在上雲基礎上的兩個主要目標：提升效能和下降成本， 2020 年天貓雙十一核心系統全面雲原生化，效率提高 100%，成本下降 80%。
 

2. Serverless 兩大優點

• 提升效能

一個標準的雲原生應用，從研發到上線到運維，須要完成上圖中全部標橙色的工做項，才能完成正式的微服務應用上線，首先是 CI/CD 代碼構建，另外是系統運維的可視化工做項目，不只要配置、對接，還需對總體數據鏈路進行流量評估、安全評估、流量管理等，這顯然對人力門檻要求已經很是高。除此之外，爲了提高資源利用率，咱們還須要對各個業務進行混部，門檻會進一步的提升。

能夠看出，總體的雲原生傳統應用，要實現微服務上線所須要完成的工做項，對於開發者來講很是艱難，須要由多個角色進行完成，可是若是到 Serverless 時代，開發者只要完成上圖中標藍色的框 coding，後續剩下的全部工做項，Serverless 的研發平臺能夠直接幫助業務完成上線。
 

• 下降成本

提升效能主要指的是人力成本的節省，而下降成本則針對的是應用的資源利用率。普通應用咱們須要爲峯值預留資源，但波谷就會形成極大浪費。在 Serverless 場景下，咱們只須要按需付費，拒絕爲峯值預留資源，這是 Serverless 下降成本的最大優點。

以上兩大背景和兩大優點，符合技術上雲的趨勢，因此集團內部的業務方一拍即合，一些大的 BU 已經把 Serverless 落地升級爲戰役層面，加速業務落地的 Serverless 場景。目前在集團落地的 Serverless 場景已經很是豐富，涉及到了核心的一些應用、個性化推薦、視頻處理，還有 AI 推理、業務巡檢等等。
 

3、Serverless 落地場景 – 前端輕應用

目前，集團內前端場景是應用 Serverless 最快、最廣的場景，包含淘系、高德、飛豬、優酷、閒魚等 10+ 以上 BU。那爲何前端場景適合 Serverless 呢？

上圖是全棧工程師的能力模型圖，通常的微應用中須要有三個角色：前端工程師、後端開發工程師，運維工程師，三者共同完成應用的上線發佈。爲了提升效能，最近幾年出現了全棧工程師的角色，做爲全棧工程師，他要具有這三個角色的能力，不只須要前端的應用開發技術，還須要後端系統層面的開發技能，而且要關注底層的內核、系統資源管理等，這對於前端工程師來講門檻顯然很是高。

最近幾年 Node.js 技術興起，可以替代後端開發工程師角色，前端工程師只要具有前端開發能力，就能夠充當兩個角色，即前端工程師和後端開發工程師，但運維工程師仍然沒法被取代。

而 Serverless 平臺，解決的就是上圖三角形結構中的底部三層，極大下降了前端工程師轉變爲全棧工程師的門檻，這對前端業務開發者來講很是有誘惑力。

另一個緣由是業務特性符合，大部分的前端應用具備流量洪峯的特性，須要業務評估前置，存在評估成本；同時前端場景更新迭代快，快上快下，運維成本高；且缺少動態擴縮能力，存在資源碎片及資源浪費。而若是使用 Serverless，平臺會自動幫你解決以上全部的後顧之憂，因此 Serverless 對前端場景的誘惑力很是大。

1. 前端落地場景

上圖列舉了前端落地的幾個主要場景和技術點：

BFF 轉換成 SFF 層：BFF 主要是 Backend For Frontend，前端工程師作主要運維，但到了 Serverless 時代，運維徹底交於 Serverless 平臺，前端工程師只須要寫業務代碼，就能夠完成這項工做。

瘦身：把前端的業務邏輯下沉到 SFF 層，由 SFF 層去作邏輯的複用，把運維的能力也交給 Serverless 平臺，實現客戶端輕量化，提效功能下沉。

雲端一體化：一處代碼多端應用，這是很是流行的開發框架，一樣須要 SFF 做爲支撐。

CSR/***：經過 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 化，實現提升效能和下降成本兩個主要目標。

4、技術輸出，拓展新場景

在集團的 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