前端工程化之 FaaS SSR 方案

導讀：揭祕百度直播研發部 Web 應用 SSR 技術新玩法，在 CSR 目錄下添加一個 JS 計算函數就可以讓頁面具有 SSR 能力。依託端雲協同驅動打通 SSR 技術關鍵路徑、規模化落地引領高品質 Web 應用的市場價值。讓我們對這個小時級賦能方案一探究竟。

一、背景

從 CSR(client-side rendering) 到 SSG，網頁信息從無到有完整呈現個性化內容滯後於 AJAX 請求，夯實訪問體驗，提升網頁內容體量和平臺品牌等級，滿足消費者對更高質量體驗的需求。同時內容服務型站點 SEO 推廣也是關鍵要素，內容運營助於業務獲得突破性增長。迴歸到提升服務競爭力的核心上，SSR(server-side rendering) 技術獨具潛力和創新機遇，各種” 不走尋常路” 的方案也比較活躍，共同目標都是使互聯網 Web 應用優質化。

另一方面，SSR 也是 Web 服務發展脈絡迎來質變的分界點，賦能成本下降除了 SSR 技術本身的改進，更依賴於大規模的落地，通過體系工程的改變，讓開發者升級便捷，讓服務更親近用戶。

二、訴求即目標

同構的 SSR： 頂層設計上已不接受基於模板的 SSR 技術，因爲異構的 TPL 和 JS 增加了頁面組件的維護切換成本，基於業務與團隊現狀，我們需要快速迭代，一套代碼 100% 複用，同時 JS 一體化同構的 SSR 能把組件代碼侵入降到最低。
極速接入： 頁面開發者希望集成在 CSR 工程下，幾乎爲零的模塊、項目和頁面目錄改動。一方面因爲 CSR 是業務承載大頭，另一方面是前端分散的多個模塊現狀，遷入一個集中式的龐大工程內再拆成可控的小塊，加上依賴關係管理，改造成本極大，爲了接入 SSR 要重構甚至重寫是削弱工程化 ROI 的。
開發體驗： 頁面開發者更專注於組件代碼本身，CSR 的開發部署方式，修改代碼打包發佈即可。希望 BFF 服務編排和雲端基礎設施一切都以 NoOps 有條不紊的運行。數據接口和字段複用更是基本訴求。
效果保障： 使用服務端 HTML 結果渲染首屏，適當的利用緩存策略，加速受訪縮短 FMP 時間，提升網頁服務品質。SEO 友好，利於內容密集型網頁獲得搜索的曝光。

三、FaaS SSR 普世

面對以上挑戰，用第一性原理來思考，迴歸到同構 SSR 技術的本質” 是指在服務側完成網頁的 HTML 結構拼接並返回該富內容的文件，在瀏覽器側再完成水合爲其綁定狀態與事件，成爲完全可交互頁面的過程。” 無論各個版本如何描述這個過程，在服務側生成 Contentful HTML 分解成最基本的組成就是：組件和數據。源頭上：組件是已有的，修改構建配置即可導出被引入；數據即 CSR 過程通過 AJAX 調用的後端接口響應數據，事實上也是明確的，只是需要在服務端進行 Server 到 Server 的調用，相對於 CSR，SSR 需要數據提前到組件首次執行時傳入。

建構在第一性原理上，我們可以抽離出基於 PaaS 構建一致的 FaaS SSR 集結環境，具有服務預熱、快速訪問、彈性伸縮、容器隔離、低運維成本等優點，關鍵優勢在於補齊了 Web 應用的雲開發輔助能力，在前端架構層面高效配合使 Web 應用支持原生的雲端聯合渲染，創造一種通用的同構方案。SSR 核心庫更小更內聚可維護性更高，松耦合自治的模塊可擴展性更好，並不會將各模塊頁面限定於特定的技術棧，釋放組織潛力。因爲 FaaS SSR 環境除了基本的 DevOps 外，只調度組件和數據，而保障組件在 Node 服務器上運行的方法是由組件本身導入的所使用框架的原生 API。

Page Resources： SSR 過程所需的必要元素
Template：頁面模板，即 CSR 頁面的 HTML，同時是 SSR 頁面的模板。
Bundle：組件打包的 bundle，這份供 Node.js Server 端進行 SSR 的 bundle 產物，需要 webpack 單獨打包產出。
FC：控制 SSR 過程的計算函數，實現 SSR 核心的鉤子，在 Function Sandbox 中運行，可以自定義 SSR 結果。
Data：填充組件的 BaaS 數據，通過調用 Backend Service 獲取。
Routing： 路由頁面請求及調度資源
manifest.json：模塊構建產出的資源清單。每個方向模塊自動產出一份，聲明上述 Page Resources 的資源等信息。
module：模塊的信息，manifest.json 路徑、模塊查詢路徑等信息。
router：解析當前 Request 信息的 Lambda 函數，匹配到當前頁面的 Template、Bundle、FC 信息，並向 FC 派發 HTTP 事件。
BaaS： 後端即服務，包括接口、存儲、通信等 Backend Service。通過 Spec 描述即可交給 FaaS RPC 調用目標服務。
Rendering： 通過系列 Lambda 函數管道調用，注入整個過程的環境變量，包括獲取並轉換 BaaS 數據接口描述，通過 RPC 調用獲取內容數據，合併組件和數據，回填 APP HTML 和模板，等等進行實質的 SSR 過程。
Watching： 服務日常運維提效相關，包括通用監控、日誌傳輸、離線計算、服務觀測等等。

