先出文字版本，再出語音版本吧。
GMTC 2021 演講《字節跳動基於 Serverless 的前端研發模式升級》
微信鏈接
by 2021-07-07 字節跳動 Web Infra 王磊
下面是我的筆記，一部分是原文，一部分是思考。原文部分我會注明。
serverless 不是新概念，對大廠來說更不是新東西，肯定大廠也有自己的 BaaS 體系，畢竟 FaaS 相對好做，背後的基建還是要定制，懷著這個想法來看。
大綱總覽#
原文：接下來將從以下 6 個方面介紹今天的內容
- 首先總結一下大前端時代下前端的職責和挑戰
- 然後介紹字節跳動常見的業務形態
- 字節跳動傳統的研發模式和挑戰
- 之後介紹我們是如何基於 Serverless 對前端的研發模式進行升級的。
- 為了保證穩定性，我們在監控運維方面也做了不少工作。
- 最後簡單做一下總結和展望。
1 工作內容多#
第一部分不意外，工作內容拓寬，切圖仔 - 大前端 - SSR/BFF/ 微前端 / 跨端、一體化、Serverless。
我沒太理解 BFF 到微前端的漸進式開發。
知識體系部分，傳統框架知識，還需要構建工具、後端。需要補充 redis/mq/ 對象存儲、監控告警等。主要還是需要補充後端和運維的知識。
2 業務形態多#
第二部分也不意外，toC + toB，繞不開 CSR+SSR+BFF，微前端他放的位置很高。作為全球公司少不了全球部署，全球部署那就少不了分佈式數據同步呗。
3 需求和挑戰#
第三部分，舉例 web 開發的問題。這裡展開看下。
CSR+BFF
- CSR 是前端基礎部署，拓展也就是接入 CDN + k8s 集群部署。
- 業務亮點：對象存儲的處理、登錄鑑權、AB 會讀、集群運維
- BFF 的部署繞不開 k8s 集群
- 業務亮點：權限、運維、流量控制、域名接入 (估計是 dns 一套走)
- 部署系統
- 項目管理、發布系統、旅遊管理、ab 管理
這裡也沒有太多新東西，但是對普通前端來說東西很大，很難。問題就是太龐大了，Serverless 呼之欲出了。
好了，快把東西掏出來吧。
4 基於 sls 的方案#
第四部分，基於 Serverless 的研發模式。
概念對齊和拓展#
Serverless 業界實踐：
- 已經有 FaaS，比如調度、冷啟動等
- BaaS 結合
- 雲函數、Node 框架、Runtime 等
那麼一個基於 Serverless 做一站式前端解決方案。所謂解決方案首先要畫圖：架構分層架構圖 + 生命周期路線圖。
繼續看下去，一站式平台要提供基礎平台能力，常見能力開箱即用，DX 友好 (nuxt 正是在下)。
那麼平台能力都有哪些呢？
文字解釋不用看了。平台化掏出來，DDDD。先談架構，再談落地。
這部分和 modern.js 異曲同工。如果在想開啟 SSR，一鍵搞定。其實也難，類似 nuxt.js，提供 CSR/SSR/SSG 模式可選，api 目錄自動映射。部署產物使用在線的配置，分配路由和域名。
架構圖分層這就來了：
這裡文字東西很多，左邊介紹了架構圖，右邊介紹了生命周期、數據流動。
說完架構，展開聊了下 CICD，這裡我基於 Coding 提供的能力看，提交代碼 - 編譯 - lint - 安全檢查 - 會讀測試人工審批 - lighthouse 性能檢查 - 人工審批上線。
服務編排流水線，配置文件和流程互轉。
那麼就來到落地了。
CSR 落地#
首先是普通 CSR，產物自動上傳到 CDN，一份 es5 一份 es6，為啥要分開，為了 ESM？上線的過程，這裡有個平台控制圖，似乎是
- 分配域名
- 勾選對象存儲的文件夾
- 選擇發布
給了一張圖
原來如此，es6 是為了後面的動態 polyfill，根據 ua 動態返回，有點 https://polyfill.io/ 的意思了，動態填補，果然大廠，想到的都用上了。
SSR 落地#
在分配路由時，可以選一下 SSR、微前端模塊。對應 Nuxt 的配置 mode 變化吧。
用戶訪問 SSR 還是得走緩存，先看 Redis 否則就通過服務發現 (分佈式架構) 的對應服務，異常情況需要 CSR 兜底。
BFF 落地#
哦懂了，關聯已有知識，Nuxt 的 Nitro API 目錄，剛才的 SSR 就是 SSR。編譯之後產物有 bff 文件，表示了對應的服務，部署服務就有了 BFF 服務。
分的比較開，我只能理解到這裡了。
SSR 服務發現使用 RPC 調用，CSR 使用 HTTP 調用，常規。
微前端落地#
微前端就是一個頁面裡去套另一套系統的頁面，這裡不解釋。內部產出到了 Garfish 微前端體系，技術產出可以類比 micro-app/wujie
大廠的目標肯定還是要絲滑，從項目基建上做準備。
目標選擇，我需要開發 CSP/SSR/BFF/ 微前端應用，這樣開發，一樣交付。微前端多了父子模塊關係、微前端菜單等功能。
我推測父子模塊關係，需要定義 root 容器和對應的 url 路由。他有個頁面，申請關聯才能統一關聯。沒太理解作用
我推測後者微前端，就是菜單可配，畢竟菜單才是入口，菜單命中的頁面是空的，作為容器引入。畢竟要動態鑑權，想起我曾經的噩夢哈哈哈。
我就理解到這裡了，流量進來先到網關 - 容器頁面 - 加載微前端。
5 監控運維#
前端玩了這麼多東西，還是要看負載和運維，有了 k8s 簡單了很多，我推測可以有面板監控、監控報警方案、自動重啟和回退、說不定還有火焰圖。
首先是定義指標，通過規則引擎設定閾值。
- 404 告警
- 5xx 告警
- qps 超額告警
- ssr 失敗告警
有了告警，就得彈窗要處理，有問題了要怎麼辦
- 知道了，不處理
- 屏蔽半小時，屏蔽 6 小時
- 取消屏蔽
- 這是正確告警、錯誤告警、需要處理。埋點上報
- 複製內容求助
有了指標就可以做大屏了，我太警覺了。試試看到負載效果。
日誌還是要接入日誌系統，日誌系統對接做單獨的管理和篩選。也就是海量數據的信息探查。爭取做到鏈路追蹤。
有了問題，如何保護現場和調試？這裡有點盲區了，應該還是遠程 sourcemap、火焰圖分析，他也承認內部有類似 alinode 自定義的東西，node 運行時調試。
對 snapshot/cpu profile 分析就有點黑魔法了，不懂，尊重。
6 總結展望#
未來 serverless 的發展：
- runtime 要更好的處理冷啟動、動態擴縮容
- 更好的 baas 做好平台建設
- serverless+ 也就是一站式服務
他們 infra 團隊
- apm platform
- test infra
- low code
- 跨端解決方案
- web 開發引擎
- engineering platform
- 移動中台
- serverless
- node.js 架構
- web ide
- 微前端解決方案
- design ops
閱讀結束的感受#
大廠果然是大廠，很坦誠很真實，玩的深入。
自己吹牛逼也越來越好了，能猜到他們在說什麼了。開心！