冷启动充当看门人,业务 POD 0-1 流量会经过 Activator 组件
突发流量的保护者,将 Activator 加?到核心路径,充当缓冲,流量将会在 Activator 缓存(0.8 版本 加入功能)
其次 Queue Proxy 作用是:
Queue Proxy 以 Sidecar?式和应?容器部署到同?个 Pod,Queue Proxy 是为了配合完成扩缩容事宜以及满足 App 可观测性要
求,以 Sidecar 方式部署主要考虑到对 App 应用无侵入,功能描述如下:
完成观测性数据收集向 Autoscaler 同步当前的并发监控,以便实现自动伸缩功能
代理业务容器, 完成指标的统计,并将对应的数据汇报给后端的?志 / 监控 / 分布式跟踪服务
Activator 必要性分析
谈到 Activator 必要性,需要先了解当前 Serverless 难题“冷启动”,所谓冷启动是 Serverless 缩容到 0 后,重新从 0 扩容到 1
的过程,该过程目前是非常慢的,也是业界难题,根据社区对 Knative 冷启动分析得知,冷启动时间大概 6s ,很显然 6s 的冷
启动任何业务都?法容忍;当前可以尽量优化冷启动时间,但是想达到 ms 级别,做到业务?感知,挑战非常大,目前有两种解
决思路:
方向 1: 温启动,通过冗余方式建立预热池来解决,当需要 0-1 时候,从预热池取,然后将用户程序注入,省去建立容器的过
程
方向 2: 通过默认预留实例来规避
目前该问题我们先通过方向 2 来解决,至于方向 1 也在考虑,但是涉及到的开发工作量大,且需要对 K8s 框架改动,需要根
据需求触发。所以目前在我们使用场景中不需要 Activator 帮助从 0-1 扩容。
对于突发流量保护功能,在使?场景中可降低扩容触发的并发要求,预留出一定的 Pod 计算能力来抵御突发流量;因此在目前
业务场景中,Activator 存在必要性?般,可以考虑将其从核心数据路径中彻底去除。
QueueProxy 必要性分析
Queue Proxy 核心作用是收集 App 的指标(并发、RPS 等)来决定扩容,当前以 Sidecar?式部署是非常有必要的:
将核心指标统计逻辑提炼到 Queue Proxy,对 App 无任何代码逻辑侵?,基础设施和应用 App 业务逻辑分离,独立运维
收集扩容指标支持跨语言
所以 Queue Proxy Sidecar 是非常有必要的,但是相比裸业务容器而言,会增加?层代理(该场景就像服务网格 Server
Sidecar?样),导致业务容器性能降低,这是选择这种架构所要付出的资源成本,我们要做的就是将该成本降到最小。
如上图,总结下分析结论,从性能?度出发,我们需要关注:
将 Activator 从数据路径中去除
重点关注 Queue Proxy 和 App 路径
关注 Knative 网关和 Queue Proxy 路径