Serverless SSR 技術在獵豹移動的實踐

時間 2021-05-15

標籤 html 前端 webpack git github web express 編程 redux 後端欄目無線简体版

原文原文鏈接

做者：董文梟 | 策劃：王俊傑

爲了追求速度體驗和極致的 SEO 效果，愈來愈多的技術管理者和架構師傾向於採用 SSR (Server Side Rendering) 技術來構建前端項目，以支持同構代碼的服務器端渲染。而在雲的時代，更多的應用將遷移到雲端部署，Serverless 雲技術因其下降開發成本、按需自動擴縮容、免運維等諸多優點，已經大量被開發者採用以更快的構建雲上應用。html

本篇文章整理自獵豹移動負責平臺前端部負責人董文梟老師的採訪。經過董老師的講述，咱們進一步瞭解到獵豹移動前端團隊是如何基於騰訊雲 Serverless 技術在其前端項目中應用 SSR 的。前端

做者簡介

採訪實錄

問：董老師您好，請簡要介紹一下您所在的團隊。webpack

答：個人團隊是平臺前端部，負責公司 AI、機器人、廣告系統等業務和對外網站業務，團隊成員包括前端工程師和 Node 全棧工程師。git

問：基於什麼背景和問題，您的團隊考慮採用 SSR 的技術方案？github

答：固然是追求極致的用戶體驗，雖然 HTML、CSS、JS 以及其餘資源都作到了按需加載，但這裏的 SSR 更是 Isomorphic（先後端同構），把 SSR (Server Side Rendering) 和 CSR (Client Side Render) 的優勢結合，讓用戶瀏覽網頁的時候不論是首屏仍是隨後操做的其餘頁都能更快的展現響應。web

問：您的團隊使用 SSR 技術方案時，有沒有進行一些調研？express

答：咱們團隊在 2016 年的時候開始使用 React，2017 年就開始研究並嘗試 React Server Render，同期 Facebook 的網站已經採用 Isomorphic 技術實現，性能很是好。爲了知足公司業務需求和技術傳承，咱們自研了獵豹的前端技術框架 Koot.js，目前已成爲獵豹前端的主要技術方案。編程

問：可否從技術的角度介紹一下目前使用的 SSR 方案的前端技術框架 Koot.js，是基於什麼樣的架構，有哪些模塊？redux

答：Koot.js 包含了 SSR，也是咱們團隊自研的方案，因此都是在用它.後端

Koot.js 是基於 React、Koa、Webpack 來架構的，其中用 Koa 搭建的 Node 做爲開發服務和部署時候的 SSR 服務，頁面渲染主要是用 React+Redux 完成的一套代碼在瀏覽器環境和 Node 環境通用，利用 Webpack 可編程性動態生成配置並執行，打包出多場景（開發、測試和線上環境等）多端代碼（前端、服務端）部署。

同時在開發過程當中配合了自研工具和模塊來輔助開發，如 koot-router、koot-redux、koot-webpack 進行了封裝簡化調用方法，提高開發效率；koot-cli 完成腳手架模板選擇、項目配置等；koot-i18n 提供了多模式多語言方案，能夠作到正常開發，打包後多語言內容按需加載的效果；集成了 koot-analyze 分析代碼、預製 eslint 規範的 koot 版本等知足了平常工做所需的大部分技術點。

具體落地的時候，咱們把自研的 Koot.js 使用 Serverless Framework 進行了封裝，作了一個 Serverless 組件，這樣在其餘業務場景須要用的時候就能夠直接複用，能夠節省很多成本，避免了重複造輪子，下降了出錯的機率。

問：SSR 的技術方案在落地時過程是否順暢，遇到了哪些問題，是如何解決的？

答：SSR 項目落地的時候一般不是很順暢，項目部署的時候須要具有服務器技術能力才能和運維順暢溝通，因此項目落地不只要前端同窗掌握後端開發能力還要對運維技術、併發等問題多方面考慮，這對前端技術同窗的技術全面行有較高要求。

在這種狀況下，去年咱們開始接觸 Serverless 技術，Serverless 技術能夠下降前端對服務端和運維的技術能力但要求，更適合大部分要作 SSR 的前端團隊。調研了幾大雲廠商 Serverless 服務，最後綜合比較後，選擇了騰訊雲做爲咱們實現 SSR 的 Serverless 服務支持。

騰訊雲 Serverless 提供了比較全面的組件支持，與 Serverless Framework 基本是無縫結合，周邊社區和生態支持也比較到位，使用過程應該會少踩一些坑。在選定了平臺以後就比較順暢了，由於 Serverless Framework 提供了不少標準化的接口，在封裝 Koot.js Serveless 組件的過程當中也比較省心。

問：目前的 SSR 方案推進了您所在團隊哪些協做模式或分工的優化？

答：咱們很早就作了前端分離的開發，先後端徹底使用 API 對接，協做改變不大。由於咱們作了 Isomorphic，因此對 API 的要求變高，用戶的請求不止來源於 Node 服務器，還有來自瀏覽器的請求，對安全性要求會高一些。

問：從您的視角，目前 SSR 方案是否還須要一些改進？

答：我認爲未來的 SSR 都應該是 Isomorphic 的模式，帶來的好處是減小傳輸成本，分攤渲染壓力，用戶體驗也會有所提高。體驗的提高其實很是小，網路狀況好時，用戶幾乎感知不到，但小小的提高在技術開發中卻作出了很是多的工做，所以咱們會把技術框架作的愈來愈完善，讓業務開發同窗可以快速開發出需求，同時又享有 Isomorphic 帶來的技術體驗。

問：對於還未開始作 SSR 的團隊您有什麼建議嗎？

答：若是要作 ToC 的產品，建議作 SSR 嘗試，讓用戶儘快的看見頁面內容老是更好的。

前端的 SSR 必定會考慮是否須要 Isomorphic，若是小團隊建議先從比較流行的框架着手嘗試，如 Next.js、Nuxt.js 等，也推薦體驗咱們的 Koot.js。Next.js、Nuxt.js 這些框架在騰訊雲 Serverless Framework 都現成的組件支持，Koot.js 也能夠用咱們的方案。不管是 SSR 仍是 Serverless，最好都是基於現有框架，從零開始搭建框架坑太多了，若是沒有足夠業務支持不要浪費精力本身去作框架，學會一個框架的成本要遠小於維護一個框架的成本。

最後，感謝董老師接受 Serverless 中文社區的採訪。