灵伴科技（Rokid）借助 Knative 实现 AI 应用云原生 Serverless 化

作者：朱炜栋、元毅、子白

公司介绍

Rokid 创立于 2014 年，是一家专注于人机交互技术的产品平台公司，2018 年即被评为国家高新技术企业。Rokid 作为行业的探索者、领跑者，目前致力于 AR 眼镜等软硬件产品的研发及以 YodaOS 操作系统为载体的生态构建。公司通过语音识别、自然语言处理、计算机视觉、光学显示、芯片平台、硬件设计等多领域研究，将前沿的 Al 和 AR 技术与行业应用相结合，为不同垂直领域的客户提供全栈式解决方案，有效提升用户体验、助力企业增效、赋能公共安全，其 Al、AR 产品已在全球八十余个国家和地区投入使用。

业务场景

Rokid 在数字文化领域，围绕展陈导览解决方案，主要形成了三维建图，场景创作，场景体验三个业务模块，每个模块都有不同的后台平台支撑。

三维建图： 制作展陈导览的第一步是取景，通过设备获取场地的真实布景，然后通过算法处理，进行三维建模，之后可以经过创作器进行下一步的内容创作。

场景创作： 在三维建模生成的视频流上创作，通过 Web3D 渲染引擎，将创作内容与场景紧密结合，结合硬件设备，在 AR 设备使用时，形成一体化的体验效果。

场景体验： AR 设备在使用时，根据定位服务，锚定在场景中的位置，根据位置的不同会显示不同的空间内容，达到扩展现实场景的效果。

未雨绸缪，磨刀不误砍柴工

在 AR 大潮的涌动中，Rokid 紧随时代脉搏，持续精进业务迭代与技术更新。我们深刻理解到，在构建稳定可靠、高效卓越且经得起市场严峻考验的 AR 部署解决方案时，必须秉持未雨绸缪的策略和工匠精神。

面对瞬息万变的场景体验领域，我们尤为关注 GPU 资源的依赖性，因其直接决定了用户通过扫描或小程序步入 AR 世界的实时服务品质。定位的即时性和准确性成为了衡量服务质量的关键指标。从具体的商业逻辑、研发挑战到技术选型层面，我们面临的核心问题聚焦于以下两点：

初期的策略构想中，我们曾探讨过购置专用 GPU 机型以及采用 Kubernetes 社区原生的 Horizontal Pod Autoscaler 方案。然而，实践是检验真理的唯一标准，基于业务实际运行效果的反馈，我们意识到单一方案并不能满足所有需求。深信“工欲善其事，必先利其器”的理念，在历经数次实战探索及联合调试的过程中，Rokid 携手阿里云共同砥砺前行，最终在阿里云强大基础设施的支持下，打磨出一套更为高效、成熟且适应市场需求的实施方案。

基于 GPU 按需使用如何做

我们知道 GPU 资源很贵，按需使用尤为重要。K8s 社区提供的原生 HPA 方案基于 CPU、内存等静态阈值实现，如果要基于 GPU 使用率指标则需要通过自定义指标方式实现，配置繁琐，此外 GPU 使用率指标并不能最直接反馈业务请求负载情况，对于在线应用来说，通过请求流量的并发数、qps、rt 等指标，可以很好的衡量当前的服务质量，能否基于这些指标做到按需弹性。

如何快速发布迭代应用

在 K8s 中如果要做基于流量的蓝绿发布，首先需要创建对应的 K8s Service 与 Deployment，如果需要弹性，则还需要配置 HPA，然后在流量灰度发布时，要创建新的版本，最后通过 Ingress 设置对应的流量比例，最终实现流量灰度发布的功能。显然，在 K8s 要做基于流量的蓝绿发布，需要管理多种资源，并且随着版本的迭代，管理起来会更加复杂。

弹性滞后

我们知道应用往往很难做到秒级启动，也使得基于 HPA 扩容存在较大的滞后性，带来真实业务的稳定性风险。如何减少弹性滞后带来的业务影响，是需要我们要解决的问题。

GPU 资源不足的问题

云上 GPU 资源有限，如何保证常态下 GPU 资源供给，以及在突发业务场景下，及时扩容出 GPU 资源。

