Rokid 创立于 2014 年，是一家专注于人机交互技术的产品平台公司，2018 年即被评为国家高新技术企业。Rokid 作为行业的探索者、领跑者，目前致力于 AR 眼镜等软硬件产品的研发及以 YodaOS 操作系统为载体的生态构建。公司通过语音识别、自然语言处理、计算机视觉、光学显示、芯片平台、硬件设计等多领域的研究，将前沿的 Al 和 AR 技术与行业应用相结合，为不同垂直领域的客户提供全栈式解决方案，有效提升用户体验、助力企业增效、赋能公共安全，其 Al、AR 产品已在全球八十余个国家和地区投入使用。
Rokid 在数字文化领域，围绕展陈导览解决方案，主要形成了三维建图、场景创作、场景体验三个业务模块，每个模块都有不同的后台平台支撑。
三维建图：制作展陈导览的第一步是取景，通过设备获取场地的真实布景，然后通过算法处理，进行三维建模，之后可以经过创作器进行下一步的内容创作。
场景创作：在三维建模生成的视频流上创作，通过 Web3D 渲染引擎，将创作内容与场景紧密结合，结合硬件设备，在 AR 设备使用时，形成一体化的体验效果。
场景体验：AR 设备在使用时，根据定位服务，锚定在场景中的位置，根据位置的不同会显示不同的空间内容，达到扩展现实场景的效果。
面对瞬息万变的场景体验领域，Rokid 尤为关注 GPU 资源的依赖性，因其直接决定了用户通过扫描或小程序步入 AR 世界的实时服务品质。定位的即时性和准确性成为了衡量服务质量的关键指标。从具体的商业逻辑、研发挑战到技术选型层面，面临的核心问题聚焦于以下两点：
-
成本效益（按需弹性伸缩）
-
启动效率（实现秒级启动）
如何实现基于 GPU 按需
GPU 资源很贵，按需使用尤为重要。K8s 社区提供的原生 HPA 方案基于 CPU、内存等静态阈值实现，如果要基于 GPU 使用率指标则需要通过自定义指标方式实现，配置繁琐，此外 GPU 使用率指标并不能最直接反馈业务请求负载情况，对于在线应用来说，通过请求流量的并发数、QPS、RT 等指标，可以很好地衡量当前的服务质量，能否基于这些指标做到按需弹性。
如何快速发布迭代应用
在 K8s 中如果要做基于流量的蓝绿发布，首先需要创建对应的 K8s Service 与 Deployment，如果需要弹性，则还需要配置 HPA，然后在流量灰度发布时，要创建新的版本，最后通过 Ingress 设置对应的流量比例，最终实现流量灰度发布的功能。显然，在 K8s 要做基于流量的蓝绿发布，需要管理多种资源，并且随着版本的迭代，管理起来会更加复杂。
弹性滞后
我们知道应用往往很难做到秒级启动，也使得基于 HPA 扩容存在较大的滞后性，带来真实业务的稳定性风险。如何减少弹性滞后带来的业务影响，是我们需要解决的问题。
GPU资源不足
云上 GPU 资源有限，需要保证常态下 GPU 资源供给，以及在突发业务场景下及时扩容出 GPU 资源。
标准化
当前 Serverless 产品丰富多样，各个云厂商和开源社区都有。在技术选型时需要考虑尽可能通过标准化的方式使用 Serverless 能力，以满足多云、混合云等场景。
从资源按需使用、GPU 供给、稳定性以及标准化等方面的考虑，Rokid 选择了阿里云 ACK + Knative 的解决方案，保证弹性供给兼顾成本最优，整体方案如下：
Knative 是一款基于 Kubernetes 的开源 Serverless 应用编排框架，其目标是制定云原生、跨平台的 Serverless 应用编排标准。其提供了基于请求数、并发等指标的自动弹性能力，并且通过多版本管理机制，可以方便地实现基于流量的灰度发布、快速回滚的功能。
针对传统弹性能力所存在的问题，Rokid 采用了 ACK 容器服务推出的 AHPA（Advanced Horizontal Pod Autoscaler）弹性预测，可以根据历史 Pod 的 Ready Time 以及历史 Metrics 自动学习规律，在业务量上涨之前的一个 Ready Time 开始扩容，在业务量上涨时 Pod 已提前准备，可以及时供给资源，解决弹性滞后的问题。
AHPA 弹性预测根据历史数据自动规划未来 24 小时每一分钟的应用实例数，相当于进行 1440 个点（一天为 1440 分钟）的 CronHPA 定时配置。
弹性容器实例 ECI（Elastic Container Instance）是阿里云一款敏捷安全 Serverless 容器运行服务，用户无需管理底层服务器资源，同样也不需要关心运行过程中的容量规划，非常适合应对这种流量突发的业务场景。
但从弹性供给来看，ECI 并不能完全保证资源的供给，结合常态下的使用情况，当前采取混合部署模式，兼顾成本及稳定性两方面的业务目标。如图所示，常态业务下使用 ECS 资源，在有突发业务流量的时候，通过 ECI 按需提供资源。
由于采用了 ECS 及 ECI 两种部署模式，在资源的调度策略上，期望应用扩容和缩容行为都是确定性的。那么，部署的服务优先调度顺序理论上依次为：ECS、弹性实例 ECI。同时在服务缩容时优先删除 ECI 上的 Pod，释放 ECI 的节点资源，然后删除 ECS 上的 Pod。Rokid 采用了自定义弹性资源优先级调度策略：ResourcePolicy。
对于不同类型的节点需通过打上不同节点标签实现，然后创建 ResourcePolicy 自定义节点池调度顺序。结合 Knative，只需要在 selector 指定相应的 Knative Service 名称即可。ResourcePolicy 配置示例如下：
在当前的实施中，Rokid 已成功运用阿里云容器服务 ACK 与 Knative 这一先进组合构建并部署了在线服务系统，借助 Knative 出色的多版本管理特性，提升了 Rokid 的应用迭代效率。同时，得益于其基于请求动态调节的自动扩缩容能力，实时响应突发业务需求，精准按需调配 GPU 资源，实现成本和性能之间的平衡。