当 Rokid 遇上函数计算-Toy模板网

这篇具有很好参考价值的文章主要介绍了当 Rokid 遇上函数计算。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

作者：王彬（阿里云解决方案架构师）、姚兰天（Rokid 技术专家）、聂大鹏（阿里云高级技术专家）

公司背景和业务

Rokid 创立于2014年，是一家专注于人机交互技术的产品平台公司。Rokid 通过语音识别、自然语言处理、计算机视觉、光学显示、芯片平台、硬件设计等多领域研究，将前沿的 Al 和 AR 技术与行业应用相结合，为不同垂直领域的客户提供全栈式解决方案，有效提升用户体验、助力企业增效、赋能公共安全，其 Al、AR 产品已在全球八十余个国家和地区投入使用。
Rokid Air Pro 这款AR眼镜产品，为旅游景点，大型企业，国内科研机构都提供了服务支持。目前 Rokid 已和全国百余家博物馆和景区达成合作，给游客穿越时空，身临其境的非凡参观体验。

架构革新的必要性

Rokid 在 AR 的研究可以追溯到公司创立之初，在2012年 Google Glass 横空出世，其广阔的想象空间深深震撼了 Rokid 创始团队。后面虽然因为使用的场景和高额的价格原因，Google Glass 并没有持续的火爆普及。但可以预计在不久的将来，随着基础设施，生态应用的成熟，和人们持续提升的对娱乐，办公的体验要求，AR技术一定会得到更广泛的应用。
Rokid 在数字文化领域，围绕展陈导览解决方案，主要形成了三维建图，场景创作，场景体验三个业务模块，每个模块都有不同的后台平台支撑。

三维建图：制作展陈导览的第一步是取景，通过设备获取场地的真实布景，然后通过算法处理，进行三维建模，之后可以经过创作器进行下一步的内容创作。
场景创作：在三维建模生成的视频流上创作，通过 Web3D 渲染引擎，将创作内容与场景紧密结合，结合硬件设备，在 AR 设备使用时，形成一体化的体验效果。
场景体验：AR 设备在使用时，根据定位服务，锚定在场景中的位置，根据位置的不同会显示不同的空间内容，达到扩展现实场景的效果。

整体的产品架构图如下：

三维建图，场景创作，场景体验三个场景都涉及到了的图像处理，需要大量的 GPU 资源。其中三维建图属于离线任务，在构建展陈模型时，需要将整个展陈场所的视频内容进行预处理，是三个场景中消耗算力最大的部分；场景创作需要配合创作软件，GPU 资源主要来自开发机器；场景体验在设备真实运行时提供实时服务，主要功能是定位服务，对服务的实时性要求很高。
为了支撑 GPU 算力的需求，Rokid 在开发的初期就决定尽可能的使用云资源承载，充分利用云计算的红利。最初是购买了 ECS 的 GPU 机型，用于业务的开发和测试。这里很大的问题是在三维建图时，一般都会一次性采集展陈环境的所有场景资料，视频量巨大，通过 ECS 串行处理需要时间很长，一个1小时的视频资料，通过一台 ECS GPU 机器需要处理3小时左右。Rokid 做的第一步是并行化，通过拆分 CPU 和 GPU 处理逻辑和优化任务编排方式，尽可能的让可以并发处理的部分拉起更多的资源加大并发量，通过这一系列的优化，视频的处理时间得到了不错的提升。
在并发资源方面，Rokid 选择的 GPU 计算资源是 ECI，相对 ECS，ECI 可选的资源粒度更加多样，特别是在小规格的选择上，对于切分的小块视频，通过并发的使用小规格 ECI 实例并行处理，大大缩短了整体视频的处理时间。为此，Rokid 内部平台还开发了一套针对阿里云 ECI 资源的调度模块，方便内部快速的申请和归还 ECI 资源。
通过对 ECI 资源的灵活使用，在保证高峰期任务处理并发度的同时，也保证了算力成本的可控，使用流程上得到了初步的优化。但是通过一段时间的使用，发现还是有很多的不足之处，主要问题总结如下：

ECI 资源的申请和释放都依靠使用人员主动操作，有时在使用完毕后会忘记及时释放资源，导致资源闲置浪费。且开发和维护 ECI 的调度程序也需要占据对应同学一定的精力，带来了一些额外的运维工作。
三维建模的任务经过拆分后，分成了好几个步骤，每个步骤的任务都需要异步执行，需要一个系统维持任务的调用关系，在上一个步骤完成后，拉起下一个步骤的任务继续运行。
在运行过程中，会存在异常情况，排查下来，有时是因为申请的计算资源规格过小导致计算负载较高，有时是存储异常或存储空间写满，还有些情况是程序本身性能瓶颈。对于程序的整体监控缺乏，使得出现问题时不能第一时间发现，发现有异常排查过程不够直观，需要通过多种工具获取运行指标分析。
GPU 算力在云上规模有限，在高峰期会偶尔存在 ECI 资源弹不出的情况，影响开发效率。

为了解决上面问题，Rokid 内部架构组寻求优化已有的架构，针对第2点，Rokid 自行维护了一个总的调度系统，进行任务编排；针对第3点，通过阿里云 Arms Tracing，Promethues，Grafana 等组件的引入，结合 ECI 硬件指标，统一收集到 SLS，形成统一的监控报表，再配以监控指标的告警，也能够初步的满足 Rokid 使用需求。但第1点和第4点，很难通过增加云产品或者内部应用程序解决。为此 Rokid 架构组开始寻找云上新的产品，以求彻底的解决使用过程中的痛点问题。此时，Serverless 架构的函数计算出现在了 Rokid 架构师的视野，经过一段时间的调研使用，函数计算的各项能力都能够很好的满足 Rokid 使用场景。

