![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/4fa554e066ea4b46bc33c93e516a7f00.png)

作者 | 王恆飛（承蔭）
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/5H4EmHMmIRoA0DGfssFAyg)

本文整理自飛豬旅行前端技術專家--王恆飛（承蔭）在【阿里雲 Serverless Developer Meetup 上海站】上的分享。點選檢視直播回放：[https://developer.aliyun.com/live/246653](https://developer.aliyun.com/live/246653)。

過去兩年，飛豬前端一直在積極地進行 Serverless 建設和實踐，2019 年 - 2020 年我們和集團 Node 架構組、研發平臺一起完成了基礎能力的建設和業務試點，成為集團率先落地 Serverless 實踐的 BU，2020 年 - 2021 年我們開始大規模地在飛豬推廣使用 Serverless 的能力，從導購全鏈路到核心中後臺，都能夠看到 Serverless 的身影，這一年我們完成了 Serverless 從業務試點到生產力工具的轉變，本文將主要分享飛豬基於 Serverless 的實踐成果以及未來想要做的事情。

# Serverless 的使用規模

2020 年 - 2021 年飛豬 Serverless 的規模和重要度都有很大的變化，主要表現在三方面：

- 一是函式組規模增長一倍以上，Qps 峰值增長 650%。
- 二是使用 FaaS 開發的人員規模增長 560%，其中前端人員 80% 以上參與到 FaaS 的開發中。
- 三是影響力的表現，目前不僅飛豬前端都對 Serverless 很熟悉，客戶端也有很多人參與到 FaaS 的開發，更重要的是後端和產品同學也知道我們有 Serverless 進行服務開發的能力。

具體的資料如下：

![1.png](https://ucc.alicdn.com/pic/developer-ecology/db139c269534470e890a8c2c22d29929.png)

# 為什麼要引入 Serverless

飛豬為什麼這麼迫切地要引入 Serverless？這主要是出於前後端研發模式升級以及前端職能擴充套件的考慮，下面回顧一下飛豬前端架構的發展和研發模式的演進。

## 1. 飛豬前端架構的發展

飛豬前端架構總結下來就是從最初純粹的前端開發，到解決多端一致性的跨端開發，再到接管檢視服務端邏輯的前臺開發，Serverless 就是前端升級轉變的核心一環。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/19391a0458474be8a4da5b62275b7d77.png)

## 2. 研發模式的演進歷程

前端人員為什麼一定要參與服務側開發？從前後端研發模式的演進來看，主要經歷了以下三個大的階段：

第一階段是**資源解耦**，這個階段前端把靜態資源分離出來部署到 cdn，解決了和後端服務同機部署的耦合。

第二階段是**模板解耦**，我們之前提到的前後端解耦大部分指的就是模板的解耦，一種不徹底的解法就是渲染解耦，服務端放一個空模板內容部分全靠 CSR，徹底的解法就是前端接管模板，可以獨立部署模板也可以使用 node.js 替代。

第三個階段就是**試圖解耦**，一方面是由於客戶端體系和前端的離線體系的限制，端側對於檢視的動態性要求極高，沒有服務側能力的前端只能將檢視的動態性放在服務端做，另一方面由於端側架構對於資料介面協議的特殊要求，需要服務端來進行協議的轉換，也就是服務端常說的 Do 到 Vo 的處理，這就造成了前後端檢視的耦合，為了去除這部分耦合，前端透過 Node.js 做 BFF 層來接管檢視層的邏輯，Serverless 則是給了前端做 BFF 開發的最佳選擇。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/8ed5accec6634872954e0336b8164a3c.png)

## 3. 為什麼一定是 Serverless

其實在 Serverless 出現之前，前端也嘗試了用 node 應用來做 BFF 層的開發，飛豬也是在 2017 年透過 Midway + React SSR 的架構將飛豬 PC 主鏈路首頁、搜尋、商品詳情、訂單詳情 Node 化，但是應用級別的開發在前端存在以下幾個問題：

- **開發成本高**：Node 應用級別的開發對於新手前端還是具備一定的開發成本，之前做過粗略的估計，上手成本至少需要 3 人/日，還不包括後續的效能最佳化、記憶體洩漏排查等一系列能力。

- **運維成本高**：Docker、映象、機器日誌檢視、域名申請、機器替換等一系列運維能力對於前端來說具備非常高的複雜度，也是註定無法推廣的一個重要原因。

- **機器成本高**：前端在使用應用開發時過度偏向於前端架構設計帶來的應用離散和機器利用率低的問題，根本原因是前端在用頁面開發的思維去做應用開發，導致新建一堆應用佔用大量閒置機器。

2017 - 2019 年也是集團 Node 開發停滯的兩年，這個階段由於上述問題的閒置，Node 開發無法在移動端鋪開，前端使用  Node 主要在中後臺的開發，這時矛盾主要表現在前端迫切渴望研發模式轉變和涉足服務端開發的高昂成本，直到 Serverless 浪潮的出現讓我們看到了曙光，下面來看下 Serverless 能給前端帶來什麼樣的變化：

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

Node FaaS 透過將中介軟體整合到 Runtime 的上下文中，開發透過 Api 的方式呼叫來實現極低上手和開發成本，只要會寫 js 就能在 0.5 人/日內上手 FaaS 開發，同時 Serverless 容器底層透過機器統一管理、映象統一、靈活排程、按需付費等方式向開發者遮蔽容器的運維，兩者結合完美地幫我們解決了之前 Node 應用開發遇到的三大問題，至此前後端研發模式升級的最後一塊拼圖集齊，前端開始雲+端的變革。

# 飛豬雲+端的核心落地場景

