🙋🏻♀️ 编者按：本文作者是支付宝后端开发工程师馥云，介绍了 2024 年五福全新互动玩法“烟花摊”背后的技术细节，欢迎查阅～
前言
2023年，我们把数字人带进福气乐园，打造了支付宝首个亿级用户参与的3D多人实时在线互动空间；2024年，随着支付宝五福从“集五福”升级为“五福节”，福气乐园也整体升级为“福气之城”。
福气之城作为五福会场的主链路之一，除了承担「耗卡」这条主线任务，也是各业务场流量转化的中心阵地。今年为卷入更多的用户，福气之城尝试启用平面分层空间，通过三大街区（年俗、好礼、快乐）串联耗卡场景，提供更多商业化的能力。用户在城内不仅可以体验前沿AI科技，还能感受到开放互动带来的无限乐趣。“烟花摊”作为全新玩法，提供了氛围最强、年味最浓的互动能力。
业务玩法
福气之城玩法介绍：以耗卡得好礼/福气值为抓手，让用户在城里通过参与年俗互动、游戏、商业化私域阵地体验、任务打卡等玩法，赚取福气值解锁奖励，福气值达到一定数额后还能参与5000w大奖平分。
在分层街区布局下，用户点击「年俗街」的“天空”区域，即可解锁烟花的沉浸观看模式。沉浸模式下，用户能看到其他用户燃放过的烟花，其中支付宝好友燃放过的会被优先推荐。
烟花摊提供了不同类型的烟花供用户选择，包括能激起用户好奇心的盲盒烟花、支持自定义文案的DIY烟花、寓意吉祥的祈福烟花等。当然，天然具备浪漫属性的烟花，还可以通过多个社交渠道赠送/分享给他人，把美好的祝福传递下去。
技术挑战
烟花渲染体验
福气之城烟花制作的本质是将播放内容通过算法处理得到 uv 采样坐标，燃放烟花就是消费坐标及纹理对象来播放Mars动画（Mars是蚂蚁自研的专注于移动端的动效方案）的过程。
机型覆盖率
参照大促降级标准，一般会有5% 左右的中低端机型会在互动场景中被降级。这部分中低端机型CPU和内存性能较差，在播放Mars动画可能存在渲染卡顿、失败等问题，这将非常影响用户的体验及会场参与的公平性。
UGC实时特效计算
在非 UGC 场景下，烟花内容可枚举，所有的动作、特效、粒子都可以预先处理，播放时直接消费设计提供的 Mars 产物。而 UGC 文字烟花场景中，文字、图片的粒子构造则需要在终端运行时完成，该步骤计算量较大，其中镂空字体的计算量甚至高达 90w+ 次。多数机型的端计算能力有限，可以预见会出现播放发热、卡顿、甚至闪退等现象，需要保障DIY文字烟花渲染的稳定性。
实时互动诉求
用户沉浸模式下观看烟花，可以体验到很多类似直播间的实时互动玩法，包括在线人数 /烟花弹幕氛围实时透出、赠送消息触达等。
互动能力
在2023年福气乐园“元宇宙”互动项目中，已经探索出一套较完善的多人实时互动解决方案。在今年的业务背景下，是否能将这套方案再做抽象沉淀？
实时数据
烟花沉浸模式下需要透出「在线人数」、滚动弹幕等信息以带动更多用户参与实时互动。因为实时人数量会在短时间内急剧变化，准确地统计并实时更新在线人数需要高效的并发处理能力。在分布式架构下，如何将各个服务器节点的数据汇总，并在低延迟下完成实时计算也是一项技术挑战。
内容安全风控
DIY烟花能调动起用户参与的积极性，也带来了内容安全的管控挑战，需要协同内容安全团队建立完善的识别技术方案。
技术选型
云渲染是指在云端服务器上进行渲染计算的方式，它可以通过音视频服务将高质量的图像或视频传递给用户，从而降低了对用户设备性能的需求，基本可以实现在任何终端上正常使用业务功能。引入云渲染技术，用户设备仅需要播放视频，即可解锁烟花观看。
云渲染+直播
前面也提到过，烟花的业务玩法和直播间的互动玩法很类似。在前期方案选型阶段，考虑过采用「云渲染+直播」推流形式。
虽然云端计算能力和存储资源都很强大，但云渲染架构多线程的特点，会占用很多CPU和内存，导致单机运行实例有限，需要承担较高的资源成本。 在五福这种大促场景中，服务高可用性永远是放在首位考虑。上述链路没有经过成熟业务的实践，可行性方面亟待验证。另外，直播内容“千人一面”的特点，很大程度上也会限制我们的互动能力，一些“千人千面”的玩法可能没办法落地。
端云协同渲染
「端云协同渲染」是支付宝端内较成熟的技术架构。在这套架构下云端聚焦渲染，直接在 linux 上启一个精简版浏览器(CEF)/webgl 容器(webglic)，减少云端的消耗，提高单机并发量；客户端承载依赖于端上的能力东西，这样端和云协同渲染，降低云端计算压力，极大的节省了成本。
回到福气之城烟花本身，高端机在设备端渲染烟花Mars动画；对于命中降级决策的中低端机，canvas 互动区域放到云端渲染，JSAPI 等能力走客户端。「云渲染」作为兜底策略保证了烟花玩法可用性。互动玩法基于RTMS服务打通的长链接通路，完成服务侧到端的实时通信诉求。
RTMS：Real Time Message Service，蚂蚁自研的实时消息服务，具有实时性高、交互性强等特点。
方案比对
技术实现
领域模型
烟花模型存储着烟花的全量信息，包括展示内容、耗卡数量、以及渲染需要的动画资源等，由服务端维护。从玩法上看，烟花分为盲盒烟花、DIY烟花、祈福烟花三大种类，每类烟花也都有自己对应的特点。祈福烟花是最好描述的一类烟花，“烟花摊”展示的槽位背后仅对应一个唯一的烟花实例，单独配置该烟花实例即可；盲盒烟花相对特殊，展示槽位背后对应多个烟花实例；DIY烟花在“一对多”的基础上，还伴随着内容文字的不确定性。
- 模式隔离
在模型设计中引入「showMode展示模式」字段，区分某个烟花是否只能用于展示或者能被燃放。比如fireworkId为001和002的盲盒烟花，前者showMode=onlyShow，后者showMode=onlyFire。通过该字段区分前者仅用于展示，烟花展示信息的字段可以只配置在001，002只需要配置播放资源等内容即可，大大降低烟花配置维护成本，也缩小了资源变更带来的影响范围。
- 资源文件拆分
为了避免粒子动画编译浪费，不同DIY烟花共用同一个mars资源，再通过消费不同的UV 纹理来呈现不同效果。所以对于DIY烟花而言，只需配置一个烟花实例即可，具体的UV文件信息则存储在烟花兑换流水记录中。
- 示例文案UV预生成
在DIY文字烟花编辑页面，会预设展示祝福文案示例，方便用户一键使用。这部分文案模型设计如下，其对应的UV纹理坐标会提前生成。如果烟花燃放请求传入示例文案，可以跳过「粒子动效实时计算」，缩短烟花兑换链路耗时，提升产品体验。
云图形计算
UGC文字特效计算对设备性能有较高要求，如果放在终端计算存在卡顿、闪退等风险。去年福气乐园「数字人分享合照」玩法也遇到过类似问题，实时渲染多人高清形象会占用端设备大量内存。当时我们采取了“云端渲染+AFTS存储”的方案，通过将数字形象模型、动作、背景等数据上传到云服务器，云服务器配合Tiny3D渲染引擎（Tiny是具备2D/3D 渲染能力的轻量级互动引擎）执行渲染并截图。参考去年的方案，可以将DIY烟花文字特效计算模块上云，利用云服务器调用对应算法生成UV纹理坐标数据，基本链路如下：
风险：云计算不可用时尝试走本地计算，云图形计算依赖云服务以及GPU资源，存在不可用风险。当某次云图形计算请求失败时，会兜底走本地端设备计算；如果大面积云服务不可用，可紧急下线DIY烟花。
互动基建
互动组件
结合今年的业务背景，基本可以复用兔年五福建设的多人实时互动能力。今年五福应用整体升级为erverless架构，通过抽象互动底层逻辑，将该能力沉淀为基座组件应用在「烟花互动」板块。
用户进入烟花沉浸模式中，通过RTMS建立长链接实现client和server之间的实时通信。对单用户而言本质是加入了服务端创建的meeting。内存房间维护了用户的基本信息，同meeting内的用户也可以共享数据，用户退出或跳转出沉浸模式即退出房间。烟花互动的链路大致分为以下几个阶段，其中烟花播放内容、氛围弹幕都是由服务端通过RTMS定时向端上发送数据。
b. 实时在线人数统计
传统直播间一般会通过露出「累计观看人次」等数据反映主播或直播内容的吸引力，烟花沉浸模式也类似一个直播间。希望通过透出「在线人数」、滚动弹幕等内容带动更多用户参与并驻足停留，形成良好的活动氛围和用户粘性。
方案一：sls日志+blink实时计算
“sls日志+blink实时计算”是直播场景中较通用的统计方案。
- 延迟：由于业务上对数据的实时性要求高（秒级），该方案在大促场景中需要做降级处理，可能会带来一定的更新延迟；
- 成本高：较短的时间统计窗口对blink的计算资源有一定的要求
方案二：互动房间维度实时统计
我们互动组件提供的房间模式，天然存储了用户信息，通过单机上报房间内的在线人数，是可以汇总计算出总在线人数。基本流程如下：
- 秒级的单机调度任务，定时向DB写入当前机器IP、房间的总人数、更新时间等
- 维护一个全局任务，定时汇总DB中存储的总人数，并写入分布式缓存
- 单机查询缓存，获取全局人数【写缓存的过程开启了扩散写，每个RZone缓存数据都能得到更新】
- 通用性弱：和业务逻辑强耦合，需要业务定制化，不具备技术通用性。
风险：如果某台机器重启或者宕机，其记录在数据表中的人数信息其实是无效的，所以在汇总计算的步骤是需要限制「更新时间」，只选取特定时间范围内的数据。
c. 多级缓存方案
不管是在线人数的透出，还是烟花播放内容、氛围弹幕的推送，都是短时间内的数据刷新，对于数据读取的性能有极高的要求。因此业务链路上需要建立一道保护屏障，防止大流量涌入时出现查询节点阻塞、系统性能被拖垮等情况。我们采用「两级缓存+定时任务」方案解决此类数据实时刷新case，在保证查询性能的同时也保护了下游系统的稳定性。
实时提醒
烟花赠送/分享不仅可以作为用户情感表达的一种方式，也是玩法完成社交裂变的一种手段。赠送好友烟花的消息会通过端内CC消息和push通知到受赠方，但这两类消息的到达率受限。为了更流畅的用户体验，在烟花沉浸模式下的用户还会收到实时提醒（类似小红点通知）。「实时提醒」功能实现思路如下：
为满足业务需求，赠送烟花信息需要在赠送方和受赠方都落入一条记录。利用消息中间件实现跨zone插入受赠流水，同时消息本身的重试机制也保证了数据的最终一致性。用户join互动房间的过程中，会往分布式缓存（TBase）写入当前服务器信息，通过查询受赠用户是否有该条记录可以确定用户是否在烟花沉浸模式下。获取到服务器信息后，利用sofaRpc「点对点直连」能力请求到对应服务器向端上发送RTMS消息，完成实时提醒触达。
内容风控
DIY烟花在玩法上完全开发给用户创作，其内容传播范围广，需要建设一套公域内容安全的识别能力以规避潜在的涉黄、涉政等风险。我们协同内容安全团队，针对五福业务场景制定了「同步+异步」双阶段审核方案，「异步」兜底拦截漏掉的违规内容：
- 兑换烟花赠送/分享链路，内容传播范围较窄（仅受赠/分享方能查看），如果异步拦截会影响受赠方的产品体验，因此仅在同步安全策略上做严格管控，不做异步审核。
风险 & 应对
烟花互动可能存在的线上风险及应对方案梳理如下：
业务效果
在无特殊市场部宣传以及更多业务导流下，截止2024年02月08日17:00，福气之城上空一共绽放了1591万次代表祝福的烟花。
- 烟花互动完成率高达98%；
- 通过云渲染技术引入，实现了 99.99% 的设备覆盖率；
- 相比支付宝大盘，五福烟花的访问用户中，青壮年占了更大比例，吸引了更多的城市青壮年人群；
- DIY烟花设计初衷希望用户广泛参与，许下新年心愿。实际上线后，用户重复参与DIY烟花的意愿也随福卡数增加而增加，证明使用该功能的用户对这个功能的认可度较高。
结语
最后，福气之城互动玩法技术的落地，离不开各合作方的鼎力相助，非常感谢福气之城项目组每一位成员的辛苦付出，在此就不一一列出了！