函数计算的出现恰逢其时

函数计算是事件驱动的全托管计算服务。使用函数计算，客户无需采购与管理服务器等基础设施，只需编写并上传代码或镜像。函数计算会准备好计算资源，弹性地、可靠地运行任务，并提供日志查询、性能监控和报警等功能。函数计算提供 CPU，GPU 的算力，秒级计费，客户只需要为实际资源使用付费。资源弹性可根据定时，请求量等指标自动伸缩，无需维护调度，负载，重试，异步回调等组件，提供了开箱即用，用完即走，按量付费的极致 Serverless 能力。函数计算 GPU 架构如下：

底层依托阿里云的大计算池，提供近乎无限的计算资源，通过阿里云的 cGPU 技术，可将单卡 GPU 资源切分成多种更小粒度的资源规格。客户在函数计算选择 GPU 规格创建函数，在有请求时，函数计算会实时从预热资源池获取资源，配合对应的镜像程序，启动客户函数，启动完毕后对外提供服务。
函数计算在第一次运行实例时会涉及到资源的拉起，弹性交付时间在1s（热启动）～20s（冷启动）。Rokid 的三维建图场景是离线任务，单个视频的处理时间也在分钟级，对于秒级别的启动时延完全可以接受。
在三维建图任务接入函数计算后，Rokid 不再需要手动申请 ECI 资源，在使用结束之后也不需要在手动释放。函数计算会根据请求流量，动态的拉起与请求量匹配的后端 GPU 算力资源，在请求处理结束后，一段时间没有新请求的情况下，自动释放资源；整个三维建模在拆分后涉及好几个步骤，每个步骤都是异步执行，通过函数计算的异步系统，在一个步骤的任务完成后，可以自动触发下一个任务；函数计算控制台内置了指标监控，异常告警，链路追踪，调用日志，异步配置的功能，可以满足 Rokid 从开发，运行监控到运维全函数生命周期的功能需求；函数计算底层依托阿里云大计算池，加上预热和资源评估的后端算法，可以最大程度的保证资源供给；这几点正是 Rokid 之前遇到的痛点问题，通过接入函数计算单一的产品，就解决了 Rokid 近乎全部的主要问题。
接入函数计算后，Rokid 的云产品技术架构如下：

函数计算资源利用率监控图如下，从监控图可以看出，在有任务进入时，GPU 计算利用率可以达到60%甚至接近100%。

体验与架构的妥协

Serverless 理念的函数计算确实给 Rokid 带了很多的便利，在高峰期资源的扩展性和成本节约方面都做到了当前云产品的极致，但函数计算也并非万能，对于 Rokid 的场景体验功能，也就是需要实时提供定位服务的模块，函数计算还是存在了一定的问题。
函数计算在第一次拉起实例资源时，会存在1s（热启动）～20s（冷启动）的启动时间，这个时间对于实时定位服务模块是不可接受的，实时定位是在使用者身处展陈场地时，AR设备通过实时定位，获取空间位置的AR拓展信息，接口响应的时间对客户的体验非常重要，定位请求需要在1s以内返回。
在成本和服务质量之间，Rokid 选择了服务质量优先，场景体验模块采用 ECI 部署，通过每天的定时任务，在高峰期提前弹出更多的 ECI 实例，在低峰期时，保留少量的 ECI 实例，以此达到体验和成本的平衡。
另一方面，函数计算在实时的场景也并非完全没有解决方案。目前 GPU 的模型一般都很大，镜像都在 G 级别，所以对于第一次资源拉起，在接下来一段时间内还看不到跟 CPU 资源一样100ms级别的拉起速度。针对实时场景，函数计算 GPU 实例在做的是预留实例，该功能可以在资源闲置时，释放计算资源的同时，保留程序的内存运行镜像，在有新的请求进来时，只需要供给算力资源，函数就能提供服务，免去了中间硬件资源拉起，函数镜像拉取和启动的时间，可以提供实时的服务。预留实例已经在 CPU 实例上线，闲置时 CPU 价格是运行态的1/10，在保证实时能力的情况下，大大降低了资源成本。GPU 版本的预留能力预计年底上线。
场景体验采用 ECI 后，Rokid 的业务架构图如下：

出色的效果和进一步的期待

通过一系列的云架构改造，当前 Rokid 三维建图模块运行在函数计算的 GPU 资源上，场景体验模块运行在 ECI 资源，在成本和性能上，都做到了兼顾，且给整个系统强大的可拓展性，达到了系统设计时设定的架构目标，从2023/2上线提供服务以来，达到了不错的效果。其中三维建图模块降本明显，相比最初的 ECS 架构，算力成本降低了40%，更为重要的是，通过实时的并发处理，大大减少了子任务的排队时间，加快了整个任务的完成时间。
下一步，Rokid 对于函数计算的 GPU 预留实例还是非常期待，期待函数计算能够尽快上线，这样 Rokid 内部可以将整个的 GPU 算力都迁移到函数计算，达到架构的统一。
经过展陈展览项目的实践，Rokid 相信以函数计算为代表的 Serverless 一定是云计算的未来，通过 Serverless，云计算的使用者不再需要关注底层的 Iaas 层运维和调度，在保证成本最优的情况下能够得到最大限度的拓展能力，且在整服务的生命周期，都能使用云产品提供的原生能力，简单，快速的定位，解决问题。Rokid 在3d模型处理，音视频后处理方面正在大规模尝试函数计算，Rokid 相信以函数计算为代表的 Serverless 架构也一定会在越来越多的云产品上得到应用。