飛豬基于 Serverless 的云+端實踐與思考
過去兩年，飛豬前端一直在積極地進行 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 進行服務開發的能力。
具體的數據如下：
為什么要引入 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 化，但是應用級別的開發在前端存在以下幾個問題：
- - 開發成本高：Node 應用級別的開發對于新手前端還是具備一定的開發成本，之前做過粗略的估計，上手成本至少需要 3 人/日，還不包括后續的性能優化、內存泄漏排查等一系列能力。
- 運維成本高：Docker、鏡像、機器日志查看、域名申請、機器替換等一系列運維能力對于前端來說具備非常高的復雜度，也是注定無法推廣的一個重要原因。
- 機器成本高：前端在使用應用開發時過度偏向于前端架構設計帶來的應用離散和機器利用率低的問題，根本原因是前端在用頁面開發的思維去做應用開發，導致新建一堆應用占用大量閑置機器。
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 成為前后端都習以為常的一環，規劃還沒做具體，有以下幾個關鍵的事情要做：
- - 中后臺和長尾函數 0 - 1 的彈起嘗試：這塊考慮到一些中后臺函數和長尾函數每天可能只有幾十個 Uv 夠不到 Qps 級別，目前預留 1 核機器的方式仍是有些浪費，考慮在不影響初次請求的情況下嘗試 0 到 1 的彈起，做到機器的極致利用率。
- 飛豬物理網關的替換：目前雖然飛豬 Java 的網關出于維護狀態投入較低，但是一旦流量發生變化，網關的穩定性會成為瓶頸，希望能夠有 Fc 專門的團隊接管流量網關，之前飛豬也是完成了一個線上試點，2021 年 - 2022 年繼續推進。
- 研發態和運行時問題的可觀測增強：從 FC 底層容器到函數代碼內部再到函數依賴、流量網關，不管是部署出現的問題還是線上的問題，都比較難定位，通常需要拉著 FC、研發平臺、Runtime 的同學一塊排查，后續希望能推動可觀測性的增強，讓業務開發能夠快速發現問題。
寫在最后
基于 Serverless 的云+端結合已經基本成型，這將是前端近些年來最大的變革之一，未來 FaaS 將是前端開發不可或缺的一環，我們需要用它來做研發模式升級，也需要用它幫助前端擴大職能，通過 FaaS 的能力讓前端開發深入到服務層，更好地貼近業務、理解業務、幫助業務。
作者簡介
王恒飛(承蔭)，飛豬旅行前端技術專家，飛豬 Serverless 引進和實踐者，探索和推動云+端的研發模式。
