公司先容

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/v1alpha1kind: ResourcePolicymetadata: name: xxx namespace: prodspec: 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 为代表的技能办理方案将在持续演进与迭代的过程中，不仅将为浩瀚云打算利用者带来本色性收益，更将以卓越的架构设计和体验改造，逐渐渗透到更多前沿产品之中，构筑起强大而灵动的云上根本举动步伐，进而惠及广大用户群体，共同见证并塑造云打算发展的新篇章。

Rokid 活动案例

钉钉×Rokid 发布「钉钉数字文化墙」，30 分钟打造 AR 数字展厅

上海旅游节灵境 AR 花车巡游引爆城市级空间体验

3D 经典奥特曼全国 AR 首展

携手央博&阿里云，环球首个李白数字展亮相云栖大会

全国首个 AR 商业化剧目亮相乌镇戏剧节

干系链接：

[1] AHPA（Advanced Horizontal Pod Autoscaler）弹性预测

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/ahpa-overview-1?spm=a2c4g.11186623.0.i0

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

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/configure-priority-based-resource-scheduling