Noslate Workers - 面向云原生的 JavaScript 容器方案

1. Noslate Workers 面向云原生的 JavaScript 容器方案杜佳昆（凌恒）大淘宝-跨端技术部-Node 架构-前端工程师

2. 目录 01 SSR 渲染业务的挑战 02 如何帮助业务应对挑战 03 面向未来探索

3.

4. SSR 渲染业务的挑战

5. Server Side Render 服务器端向客户端发送一个完全渲染的页面（准确来说是仅仅是 html 页面）。结合客户端的 JavaScript bundle 使得页面可以运行起来

6.

7. 模版引擎

8. User Code User Code VM Context VM Context Node.js Process 函数计算 Pod 函数计算 Pod LRU Cache

9. 用户困扰 1. 额外学习成本 2. 使用现代化的方式构建丰富的页面，以满足多样的业务需求

10. 开放 JavaScript 执行环境

11. 面临什么问题

12. User Code User Code VM Context VM Context LRU Cache Node.js Process 函数计算 Pod 函数计算 Pod 1. 用户代码不可信 2. Node.js VM 存在逃逸可能

13. 面临什么问题代码执行隔离业务代码多种多样，存在相互影响的风险

14. User Code LRU Cache User Code LRU Cache Node.js Process Node.js Process 函数计算 Pod（页面 A）函数计算 Pod（页面 B） 1. 业务成本不可控 2. 秒级冷启动速度难以满足需求

15. 面临什么问题代码执行隔离成本权衡业务代码多种多样，存在成本和弹性效率如何平衡相互影响的风险

16. User Code LRU Cache User Code LRU Cache Node.js Process Node.js Process 函数计算 Pod（页面 A）函数计算 Pod（页面 B）业务缓存失效

17. User Code User Code Node.js Process Node.js Process 函数计算 Pod（页面 A）函数计算 Pod（页面 B） Remote Storage（如：Redis）网络稳定性

18. 面临什么问题代码执行隔离成本权衡减少业务代码间的影响成本和弹性效率如何平衡缓存命中率减少对业务逻辑的干扰

19. 如何帮助业务应对挑战

20. 社区是怎么做的 SnapStart Zero Cold Start Deno Deploy 加速 Java 函数启动速度，可基于 V8 打造的运行环境，通 Secure by default 降到亚秒级过 isolate 隔离逻辑执行，支持通过 KV Storage 共享数据

21. 我们的思考 - 三层调度模型 Aworker Aworker Aworker Aworker Noslate Workers 毫秒级交付容器化 – K8S、Docker Swarm 分钟级交付传统 IaaS – 物理裸机、虚拟化架构天级交付

22. Noslate Workers 基础架构 Inbound Noslated Outbound 负载均衡、实例调度、弹性策略 Aworker Node.js 自研 Web-interoperable Runtime Turf 资源隔离、实例管理 Inbound Outbound Control

23. Noslate Workers 基础架构 Inbound Noslated Outbound 负载均衡、实例调度、弹性策略 Aworker Node.js 自研 Web-interoperable Runtime Turf 资源隔离、实例管理 Inbound Outbound Control

24. Noslate Workers 基础架构 Inbound Noslated Outbound 负载均衡、实例调度、弹性策略 Aworker Node.js 自研 Web-interoperable Runtime Turf 资源隔离、实例管理 Inbound Outbound Control

25. Turf 基于 OCI 标准的轻量容器管理组件，负责 Noslate Workers 运行实例的管理，提供实例间的资源隔离能力。 1. JavaScript 代码运行在 VM 里，它并不直接调用系统调用； 2. JavaScript 依赖库可能很多很大，基本都会依赖于外部服务； 3. 需要能够提供即时响应请求的启动速度；目标：提供一定程度的隔离性和共享文件系统与系统服务

26. Turf 调度单元进程传统容器 fork(2) 是一个系统调用，用于创建进程。创建的这个进程与原来进程几乎完全相同。 1. 新进程可以继承母进程的当前状态，而无需从 main() 开始初始化； 2. PCB、栈、内存页，页表都是纯内存复制，所以进程创建快 (<1ms)； 3. CopyOnWrite，新进程可以继承母进程的静态页表，可节省系统内存；

27. Turf 隔离能力 CGroup Seccomp/Setuid Rootfs System Call Hooks 资源隔离，最小化授权

28. Turf 交付产物 Sandbox.json Image

29. Noslate Workers 基础架构 Inbound Noslated Outbound 负载均衡、实例调度、弹性策略 Aworker Node.js 自研 Web-interoperable Runtime Turf 资源隔离、实例管理 Inbound Outbound Control

30. Aworker Web API 1. 遵循 Web API 标准的 Web-interoperable JavaScript 运行时，实现了近似 Service Worker API 的规范，提供了基本的 Request-Response 服务 API。 2. 提供更加高层次、抽象的定义，不会泄漏系统底层状态

