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

全文3608字，預計閱讀時間10分鐘

===

一、背景

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

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

二、訴求即目標

同構的SSR：頂層設計上已不接受基于模板的SSR技術，因為異構的TPL和JS增加了頁面組件的維護切換成本，基于業(yè)務與團隊現(xiàn)狀，我們需要快速迭代，一套代碼100%復用，同時JS一體化同構的SSR能把組件代碼侵入降到最低。

極速接入：頁面開發(fā)者希望集成在CSR工程下，幾乎為零的模塊、項目和頁面目錄改動。一方面因為CSR是業(yè)務承載大頭，另一方面是前端分散的多個模塊現(xiàn)狀，遷入一個集中式的龐大工程內(nèi)再拆成可控的小塊，加上依賴關系管理，改造成本極大，為了接入SSR要重構甚至重寫是削弱工程化ROI的。

開發(fā)體驗：頁面開發(fā)者更專注于組件代碼本身，CSR的開發(fā)部署方式，修改代碼打包發(fā)布即可。希望BFF服務編排和云端基礎設施一切都以NoOps有條不紊的運行。數(shù)據(jù)接口和字段復用更是基本訴求。

效果保障：使用服務端HTML結果渲染首屏，適當?shù)睦镁彺娌呗?#xff0c;加速受訪縮短FMP時間，提升網(wǎng)頁服務品質(zhì)。SEO友好，利于內(nèi)容密集型網(wǎng)頁獲得搜索的曝光。

===

三、FaaS SSR普世

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

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

• Page Resources：SSR過程所需的必要元素

• Template：頁面模板，即CSR頁面的HTML，同時是SSR頁面的模板。

• Bundle：組件打包的bundle，這份供Node.js Server端進行SSR的bundle產(chǎn)物，需要webpack單獨打包產(chǎn)出。

• FC：控制SSR過程的計算函數(shù)，實現(xiàn)SSR 核心的鉤子，在Function Sandbox中運行，可以自定義SSR結果。

• Data：填充組件的BaaS數(shù)據(jù)，通過調(diào)用Backend Service獲取。

• Routing：路由頁面請求及調(diào)度資源

• manifest.json：模塊構建產(chǎn)出的資源清單。每個方向模塊自動產(chǎn)出一份，聲明上述Page Resources的資源等信息。

• module：模塊的信息，manifest.json路徑、模塊查詢路徑等信息。

• router：解析當前Request信息的Lambda函數(shù)，匹配到當前頁面的Template、Bundle、FC信息，并向FC派發(fā)HTTP事件。

• BaaS：后端即服務，包括接口、存儲、通信等Backend Service。通過Spec描述即可交給FaaS RPC調(diào)用目標服務。

• Rendering：通過系列Lambda函數(shù)管道調(diào)用，注入整個過程的環(huán)境變量，包括獲取并轉換BaaS數(shù)據(jù)接口描述，通過RPC調(diào)用獲取內(nèi)容數(shù)據(jù)，合并組件和數(shù)據(jù)，回填APP HTML和模板，等等進行實質(zhì)的SSR過程。

• Watching：服務日常運維提效相關，包括通用監(jiān)控、日志傳輸、離線計算、服務觀測等等。

---

4.1 組件響應

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

---

4.2 接口描述

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

---

4.3 構建改造

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

---

4.4 開發(fā)體驗

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

---

4.5 風險控制

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

• 緩存1：即代理層緩存。當FaaS服務異常時，返回最近成功的SSR緩存。

• 緩存2：即FaaS層緩存。實現(xiàn)對不同模塊不同頁面的公共下游響應數(shù)據(jù)共用，當下游BaaS服務異常時，返回最近成功的API緩存。

• 降級：即服務降級為CSR，當以上沒有緩存時回退到響應靜態(tài)文件。

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

五、方案展望

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

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

推薦閱讀：

日志中臺不重不丟實現(xiàn)淺談

百度ToB垂類賬號權限平臺的設計與實踐

視覺Transformer中的輸入可視化方法

深入理解 WKWebView (渲染篇) —— DOM 樹的構建

深入理解 WKWebView（入門篇）—— WebKit 源碼調(diào)試與分析

總結

以上是生活随笔為你收集整理的前端工程化之FaaS SSR方案​的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。