辛宝Otto

辛宝Otto 的玄酒清谈

北漂前端程序员儿 / 探索新事物 / Web Worker 主播之一/内向话痨
xiaoyuzhou
email

速通-掘力计划第26期 node.js 的实践和未来

image

掘力计划第 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 内置语法。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 要简化一些。

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

加载中...
此文章数据所有权由区块链加密技术和智能合约保障仅归创作者所有。