## 1. 落地場景總覽

從飛豬首頁到搜尋、頻道，再到大促會場，Serverless FaaS 實現了在飛豬導購全鏈路的覆蓋，成為飛豬前端的常用生產力工具之一。另外中後臺開發已全面使用 FaaS 開發，並且賦能客戶端同學，下圖右側的包體積平臺就是飛豬客戶端同學使用 Node FaaS 開發完成。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/8fe38b432c7c4ab9bd52198ce63c578e.png)

## 2. 雲+端場景 - 資料協議處理

資料協議處理是 BFF 層最為常見的場景，包括介面合併、Do 到 Vo 的轉換等，飛豬 80% 以上的 C 端 FaaS 場景都是用作資料協議的處理，透過 FaaS 來做協議轉換能夠解放服務端，同時增強前端對檢視層的控制，可謂一舉兩得。

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

一個最新的例子（如下圖所示），這是一個飛豬的內容詳情頁，頁面涉及內容中臺、評價中臺、互動、演算法等 5 個以上介面，這些介面都是現成的分散在各個系統，對於前端來說肯定是不想在端上調 5 次介面，不管是從效能還是架構設計上考慮，都是不合理的，這時就需要一個服務端介面的合併，FaaS 就非常適合做這樣的事情，透過原子能力的拼裝，無需服務端介入，極大縮短了需求的交付週期。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/9b4be41badf04caaaf9a30d1589c562c.png)

## 3. 雲+端場景 - SSR 同構渲染

SSR 同構渲染並不是一個新的概念，最早在 React 支援 SSR 的時候，前端就具備一套程式碼在 Server 和 Client 端執行的能力，飛豬這邊早在 2017 年就在 pc 端上線了 Midway + React SSR 的頁面。

移動端由於流量比 PC 大很多，且在 Server 側執行 Js 是一個極耗機器資源的操作，透過 Node 應用的方式做 SSR 機器和運維成本跟隨著頁面流量指數級上升，ROI 並不高，但是 Serverless FaaS 的自動託管，能幫前端解決機器利用率和運維成本的問題。

再配合客戶端的文件預載入，我們可以做到客戶端預載入直出率（500ms下）100%，端外渲染 2s 達標率 90+%，效能提升 80% 以上。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/79b51d18c4d64f3d806945aae58740b8.png)

## 4. 雲+端場景 - 一體化應用

一體化研發是一種更加符合前端人員習慣的開發模式，常見的分為中後臺一體化和 Rax+FaaS 一體化，將 FaaS 程式碼和 Assets 程式碼在一個倉庫下開發，除錯和部署能夠極大地提高開發效率，目前飛豬用得最多的就是中後臺一體化開發。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/224d4c1959564effbacd562751d0c814.png)

# Serverless 研發配套建設

在基礎建設方面定義為兩部分：**研發態效率的提升**和**執行時穩定性的保障**。

## 1. 研發態效率

開發階段主要涉及的操作是新建專案、除錯和釋出，飛豬透過已有的 Clam 工程體系整合 FaaS 的腳手架模板，對接 def api 打通建立專案、迭代和釋出的能力，讓前端同學開發 FaaS 能有和開發頁面一樣的體驗，降低上手和開發成本，同時封裝 Mtop 呼叫和容災 SDK，封裝常用 FaaS Utils 集合的方式提高程式碼的複用度。

## 2. 執行時穩定性

透過函式監控 Alinode、閘道器監控 Sunfire 以及全鏈路日誌的排查能力，做到問題的快速發現和定位。

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

透過 tair 容災和 cdn 容災，保障大部分場景在函式或者閘道器掛掉的情況下，仍能夠正常展示頁面。

# 未來

2020 年 - 2021 年我們完成了 Serverless 向生產力工具的轉變，2021 年 - 2022 年總體來看是徹底完成飛豬研發模式轉變的目標，讓 FaaS 成為前後端都習以為常的一環，規劃還沒做具體，有以下幾個關鍵的事情要做：

- **中後臺和長尾函式 0 - 1 的彈起嘗試**：這塊考慮到一些中後臺函式和長尾函式每天可能只有幾十個 Uv 夠不到 Qps 級別，目前預留 1 核機器的方式仍是有些浪費，考慮在不影響初次請求的情況下嘗試 0 到 1 的彈起，做到機器的極致利用率。

- **飛豬物理閘道器的替換**：目前雖然飛豬 Java 的閘道器出於維護狀態投入較低，但是一旦流量發生變化，閘道器的穩定性會成為瓶頸，希望能夠有 Fc 專門的團隊接管流量閘道器，之前飛豬也是完成了一個線上試點，2021 年 - 2022 年繼續推進。

- **研發態和執行時問題的可觀測增強**：從 FC 底層容器到函式程式碼內部再到函式依賴、流量閘道器，不管是部署出現的問題還是線上的問題，都比較難定位，通常需要拉著 FC、研發平臺、Runtime 的同學一塊排查，後續希望能推動可觀測性的增強，讓業務開發能夠快速發現問題。

# 寫在最後

基於 Serverless 的雲+端結合已經基本成型，這將是前端近些年來最大的變革之一，未來 FaaS 將是前端開發不可或缺的一環，我們需要用它來做研發模式升級，也需要用它幫助前端擴大職能，透過 FaaS 的能力讓前端開發深入到服務層，更好地貼近業務、理解業務、幫助業務。

## 作者簡介

**王恆飛（承蔭）**，飛豬旅行前端技術專家，飛豬 Serverless 引進和實踐者，探索和推動雲+端的研發模式。

飛豬基於 Serverless 的雲+端實踐與思考

相關文章