淘宝人生云渲染技术总结
01 背景介绍
- 淘宝人生是什么:数字人IP平台,具有“外透”到其它业务的潜力。
- 为什么要做云渲染:
- 端上实现问题:难以兼容异构运行环境、移植渲染引擎成本高、批量化生产影响端性能。
- 云上优势:无需考虑兼容性、无需植入引擎、支持更多可能性(如录制动画、生成高质量照片、跨引擎渲染)。
- 云渲染的系统设计特色:
- 算力受限性:倒推渲染技术(RT)。
- 技术选型:基于Midway的Serverless架构。
02 初级方案
- 流程与架构:涉及精灵动图、斗地主、麻将等业务,触发云渲染生成产物,并在多个消费端使用。
- 渲染集群:448个渲染容器(28*16)。
- 渲染任务运行时:使用Puppeteer,但存在适配和修复需求。
- 成果演示:初步实现云渲染功能。
- 问题与反思:
- 用户有效覆盖率问题。
- 不支持多业务队列。
- 服务缺乏量化体系(业务关心排队时间)。
- 渲染效率不高(Puppeteer跨进程传数据耗时)。
03 进阶方案
- 算力与业务关系的理论模型:
- 实验模拟数据结论:
- 排队任务需在2小时内执行。
- 任务处理速度QPS与等待时间呈负相关。
- 提高处理速度需增加机器数量或优化算法,但存在性价比天花板。
- 多队列架构与全局调度器:
- 面向消费的生产优化策略:
- 新的渲染任务运行时:
- 使用Headless-GL替代Puppeteer,完成适配和修复。
- 改进后的整体架构:解决初级方案的问题,提升效率。
04 未来展望
- 面向并发的渲染容器架构升级:
- 支持更多的渲染运行时环境:
- 云渲染助力端侧实时渲染:
总结
- 流程与架构:云渲染通过触发生成渲染产物,并在多端消费。
- 渲染集群:初期448个渲染容器,后期通过架构升级提升并发能力。
- 渲染任务运行时:从Puppeteer优化至Headless-GL,解决效率问题。
- 问题与反思:初级方案存在覆盖率、多队列、量化体系、效率等问题,通过进阶方案解决。
- 理论模型:算力与业务QPS关系为负相关,需通过扩展或优化提升性能。
- 未来方向:提升并发架构、支持更多渲染引擎、助力端侧实时渲染。