掘力計劃第 26 期北京站線下沙龍｜聊聊 node.js 的實踐和未來 - 掘金
三個分享
1/3 淺談 SSR 和 Worker#
梁偉文字字跳動 - NodeJs Infra - 研發工程師
五年前端工作經歷，先後就職美團、字節跳動。目前在字節跳動從事基礎技術研發。
SSR 相關#
SSR 基礎概念介紹，區分 CSR 概念。
SSR 的好處
- 更好的 SEO
- 不外乎 fp/fcp 的時間更關注。
- 統一語言
- 可選引入
不用 SSR 的場景
- 為了更好的響應 TTFB - time to first byte
- 更早的交互 TTI - time to interactive
- 沉重的 UI 交互
- 複雜的用戶驗證
運行時支持 Node.js、Deno、cf workers 等
Worker#
引入 service worker 可以引入 fetch，相當於構建了請求。從這個角度出發，引入了 winterCG 的組織，包含了不同的運行時。兼容 web api 的標準化，一套代碼可以在不同運行時運行。
複合標準的標準的運行時。
worker 的優點
- web 標準運行時。
- 基於 v8 開發標準運行時，實現獨立、可控，從 api 到運行時都可以掌控
- 開發私有 api
- 輕量，伺服器負擔很低，pm2 啟動 3-4 個實例，如果使用自己的 worker，可以運行上百的進程
- 部署也快，舉例字節內部從 node -> worker，部署時間降低 90%
- 通用的方案，可以同構，用同一套工具、開發流程
worker 的問題
- 不可能完整兼容 node 環境，沒有 fs net 之類的，比如 pupeteer node-gyp 之類的
- 只有 fetch 觸發請求，不能 rpc 和定時器等，不能 tcp 數據庫
- 鏈路追蹤的 id 沒有標準，容易混亂
兼容問題較多。
延伸一個技術分享《字節跳動 Serverless 高密度部署與 Web-interoperable Runtime 實踐》
worker 實際落地，生成 qrcode 的服務，很快上線二維碼。因為 serverless 高密度部署系統，不用關心伸縮性、性能規格。
特點：輕量、部署快。
落地場景：
- 可以把 worker 作為一個流程引擎，執行代碼的節點嵌入。比如 langchain 去處理，處理輸入和輸出。
- 廣告規則的計算。費用
- 產品策略選擇。以上主要還是在快、輕量、好上線
- 比如一些核心服務的伴生服務，不能對原來服務有負擔
- 自動化生產的產物，比如配置接口，得出接口服務
SSR 和 worker 的結合#
- SSR 需要 js runtime 運行時，worker 就是
- SSR web 標準
- SSR simple logic
使用場景舉例，忽略。
SSR 放到 worker，worker 不熟到 edge、CDN 等。
既然把 SSR 放到 worker 上，那麼就可以在不同的場景上去運行：
- nsr-native side render 移動端渲染，預測下一頁渲染，得到移動端的秒開
- 流式渲染，為了解決 ttfb，現出來一部分內容
- edge 部署，可以 ttfb 優化，也會有其他問題
- csr 兜底，錯誤回退
- 可以緩存比如存儲設置或者 cdn
QA 部分#
- SSR 和 auth 的結合，問能不能實現和用戶權限打通，答案是看選擇，緩存要小心
- SSR 有 SSR+csr 的部分，如何區分一些邏輯的運行時機，比如 window 對象、location 對象
- 服務段就是沒有 window，要麼引入 polyfill 讓 window 不報錯，也麼判斷是否 csr 更合適
- 如何區分 SSR 還是 csr 的請求？這可能需要標記鏈路追蹤
延伸#
Roll your own javascript runtime
2/3 用戶體驗數字化建設及提效#
去哪兒 qunar 酒店前端負責人任龍飛
大綱
- 用戶體驗數字化
- 前端數字化提效
- 總結和展望
用戶體驗數字化#
業務背景和分析
用戶運營場景細化。用戶體驗、開發體驗。
如何度量用戶體驗？不同的指標，這裡給了一個圖。有顏色的部分。
細化方向。
距離技術視角
之前零碎的工具和指標，這裡做整體的數字化。
指標部分比如流暢度 tti/fcp/lcp 等，穩定性 crash exception killRate、能耗 energy cpu overheat 等
能力部分，架空，apm，報表等。
要做整體數字化，不外乎定指標、做監控、做平台，嘉賓給了圖，做細節展示。
這裡講的我陌生，具體講如何落地優化體驗，先有評價指標，所有部門對齊認知，匯總可行性方案。具體部門做了優化體驗的部分，就抽象出來去推廣，讓基礎部門做方案。
之後全生命周期測數據，分別做專項優化。
但，前端優化是有瓶頸的，到最後還是數據獲取階段。怎麼優化，還是預測、預搜，讓用戶進下個頁面能更快，空間換時間。
就變成預請求方案設計。還是通過不同的策略，計算什麼行為之後觸發提前請求。
技術收益：預測請求命中率 31%，TTI 降低 60%+
觸發時機，比如首屏觸發、瀏覽觸發、跳轉觸發。
有了測算，就可以做監控，看趨勢，找問題，拆指標，專項優化。
競品分析，儘量自動化測試。比如準備手機截屏、代碼注入、ocr 識別等，還是落實到自動化手段，數據結合。
這是為了同行業對比數字化。
定期和競品比對。定義指標、測量數據、匯總分析。
前端數字化提效#
對業務負責，牽扯線上服務內容比較多，如何優化前端效率呢？
低代碼平台的配置。BFF 也是做 serverless 上線服務。
這裡介紹了如何自研 Serverless 平台，看圖沒什麼，後面需要了可以回來聽。
從本地到雲上開發。還介紹了系統成品。系統設計圖。toC 的容器流量一直有。
單 pod，多函數，安全性考慮業務隔離。
總結#
qa 部分
- 單 pod 穩定性、熔斷怎麼處理？比如某個單函數 pod 打滿了，副本數如何設置，很專業呐
- 系統是內部平台，不會開源
- 用的 aws 資源，用的 nestjs，函數之間互相調用之間有瓶頸，如何處理
- 函數都能調用到，都可以通過 invoke 或者 new 起來
- aws 用的 iam role 區分資源，函數資源權限控制如何做？目前是默認全開
- 函數自定義運行時，只做了 node 運行時
- 可視化編輯，有沒有做 sdk 編排，怎麼做，編輯實體、運行。多個服務調用是否可以編排。實施難度比較大
3/3 AI 時代給 node.js V20 帶來的一些機遇#
狼叔！
- node 版本變化
- node v20 介紹
- ai 時代新機遇
- 再看全棧
node 版本變化#
2017 node v8 - 2023node v21
v20 很多特性已經穩定了。
node v20#
一些科普和實踐。
從 commonjs -> esm by default，曾經比較混亂，現在統一，到了 v21 默認扶正，更簡單。
社區方面積極推進 esm 落地，只支持 esm 不支持 cjs，延伸提到 sindresorhus 發表的 esm only 渲染。算是一個契機。
- esm 服務轉換：
- 比如傳統的 react 項目，通過分析把依賴專程 esm.sh 上的依賴。
- 遇到 ts 資源可以通過 sucrase 轉譯成 esm 本地直接運行
- 通過自定義 render，把標籤內容寫入 html，就能實現瀏覽器開發，搞定頁面渲染
- 低代碼情況下，完全可以不用 cli 去實現
- vite 為代表，轉 rust，為了可能不需要 cli，esm 方向沒有 cli 可能是一個趨勢
- node 可以運行 web container
未來可期
node 內置語法。node v20 已經可以實現 deno 這種 from remote，只是還沒上到最新版本裡。
異步流程控制。error first/promise/async-await 三種方式。歷史上的 geneator/blue brid 什麼的就比較少了，主流已經接受了 Promise 和 async/await 的方案。
測試方向 xv，寫一個 node assert 測試語句，用 xv 運行，很輕量。
測試框架內置 node:test，以前用框架和斷言庫，現在不需要了。直接 node --test --test-reporter spec --watch ./*..test.js*，node + node
ts 作為一等公民，deno/bun 都內置支持。知識進階，equal 類型體操 tsc/tsd/tsx/tsup/tsdoc 等，ioc 裝飾器、設計模式、oop 等。
從 mongo 到 primay /drizzle 等，引入了類型。Proxy/Reflex，事務處理還比較麻煩，開箱即用的還偏少一點。
oop 未來和 java 差異不會太大。
現在寫一個 node 模塊也不是很容易了。如果使用 deno/bun 要簡化一些。
和 deno bun 對比。優勢缺點。
node 更關注兼容和安全，不是直接追求更快。node 的性能是足夠的。from matteo collina 的《why is bun faster than node.js》
更輕量級的運行時。比如 noslate workers，對 wintercg 實現比較好的 worker，場景 faas + er
thread worker/vm/vm2 方案有很多。
知道 node 擅長、和副作用。少做補充。
node v8 到 v20 增加的東西。
ai 時代新機遇#
融合和生態。
從 prd 識別 ui，到代碼，每一步驟都有大量的計算。比較痛苦。
理解 ai 輔助寫代碼，更多是專家 + ai
ai sdk 的支持，都對 node 有支持，多應用更快。做應用層比其他語言更快。
下圖是 ai 技術方案
使用 node 快速組裝上線，node + ai 有好處。
documate + node，勝場 ai 文檔，aricode 開源的。看他的依賴，orama 向量數據庫，代碼實現簡單，node 很適合實現功能。
融合，trpc 實現前後端調用有類型 @trpc/client。提到了 aircode
使用 httpc.dev 可以實現調用。類似 sdk 上拼裝參數，去 invoke 對應函數。
node - faas 變輕，通過 sdk 隱藏了 http 的相關知識，難度變小
再看全棧#
前端已死？外包、服務端替換的現象。
next.js 直接調用 use server 的現象，感覺回到 php 的時代。前端沒有大的革新。前後端輪回，全棧。
講 rails dhh 的變化
低代碼，工作總量不變，如何減少工作量、減少中間環節。講 retool.com 卷低代碼、sql、自動 UI。
寫卷 4、下個十年、
QA
- cpu 密集計算。thread-worker 架構拆分 napi 調 rust，能力拆分是最有效的，比如讓 golang
- node 內置 ts 有可能嘛，有。
- js+ts，根據類型做優化。是的，生態現在依賴 ts 的類型推斷。
聽完三個分享的展望#
三個人的確厲害，很多東西聽不懂，是實戰出來的經驗。只是密度有點大。
第一個聽完，終於對 worker 有進一步的理解了，也理解 cloudflare 上的 workers/puppeteer/ d1 這些產品的場景限制了，原來做後端，不一定非得是 node
第二個有點難，level 有點高，細化的內容特別多，我沒有實踐過，能理解但消化不了。
第三個，重新看了 node 的這些變化，