标准化

当前 Serverless 产品丰富多样，各个云厂商和开源社区都有。我们在技术选型时需要考虑尽可能通过标准化的方式使用 Serverless 能力，以满足多云、混合云等场景。

解决方案

从资源按需使用、GPU 供给、稳定性以及标准化等方面的考虑，我们选择了阿里云 ACK + Knative 的解决方案，保证弹性供给兼顾成本最优，整体方案如下：

云原生 Serverless 框架 Knative

Knative 是一款基于 Kubernetes 的开源 Serverless 应用编排框架，其目标是制定云原生、跨平台的 Serverless 应用编排标准。其提供了基于请求数、并发等指标的自动弹性能力，并且通过多版本管理机制，可以方便的做到基于流量的灰度发布、快速回滚的功能。

ACK 智能弹性（AHPA）

针对传统弹性能力所存在的问题，我们采用了 ACK 容器服务推出的 AHPA（Advanced Horizontal Pod Autoscaler）弹性预测 [ 1] ，可以根据历史 Pod 的 Ready Time 以及历史 Metrics 自动学习规律，在业务量上涨之前的一个 Ready Time 开始扩容，在业务量上涨时 Pod 已提前准备，可以及时供给资源，解决弹性滞后的问题。

AHPA 弹性预测根据历史数据自动规划未来 24 小时每一分钟的应用实例数，相当于进行 1440 个点（一天为 1440 分钟）的 CronHPA 定时配置。

ECS、ECI混部

弹性容器实例 ECI（Elastic Container Instance）是阿里云一款敏捷安全 Serverless 容器运行服务，用户无需管理底层服务器资源，同样也不需要关心运行过程中的容量规划，非常适合应对这种流量突发下业务场景。

但从弹性供给来看，ECI 并不能完全保证资源的供给，结合我们常态下业务使用情况，当前采取混合部署模式，兼顾成本及稳定性两方面的业务目标。如图所示，常态业务下我们使用 ECS 资源，在突发业务流量下，通过 ECI 提供按需使用资源。

自定义弹性资源优先级调度

由于采用了 ECS 及 ECI 两种部署模式，在资源的调度策略上，我们期望应用扩容和缩容行为都是确定性的。那么，部署的服务优先调度顺序理论上依次为：ECS、弹性实例 ECI。同时在服务缩容时优先删除 ECI 上的 Pod，释放 ECI 的节点资源，然后删除 ECS 上的 Pod。这里我们采用了自定义弹性资源优先级调度策略：ResourcePolicy。

对于不同类型的节点需通过打上不同节点标签实现，然后创建 ResourcePolicy 自定义节点池调度顺序。参考文档：自定义弹性资源优先级调度 [ 2] ；那么结合 Knative 使用的话只需要在 selector 指定相应的 Knative Service 名称即可。ResourcePolicy 配置示例如下：

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: xxx
  namespace: prod
spec:
  selector:
    serving.knative.dev/service: worker-go ## 此处指定Knative Service 名称即可
  strategy: prefer
  units:
  - resource: ecs
    max: 2
    nodeSelector:
      key: value
  - resource: eci

业务价值

在当前的实施中，我们已成功运用 ACK（阿里云容器服务）与 Knative 这一先进组合构建并部署了在线服务系统，籍由 Knative 出色的多版本管理特性，提升了我们的应用迭代效率。 同时，得益于其基于请求动态调节的自动扩缩容能力，能够实时响应突发业务需求，精准按需调配 GPU 资源，实现成本和性能之间的平衡。

本次合作实践，犹如 Rokid 与阿里云携手共舞，在赋能业务创新的同时，也有力推动了阿里云产品的深度优化。展望未来，身处 AR 技术引领的宏大计算新时代，Rokid 深信，以阿里云 Knative 结合 ECI 为代表的技术解决方案将在持续演进与迭代的过程中，不仅将为众多云计算使用者带来实质性收益，更将以卓越的架构设计和体验革新，逐渐渗透到更多前沿产品之中，构筑起强大而灵动的云上基础设施，进而惠及广大用户群体，共同见证并塑造云计算发展的新篇章。