辛宝的玄酒清谈!
2709 words
14 minutes
速通-掘力计划第26期 node.js 的实践和未来

掘力计划第 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 酒店前端负责人任龙飞

大纲

  • 用户体验数字化
  • 前端数字化提效
  • 总结和展望

用户体验数字化#

业务背景和分析 用户运营场景细化。用户体验、开发体验。

如何度量用户体验?不同的指标,这里给了一个图。有颜色的部分。

image.png

细化方向。

image.png

距离技术视角

之前零碎的工具和指标,这里做整体的数字化。

指标部分比如流畅度 tti/fcp/lcp 等,稳定性 crash exception killRate、能耗 energy cpu overheat 等

能力部分,架空,apm,报表等。

要做整体数字化,不外乎定指标、做监控、做平台,嘉宾给了图,做细节展示。

image.png

这里讲的我陌生,具体讲如何落地优化体验,先有评价指标,所有部门对齐认知,汇总可行性方案。具体部门做了优化体验的部分,就抽象出来去推广,让基础部门做方案。

之后全生命周期测数据,分别做专项优化。

但,前端优化是有瓶颈的,到最后还是数据获取阶段。怎么优化,还是预测、预搜,让用户进下个页面能更快,空间换时间。

就变成预请求方案设计。还是通过不同的策略,计算什么行为之后触发提前请求。

技术收益:预测请求命中率 31%,TTI 降低 60%+

触发时机,比如首屏触发、浏览触发、跳转触发。

有了测算,就可以做监控,看趋势,找问题,拆指标,专项优化。

竞品分析,尽量自动化测试。比如准备手机截屏、代码注入、ocr 识别等,还是落实到自动化手段,数据结合。

image.png

这是为了同行业对比数字化。

定期和竞品比对。定义指标、测量数据、汇总分析。

前端数字化提效#

对业务负责,牵扯线上服务内容比较多,如何优化前端效率呢?

image.png

低代码平台的配置。BFF 也是做 serverless 上线服务。

这里介绍了如何自研 Serverless 平台,看图没什么,后面需要了可以回来听。

从本地到云上开发。还介绍了系统成品。系统设计图。toC 的容器流量一直有。

单 pod,多函数,安全性考虑业务隔离。

总结#

image.png

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:xxx 内置语法。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:test + node:assert

ts 作为一等公民,deno/bun 都内置支持。知识进阶,equal 类型体操 tsc/tsd/tsx/tsup/tsdoc 等,ioc 装饰器、设计模式、oop 等。

从 mongo 到 primay / drizzle 等,引入了类型。Proxy/Reflex,事务处理还比较麻烦,开箱即用的还偏少一点。

oop 未来和 java 差异不会太大。

现在写一个 node 模块也不是很容易了。如果使用 deno/bun 要简化一些。

image.png 和 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 技术方案

image.png

使用 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 的这些变化,

速通-掘力计划第26期 node.js 的实践和未来
https://ijust.cc/posts/quick-review-juejin-meetup-26-nodejs/
Author
辛宝 Otto
Published at
2023-11-06