<云原生>Serverless 高密度部署</云原生>
- 二层调度与交付时间
- 一层调度: 机房/IaaS 天
- 二层调度: 容器/K8S 分钟/秒
- serverless 冷启动: 几十秒 几秒 几百毫秒 -> 容器冷启动时间
- 设备性能
- 函数运行时
- 网络延时
- 代码包/镜像大小
- 冷启动的影响: hostless stateless elasticity
- 冷启动优化
- 供应商: 设备
- 供应商: 网络架构
- 业务: 更轻量运行时, 比如 nodejs ->
搞来搞去, 还是容器启动 - 业务: 合理组织函数代码
Web-interoperable Runtime
- 三层调度与交付时间
- 进程/线程: 毫秒级 亚毫秒级
- 三层调度: 统一接入网关 -> FaaS网关 -> pod -> scheduler/gateway -> 高密度部署
- 极端的资源利用率优化
- OCI 资源限制/资源隔离: EaaI PaaC runc iku
- WinterCG: The Web-interoperable Runtimes Community Group
- Interoperable: 互通性 -> 大胆点:可相互替代、兼容
- Interoperable 前提: 标准化 -> common minimum api
- winter: nodejs Deno CloudFlareWrkers Oxygen+Hydrogen
- 自研 Hourai.js -> 用于高密度部署
- Low barrier-to-entry: 大基数下，JavaScripters 熟悉浏览器 API ≥ Node.js API
- Hostless / Event-driven -> Node.js 之 PM2、部署、运维......
- Stateless / Elasticity
- 轻量 / 启动速度快
- 池化、snapshot......
- iku 提供 ASSS 能力，专攻极速启动
<实践>出真知</实践>
- 高密度部署 = 更高的资源利用率(智能的资源自适配算法) + 更快的调度速度(搭配亚毫秒启动 Winter) + 更低的运维成本(嫁接到我们自己身上了)
- 实践: 某服务迁移到线程级高密度部署(底层基于 Goofy Worker 1.0 的运行时)， CPU Core 从原来 287 降低到 24，内存从原来 574G 降低到 39G。
- 可扩展: 可适配各种 IaaS / FaaS 层，以应对不同场景。
- 实践·云原生· OpenTelemetry
- 实践·云原生· Dapr
- 实践·流程编排
- 实践·首屏速度: 首屏时间的长短对于用户的滞留时间的长短、用户转化率都尤为重要。
- 实践·边缘 SSR (筹) = Modern.js × 边缘机房 × 高密度部署 × Web-interoperable Runtime
<理想要大>未来展望</理想要大>
展望·调度跃迁
- K8S 直接穿透调度
- 直接部署物理机，K8S 直接调度
- K8S......?🤥🤥🤥
展望·Hourai.js
- 更极速的 ASSS 能力;
- 分布式极速启动的能力;
- 与社区一起推进 WinterCG 发展; 4. ToB?开源?......