31. Aworker 为极速启动设计 1. 单进程单线程运行架构 2. 通过 Warmfork 和 Startup Snapshot 能力，实现了更快的水平及垂直 3. 提供 busyloop 检测能力，防止过度消耗资源

32. Aworker Node.js 进程模型 Aworker 进程模型 1. 使用了 Linux AIO 特性替掉了 libuv 中同步的文件系统操作 2. 使用 V8 的 SingleThread 模式运行架构

33. Aworker Warmfork

34. Aworker Warmfork 配置种子沙盒 Turf 运行种子进程创建克隆沙盒启动克隆沙盒启动种子沙盒 Seed 种子报告 ForkWait Turfd 种子就绪 libturf 发起克隆克隆完成调用 fork 加载用户代码 Aworker

35. Aworker 无 Warmfork：450ms 有 Warmfork：40ms

36. Aworker Startup Snapshot Startup Snapshot 相当于从 V8 Context 对象与它的 globalThis 开始，遍历堆中所有的对象并将对象关系与引用序列化成特有的字节码，形成一个线性的可存储状态。并在恢复时，解释执行这些字节码，恢复堆中的对象内容与他们之间的引用关系。

37. Aworker Startup Snapshot 1. Node.js 最终有 2-5 倍的优化效果（100ms→20ms）； 2. Aworker 内建的模块 Snapshot 后，裸启动耗时 10ms；

38. Aworker Startup Snapshot 局限性 1. Startup Snapshot 对内存开销敏感，如果应用启动阶段用了大量内存，可能造成负优化； 2. 用户代码启动需要没有歧义的状态，比如 IP 地址、日期、连接状态、服务发现结果等，针对这些歧义内容用户代码需要在进程恢复时有修正能力；

39. Noslate Workers 基础架构 Inbound Noslated Outbound 负载均衡、实例调度、弹性策略 Aworker Node.js 自研 Web-interoperable Runtime Turf 资源隔离、实例管理 Inbound Outbound Control

40. Noslated Noslate Container Deamon，作为 Noslate Workers 解决方案的核心，提供了 Serverless 需要的 Worker 实例调度、弹性扩容、配置管理、流量管理等能力。 Noslated Client 与外部交互 Control Plane Data Plane 流量分发过载保护配置管理 Outbound 代理 KV Storage 实例管理弹性调度

41. Noslated Noslate Container Deamon，作为 Noslate Workers 解决方案的核心，提供了 Serverless 需要的 Worker 实例调度、弹性扩容、配置管理、流量管理等能力。 Noslated Client 与外部交互 Control Plane Data Plane 流量分发过载保护配置管理 Outbound 代理 KV Storage 实例管理弹性调度

42. Noslated 弹性调度 Data Plane request Control Plane Aworker Turfd 扩容扩容 fork connect 流量拉起 install installed fetch response response request drained stop worker kill signal disconnect uninstall 即抛模式

43. 总结代码执行隔离以进程为执行容器隔离业务代码，通过 turf 实现系统资源的隔离控制。同时在 Aworker 中提供对 busyloop 的执 01 行时间限制。成本权衡 02 通过 Noslated 的即抛模式，实现每个渲染任务独立、全新的执行环境，配合 Aworker 的 Warmfork 能力保证响应及时。缓存命中率 03 数据面提供了具备 LRU 能力的 KV Storage 和 Cache API，可以用来在函数间共享数据

44. 业务成果 1. 支持开发者使用 JavaScript 编写页面业务开发者可以低成本、简单的通过 SSR 渲染服务输出所需页面 2. 同场景下机器成本减少约 30% 改造前改造后机器利用率 40% 80% 机器成本万 QPS 约 1000C 万 QPS 约 700C

45. 面向未来探索

46. 一、探索更多业务场景 1. 使用 Noslate Workers 自建业务所需的 FaaS 平台 2. 基于 Context 1:N 执行业务逻辑的可行性二、参与标准建设 1. Winter CG 社区 2. CNCF Landscape – Serverless Installable Platform 三、和上层调度结合 1. 感知 Noslate Workers 函数分布，更均衡的调度流量 2. 反压联动，资源消耗更加合理，弹性更加平滑

47. Noslate Project 云原生 JavaScript 容器方案面向 Node.js/V8 的离线 Corefile 调试工具，提供 V8 堆内存检查、 Heap Snapshot 诊断文件导出、Backtrace 等特色调试功能，并配套一个高性能的运行态 Corefile 获取和压缩工具。面向弹性场景进行优化，提高了用户代码的加载速度提高冷启动效率，主要包括 Require 关系加速、Bytecode Cache。同时还包含来自阿里云基础软件团队面向 ARM 架构的性能优化特性。 https://noslate.midwayjs.org/

48. 扫码回复「D2」获取第十七届 D2 演讲 PDF 材料后续也将推送 D2 会后技术文章，敬请关注！！

49. 感谢大家观看