建企业网站行业网,群晖 wordpress 性能,学生个人网站模板,检测网站开发作者#xff1a;朱炜栋、元毅、子白
公司介绍
Rokid 创立于 2014 年#xff0c;是一家专注于人机交互技术的产品平台公司#xff0c;2018 年即被评为国家高新技术企业。Rokid 作为行业的探索者、领跑者#xff0c;目前致力于 AR 眼镜等软硬件产品的研发及以 YodaOS 操作系…作者朱炜栋、元毅、子白
公司介绍
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 容器服务推出的 AHPAAdvanced Horizontal Pod Autoscaler弹性预测 [ 1] 可以根据历史 Pod 的 Ready Time 以及历史 Metrics 自动学习规律在业务量上涨之前的一个 Ready Time 开始扩容在业务量上涨时 Pod 已提前准备可以及时供给资源解决弹性滞后的问题。
AHPA 弹性预测根据历史数据自动规划未来 24 小时每一分钟的应用实例数相当于进行 1440 个点一天为 1440 分钟的 CronHPA 定时配置。
ECS、ECI混部
弹性容器实例 ECIElastic 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: xxxnamespace: prod
spec:selector:serving.knative.dev/service: worker-go ## 此处指定Knative Service 名称即可strategy: preferunits:- resource: ecsmax: 2nodeSelector:key: value- resource: eci业务价值
在当前的实施中我们已成功运用 ACK阿里云容器服务与 Knative 这一先进组合构建并部署了在线服务系统籍由 Knative 出色的多版本管理特性提升了我们的应用迭代效率。 同时得益于其基于请求动态调节的自动扩缩容能力能够实时响应突发业务需求精准按需调配 GPU 资源实现成本和性能之间的平衡。
本次合作实践犹如 Rokid 与阿里云携手共舞在赋能业务创新的同时也有力推动了阿里云产品的深度优化。展望未来身处 AR 技术引领的宏大计算新时代Rokid 深信以阿里云 Knative 结合 ECI 为代表的技术解决方案将在持续演进与迭代的过程中不仅将为众多云计算使用者带来实质性收益更将以卓越的架构设计和体验革新逐渐渗透到更多前沿产品之中构筑起强大而灵动的云上基础设施进而惠及广大用户群体共同见证并塑造云计算发展的新篇章。
Rokid 活动案例
钉钉×Rokid 发布「钉钉数字文化墙」30 分钟打造 AR 数字展厅 上海旅游节灵境 AR 花车巡游引爆城市级空间体验 3D 经典奥特曼全国 AR 首展 携手央博阿里云全球首个李白数字展亮相云栖大会 全国首个 AR 商业化剧目亮相乌镇戏剧节 相关链接
[1] AHPAAdvanced Horizontal Pod Autoscaler弹性预测
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/ahpa-overview-1?spma2c4g.11186623.0.i0
[2] 自定义弹性资源优先级调度
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/configure-priority-based-resource-scheduling
点击此处了解更多阿里云 Knative 产品相关信息
