![頭圖.jpg](https://ucc.alicdn.com/pic/developer-ecology/e8d89c506e9e4421b81212dc28159e32.jpg)

作者 | 趙慶傑（盧令）

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

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

除此以外，我們還與集團內十幾個 BU 進行了合作共建，幫助業務方落地 Serverless 產品，其中包含 雙11 核心的應用場景，幫助其順利透過 雙11 流量峰值大考，證明了 Serverless 在核心的應用場景下，依然表現得非常穩定。

![1.jpg](https://ucc.alicdn.com/pic/developer-ecology/936903aed23b4ea689dba63c0cca45b3.jpg)

# 二、兩大背景，兩大優勢 – 加速 Serverless 落地

## 1. Serverless 兩大背景

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

第一個背景是**上雲**，集團上雲是重要的前提，只有上雲才能享受到雲上的彈性紅利，如果還是自己內部的一朵雲，後續的起效降本其實非常難達成，所以 2019 年雙十一阿里實現了核心系統 100% 上雲，有了上雲前提，Serverless 才有了發揮非常作用的空間。

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

- **提高效能**

![2.jpg](https://ucc.alicdn.com/pic/developer-ecology/19f66ba2541d496fa44784ff24d0c792.jpg)

一個標準的雲原生應用，從研發到上線到運維，需要完成上圖中所有標橙色的工作項，才能完成正式的微服務應用上線，首先是 CI/CD 程式碼構建，另外是系統運維的視覺化工作專案，不僅要配置、對接，還需對整體資料鏈路進行流量評估、安全評估、流量管理等，這顯然對人力門檻要求已經非常高。除此以外，為了提升資源利用率，我們還需要對各個業務進行混部，門檻會進一步的提高。

可以看出，整體的雲原生傳統應用，要實現微服務上線所需要完成的工作項，對於開發者來說非常艱難，需要由多個角色進行完成，但是如果到 Serverless 時代，開發者只要完成上圖中標藍色的框 coding，後續剩下的所有工作項，Serverless 的研發平臺可以直接幫助業務完成上線。
 
- **降低成本**

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

![3.jpg](https://ucc.alicdn.com/pic/developer-ecology/d177ffe14e0e48edbcccde0049d6c8af.jpg)

以上兩大背景和兩大優勢，符合技術上雲的趨勢，所以集團內部的業務方一拍即合，一些大的 BU 已經把 Serverless 落地升級為戰役層面，加速業務落地的 Serverless 場景。目前在集團落地的 Serverless 場景已經非常豐富，涉及到了核心的一些應用、個性化推薦、影片處理，還有 AI 推理、業務巡檢等等。
 
# 三、Serverless 落地場景 – 前端輕應用

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

![4.jpg](https://ucc.alicdn.com/pic/developer-ecology/c1736edb995a49a49ef5a07cc666c13f.jpg)

上圖是全棧工程師的能力模型圖，一般的微應用中需要有三個角色：前端工程師、後端開發工程師，運維工程師，三者共同完成應用的上線釋出。為了提高效能，最近幾年出現了全棧工程師的角色，作為全棧工程師，他要具備這三個角色的能力，不僅需要前端的應用開發技術，還需要後端系統層面的開發技能，並且要關注底層的核心、系統資源管理等，這對於前端工程師來說門檻顯然非常高。

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

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

![5.jpg](https://ucc.alicdn.com/pic/developer-ecology/3fb7e42dfc844462b5f09e4aa155ecd5.jpg)

另外一個原因是業務特性符合，大部分的前端應用具有流量洪峰的特性，需要業務評估前置，存在評估成本；同時前端場景更新迭代快，快上快下，運維成本高；且缺乏動態擴縮能力，存在資源碎片及資源浪費。而如果使用 Serverless，平臺會自動幫你解決以上所有的後顧之憂，所以 Serverless 對前端場景的誘惑力非常大。

## 1. 前端落地場景

![6.png](https://ucc.alicdn.com/pic/developer-ecology/3941db4896934bc9b37af803c524fe9c.png)

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

**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 有哪些變化呢？

![7.jpg](https://ucc.alicdn.com/pic/developer-ecology/0face9f2cf224c50997adc2791948d7a.jpg)

對前端有一定了解的都知道，前端一般分三層：State、View 和 Logic Engine，同時會把一些抽象的業務邏輯下沉到 FaaS 層雲函式上，然後用雲函式作為 FaaS API 來提供服務，在程式碼編寫上可以抽象各類 Aaction，每個 Aaction 可以有 FaaS 函式 API 提供服務。

![8.jpg](https://ucc.alicdn.com/pic/developer-ecology/de56d59c033446dcb4e4996a136b7313.jpg)

以一個簡單的頁面為例，頁面左側是一些渲染介面，可以獲取商品詳情、收貨地址等，這是基於 Faas API 實現的；右側的是一些互動邏輯，比如購買、新增等，這也是 Faas API 可以繼續完成的任務。

頁面設計中，所有的 Faas API 不是隻能為一個頁面所使用，它可以為多個頁面複用。複用這些 API 或者進行拖拽之後，就可以完成前端頁面的組裝，這對於前端來說是非常方便的。

## 3. 前端輕應用研發提效：1-5-10

![9.jpg](https://ucc.alicdn.com/pic/developer-ecology/49a1a182a38a46fa9534918604cd7d16.jpg)

在前端應用 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. 自定義映象

![10.jpg](https://ucc.alicdn.com/pic/developer-ecology/d5e82dea197242c1ae40f97f11494f33.jpg)

自定義映象主要目的是實現存量業務的無縫遷移，幫助使用者實現零程式碼改造，並且把業務程式碼完全遷移到 Serverless 平臺上。

存量業務的遷移是非常大的痛點，在一個團隊內，不可能長期存在兩種研發模式，這會造成極大內耗。想讓業務方遷移到 Serverless 研發體系下，必須推出徹底的改造方案，幫助使用者實現 Serverless 體系改造，不僅需要支援新業務使用 Serverless，還要幫助存量業務實現零成本快速遷移，所以我們推出了自定義容器功能。

![11.jpg](https://ucc.alicdn.com/pic/developer-ecology/2f811ebe531f4ce988173621e2cffb5d.jpg)

**傳統 Web 單體應用場景特性**：

- 應用現代化細粒度責任拆分、服務治理等運維負擔；
- 歷史包袱不易 Serverless 化：雲上雲下業務程式碼，依賴、配置不統一；
- 容量規劃，自建運維、監控體系；
- 資源利用率低 （低流量服務獨佔資源）。

**函式計算 + 容器映象優勢**：

- 低成本遷移單體應用；
- 免運維；
- 無需容量規劃，自動伸縮；
- 100% 資源利用率，最佳化閒置成本。

自定義容器功能，可以讓傳統 Web 單體應用（比如 SpringBoot、Wordpress、Flask、Express、Rails 等框架）不需任何改造，就可以以映象的方式遷移到函式計算上，避免低流量業務獨佔伺服器造成資源浪費。同時也可以享受到無需為應用做容量規劃、自動伸縮、免運費等效益。

## 2. 效能例項

![12.jpg](https://ucc.alicdn.com/pic/developer-ecology/abb52262b0e041249a06cfa68a0ecbf5.jpg)

高效能例項，減少使用限制，擴充更多場景。比如：程式碼包從原來的 50M 上升到 500M，執行時間從原來的 10 分鐘提高到 2 小時，效能規格比原先提升 4 倍多，能夠最大支援 16G 和 32G 的大規格例項，來幫助使用者執行一些非常耗時的長任務等等。

![13.jpg](https://ucc.alicdn.com/pic/developer-ecology/4d63777afe364c569c111a7bc7404c07.jpg)

函式計算服務了很多場景，在服務過程中我們收到了很多訴求，比如約束條件多、使用門檻高、計算場景資源不足等問題。所以針對這些場景，我們推出了效能例項功能，目標是減少函式計算應用場景的使用限制，降低使用門檻，並且在執行時長上、各種指標上，使用者可以靈活配置、按需配置。

目前我們支援的 16 核 32G 完全具備與同規格 ECS 一模一樣的計算能力，可以適用於高效能的業務場景如 AI 推理、音影片轉碼等。這個功能對後續擴充應用場景來說非常重要。

**挑戰**：

- 彈性例項約束條件多，有一定使用門檻，如執行時長、例項規格等；
- 傳統單體應用、音影片等重計算場景下，業務需要拆分改造，增加負擔；
- vCPU、記憶體、頻寬等資源維度，彈性例項未給出明確承諾。

**目標**：

- 減小函式計算的使用限制，降低企業使用門檻；
- 相容傳統應用和重計算場景；
- 給使用者明確的資源承諾。

**做法**：

- 推出更高規格、資源承諾更明確的效能例項；
- 未來，效能例項將具備更高的穩定性 SLA、更豐富的功能配置。

**主打場景**：
計算型任務、long-running 任務、彈性伸縮不敏感任務。

- 音影片轉碼處理；
- AI 推理；
- 其它需求高規格的計算場景。

**優勢**：

效能例項除放寬限制外，仍保留當前函式計算產品所具備的所有能力：按量付費、預留模式、單例項多請求、多種事件源整合、多可用區容災、自動伸縮、應用的構建部署及免運維等。
 
## 3. 鏈路追蹤

![14.jpg](https://ucc.alicdn.com/pic/developer-ecology/df63127dc4b34fdd8f864df5ed6219c8.jpg)

**鏈路追蹤功能包括：鏈路還原、拓撲分析、問題定位。**

一個正常的微服務，不是一個函式就能完成所有工作，需要依賴上下游服務。在上下游業務都是正常的情況下，一般不需要鏈路追蹤，但是如果下游服務出現了異常，如何定位問題？這時就可以依賴鏈路追蹤功能，迅速分析上下游的效能瓶頸或者定位問題的發生點等。

函式計算也調研了很多集團內外的開源技術方案，目前已經支援 X-trace 功能，並且相容了開源方案，擁抱開源，提供了相容 OpenTracing 的產品能力。

![15.jpg](https://ucc.alicdn.com/pic/developer-ecology/1bd8293019524bfabcace6c88a811e3e.jpg)
![16.jpg](https://ucc.alicdn.com/pic/developer-ecology/db1973822bc14528a0ff9940aea6458f.jpg)

上圖是鏈路追蹤的 Demo 圖，透過計算 tracing 可以視覺化看到後端服務的資料庫訪問開銷，避免大量服務間的複雜校驗關係增加問題排查的難度等。函式計算還支援函式程式碼級的鏈路分析能力，幫助使用者最佳化冷啟動、關鍵程式碼實現等。

Serverless 產品在業務角度上帶來了巨大收益，但是封裝也帶來了一個階段性難題——黑盒問題。當我們向使用者提供鏈路追蹤技術，同時也把黑盒問題暴露給使用者，使用者也可以透過這些黑盒問題提升自身的業務能力。這也是 Serverless 未來提高使用者體驗的方向，後續我們會在這方面繼續加大投入，降低使用者使用 Serverless 的成本。

**挑戰**：

- Serverless 產品在業務角度有巨大收益，但封裝帶來黑盒問題；
- Serverless 連線雲生態，大量的雲服務造成呼叫關係複雜；
- Serverless 開發者依然有鏈路還原、拓撲分析、問題定位等需求。

**FC + x-trace 主要優勢**：

- 函式程式碼級鏈路分析，幫助最佳化冷啟動等關鍵程式碼實現；
- 服務呼叫級鏈路追蹤，幫助串聯雲生態服務，分散式鏈路分析。

## 4. 非同步配置

![17.jpg](https://ucc.alicdn.com/pic/developer-ecology/8cb06da48a7d47d183c97d209f2bbdf5.jpg)

在 Serverless 場景下，我們提供了離線任務處理、訊息對立消費等功能，在函式計算中這類功能的使用率佔比 50% 左右。在大量訊息消費中，存在很多非同步配置問題經常被業務方挑戰，比如，這些訊息是從哪裡來？又去到哪裡？被什麼服務消費？消費的時間？消費的成功率如何？等等。這些問題的視覺化/可配置，是目前需要主要解決的重要課題。

![18.jpg](https://ucc.alicdn.com/pic/developer-ecology/6c40aabb33f14d36bdd831d592322c56.jpg)

上圖為非同步配置的工作原理，首先從使用者指定的事件源開始觸發非同步呼叫，函式計算立即返回請求 ID，同時也可以呼叫執行函式，返回執行結果到函式計算或者訊息佇列 MNS 裡面。然後透過事件源可配置觸發器等等，這些效果或者主題消費，可以進行訊息的再次消費。比如，如果一個訊息處理失敗了，可以配置一下進行二次處理。

![19.jpg](https://ucc.alicdn.com/pic/developer-ecology/cfe7559a2cc94e848935eeb5b5a6ed6c.jpg)

**典型的應用場景**：

- 一是**事件閉環**，比如對投遞結果（如收集監控指標、報警配置）進行結果分析；生產事件上客戶不僅可以利用 FC 消費事件，也可以利用 FC 主動生產事件。
- 二是**日常的異常處理**，比如失敗處理、重試策略等。
- 三是**資源回收**，使用者可以自定義存貨時間，及時丟棄無用訊息，節省資源，這是非同步場景非常大的最佳化。

**作者簡介**：
趙慶傑（盧令），目前就職於阿里云云原生 Serverless 團隊，專注於 Serverless 、PaaS，分散式系統架構等方向，致力於打造新一代的 Serverless 技術平臺，把平臺技術做到更加普惠。曾就職於百度，負責內部最大的 PaaS 平臺，承接了 80% 的線上業務，在 PaaS 方向，後端分散式系統架構等領域有豐富的經驗。

> 本文整理自【Serverless Live 系列直播】1 月 26 日場
> 直播回看連結：[https://developer.aliyun.com/topic/serverless/practices](https://developer.aliyun.com/topic/serverless/practices)

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

相關文章