4.1 組件響應

組件是同構的最小粒度，同構給了組件一種非常強大、複用度極高、靈活多元的運行環境，事實上是客戶端、邊緣服務、中心服務的一個整合。我們把職責單一的組件內容展示和交互邏輯內聚在一起，讓組件代碼在端和雲環境中至少執行兩次，在服務器端環境下執行一次，產出網頁的 Contentful HTML 結構，在瀏覽器端環境下再執行一次，水合接管頁面的交互響應。組件可以根據不同階段的全局環境標記做更加垂直細分化的 render 響應，來控制更多的個性化適配邏輯，通過在 FaaS 沙盒底層規模化完整抹平，驗證了絕大部分的組件零接入成本。即使組件不做響應，也可以通過實現 FC 操作 HTML 結構，響應請求結果。

4.2 接口描述

組件是頁面骨架，數據是頁面靈魂。在 FaaS SSR FC 中使用 JSON Scheme 語言描述的接口，由 FaaS RPC 中轉處理引擎將瀏覽器的源請求轉換爲對應的 BaaS 調用，鏈接上下游數據通信，具有縮短調用鏈路、加速結果響應的特性。該描述規範包括：URI 地址、靜態參數、動態參數、請求頭、請求方法、權限校驗控制、響應捕獲機制、存儲庫等其它私有協議格式。

4.3 構建改造

在構建階段的目標是明確模塊內不同資源的規則邊界，迎合源代碼資源，通過加載、編譯、依賴分析，產出多元多層次的產物，發佈至 BFF 應用，供大規模的部署。同時通過工程自動化的手段使流程線可複製。新增產物包括：模塊清單、頁面 Bundle、SSR 計算函數。

4.4 開發體驗

技術方案要開拓落地場景，必須先” 本地化” 再” 生產化”，只有建立流暢的本地開發體驗，纔能有可能在線下獲取開發者用戶，展開合作共建。基於 FaaS 的 SSR，即便頁面開發者沒有服務端 DevOps 經驗、沒有腳手架，也可以通過構建插件引入 FaaS SDK，不耦合服務端框架，進一步減少開發時間和成本，本地實時看到 SSR 結果，讓你的網頁瞬間優質化。

4.5 風險控制

” 我們不能徹底阻止有不兼容的組件代碼、下游 BaaS 黑洞等等，但可以避免當問題發生時直接影響到用戶訪問。” 在這個思路的指導下，通過改變 BFF 軟件架構，創建了” 兩存一降” 架構設計理念，它更能容忍組件異常、下游 BaaS 異常、FaaS 環境異常，從而能提高 BFF 服務整體穩定健壯性。兩層緩存和一種降級策略：

緩存 1： 即代理層緩存。當 FaaS 服務異常時，返回最近成功的 SSR 緩存。
緩存 2： 即 FaaS 層緩存。實現對不同模塊不同頁面的公共下游響應數據共用，當下遊 BaaS 服務異常時，返回最近成功的 API 緩存。
降級： 即服務降級爲 CSR，當以上沒有緩存時回退到響應靜態文件。

另外，由於以” 兩存一降” 爲基板，也大幅削減了各模塊各頁面接入 SSR 能力所製造的成本，成本的降低提高了該技術方案應用到各業務場景中的可能性。從周級降低到小時級，隨着接入效率的提升，產能、意願、信心不斷增加。隨時可發佈 FaaS FC，且只由頁面開發同學自己來定，也僅專注頁面結果，真正爲開發人員提供無服務器的開發體驗。

五、方案展望

技術方案實際的功效是提高了系統的下限，它限制工程方法不跌落到無底線的混亂之中，方案設計既要要控制邊界也要預留擴展，提升開發者” 犯錯誤” 的水平。工程化的鏈條輻射，各種恰到好處的側面侵入，可以輕鬆移植進更多模塊。率先垂範，佈局切入前端工程化新基因，共同拓展漸進式增量升級的能力，帶來技術選型上的靈活性。賦能新形態業務模式，同時降低實驗沉默成本。

總而言之，Web 應用 SSR 升級已成爲一個普遍的現象，也在不斷創造新的範式，而且還遠未結束。展望是建立在歡迎新來者和擁抱未來的基礎上，這些使得 SSR 方案高度多樣化——自由、活力、多邊智慧。

參考閱讀：

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