簡介： 2020 年，我們在 Serverless 底層基建上做了非常大的升級，比如計算升級到了第四代神龍架構，存儲上升級到了盤古 2.0，網絡上進入了百 G 洛神網絡，整體升級之後性能提升兩倍；BaaS 層面也進行了很大的拓展，比如支持了 Event Bridge、Serverless Workflow，進一步提升了系統能力。

一、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%。

1. 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 方向，後端分佈式系統架構等領域有豐富的經驗。
原文鏈接
本文為阿里雲原創內容，未經允許不得轉載