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

作者 | 王恆飛（承蔭）

本文整理自飛豬旅行前端技術專家 -- 王恆飛（承蔭）在【阿里雲 Serverless Developer Meetup 上海站】上的分享。

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

Serverless 的使用規模

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

具體的數據如下：

爲什麼要引入 Serverless

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

1. 飛豬前端架構的發展

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

2. 研發模式的演進歷程

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

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

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

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

3. 爲什麼一定是 Serverless

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

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

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

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

1. 落地場景總覽

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

2. 雲 + 端場景 - 數據協議處理

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

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

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% 以上。

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

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

Serverless 研發配套建設

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

1. 研發態效率

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

2. 運行時穩定性

通過函數監控 Alinode、網關監控 Sunfire 以及全鏈路日誌的排查能力，做到問題的快速發現和定位。

通過 tair 容災和 cdn 容災，保障大部分場景在函數或者網關掛掉的情況下，仍能夠正常展示頁面。

未來

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

寫在最後

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

作者簡介

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/5H4EmHMmIRoA0DGfssFAyg

猜你喜歡