玩法独立发、容器不发版：直播互动一体化方案复盘

这篇文章整理自一次直播互动玩法平台的一体化实践。为了方便公开分享，文中对公司名、内部系统名、域名、包名和业务数据都做了脱敏，内部专有系统统一用通用说法代替（构建系统 / 配置中心 / 变更管控 / 客户端网关 / 原生桥 等）。示例只用于说明思路，不代表任何线上实现。

先说说背景：玩法太多，容器太重

直播间里的互动玩法——红包雨、抽奖、优惠券、引导关注、商品弹窗——有个共同特点：多、杂、变得快。一到大促，玩法几乎天天有，而且经常要在直播、短视频、全屏等不同场景里复用。

如果按传统做法，把每个玩法都打进客户端、或者塞进一个大 H5 包里，很快就会很难受：

• 改一个玩法，要整个包重新发版、整体回归，互相阻塞。
• 直播是实时业务，线上一旦出问题影响面很大，发布必须能灰度、能回滚、能审计。
• 直播间还是个对性能很敏感的场景，要秒开、要按需加载，不能因为某个玩法体积大就拖慢整体。

我们想做的，不是再优化某一个玩法，而是把"生产玩法 — 构建物料 — 消费渲染"这三段拆开、各自独立，再用一套机制重新串成闭环。

这套方案想解决的一件事

如果只用一句话说清楚它在干嘛：

物料在独立仓里写、由 SDK 构建成 Module Federation 远程模块、在中台做中心化管控与灰度发布、经配置中心 + CDN 下发，最终在 Webview 容器里按需动态装载，由直播间实时消息驱动渲染。

落到工程上，它由三块拼图组成：

而真正想要的结果只有一个：容器和物料解耦——玩法独立开发、独立发布，不必联动容器发版。

三块拼图是怎么串起来的

可以顺着三条线去看它：物料从独立仓开发、SDK 构建、中台登记发布，是生命周期线；中台发布后双写配置中心和 CDN，是下发线；容器拉到清单后动态装载渲染，是运行时线。下面分别说这三块。

生产侧：中台怎么管、怎么发

中台是这套方案的"大脑"，基于 Serverless Node.js + MySQL，内部分成业务编排、能力集成、数据实体三层，结构上保持得比较克制。

领域上它分两条平行的轨：一条是可复用的物料，一条是玩法页（一个玩法页绑定多个物料，是前者的超集）。另外还维护一张共享库清单，记录哪些公共依赖走远程共享——这张清单是连接构建侧和运行侧的纽带，后面 SDK 构建时会反查它。

一个物料从创建到上线、再到下发，大致是这样：

这里有三个点是我们比较在意的：

• 生产发布要过审批闸门，留痕，不允许绕过。直播业务出事代价太大，这道闸门值得。
• 灰度不是简单开关，而是候选版本 + 比例 + 一份影子产物，可以定向、也可以秒回滚。
• 下发故意做成双写：配置中心负责实时，CDN 负责兜底。主通道万一抖了，容器还能从 CDN 拿到一份能用的清单，尽量不让直播间黑屏。

消费侧：容器怎么把物料装起来

容器跑在直播客户端的 Webview 里，技术上用了跨端 JSX 框架 + Webpack 的 Module Federation（容器作为宿主）。它最核心的，就是一条动态装载流水线：

几个当时觉得值得做的小设计：

• 运行时组合：容器拿到清单后，用 MF 在运行时把远程物料拉下来装载，结果走内存缓存，二次复用不再重复加载。
• 分级加载：关键玩法立即装载，非关键的延后一点、非阻塞地装，别拖慢首屏。
• 能降级：网关挂了就回退到一份内置兜底清单，容器尽量不空窗。
• 容器默认透明、手势穿透，只在真有玩法 UI 的时候才接管那块区域的手势，不挡用户和直播流的交互。
• 实时消息是互动的心跳：各物料先注册自己关心的消息，容器聚合后告诉客户端，客户端推下来再由容器按类型路由给对应物料。这里用了一个带缓存的事件总线，专门解决"消息比组件先到"的乱序问题。

物料 SDK：让一个物料能独立活着

SDK 是连接"独立仓开发"和"运行时装载"的那座桥，主要做三件事：

第一，把物料构建成远程模块。靠一个 Babel 插件，把命中共享库清单的依赖 import 改写成远程引用——这样全平台物料共享同一份公共依赖，单实例、包体也更小；再配合样式隔离，避免同页多个物料样式打架。

第二，自动发现共享依赖。构建时反查中台那张共享库清单，自己算出哪些依赖该走远程，不用开发者手动维护。

第三，也是体验上最关键的一点——本地模拟器。它用静态分析自动扫出物料声明了哪些消息处理，注入一个本地模拟器，让开发者不连真实直播间就能全链路联调。这件事看着不起眼，但很大程度上决定了这个平台到底有没有人愿意用。

物料独立仓本身只需要遵守很少的约定（声明一个唯一名、指定构建器、声明依赖），推代码就能触发构建、发布到 CDN，拥有自己完整独立的生命周期。

把它串起来：一次玩法从开发到上线

整条链路最关键的一点是：物料的发布（独立仓 → SDK → 中台 → CDN）和容器的发版完全分开。新增或更新一个玩法，只走中台发布，容器运行时自动拉到新清单装上，客户端和容器都不用重新发版。这正是一开始想要的那个结果。

它实际带来了什么

技术架构讲得再漂亮，最后还是要回到"它到底解决了什么业务问题"。这套方案上线后，比较明显的变化集中在几个方面（下面只说趋势，不代表任何具体指标）：

• 玩法上线变快了：以前一个新玩法要排进容器的发版节奏，现在物料独立发布、容器运行时自动装载，新玩法从开发完成到上线的周期明显缩短，大促期间多个玩法可以并行推进、互不阻塞。
• 发版风险降了：玩法改动不再牵动整个容器，加上灰度 + 审批 + 秒回滚，单个玩法出问题的影响面被控制在自己范围内，线上变更更可控、可审计。
• 复用率上去了：同一个物料声明好渠道就能在直播、短视频、全屏等多个场景复用，重复开发明显减少；公共依赖走远程共享后，单个物料的包体也更小、首屏更快。
• 研发门槛低了：本地模拟器让物料开发不再依赖真实直播间环境，新同学接入和日常联调的成本都降了下来，更多业务团队愿意自己接进来做玩法。

说白了，这套方案真正的价值不在某个技术点，而在于它把"玩法迭代速度"和"线上稳定性"这两个本来容易打架的目标，同时往前推了一步。

还不完美的地方

说实话，这套方案也远谈不上完美：

• 物料之间的依赖共享，强依赖那张共享库清单的维护，版本管理稍不留神就容易踩坑。
• 运行时动态装载多了，端上的性能和稳定性观测还需要做得更细，尤其是弱网下的兜底体验。
• 灰度目前更偏"比例 + 人群"，更精细的定向（比如按场景、按版本）还有空间。
• 本地模拟器虽然好用，但和真实直播间的差异，偶尔还是会漏掉一些边界问题。

这些都不影响它现在发挥价值，但确实是从"能用"走向"好用"还要继续填的坑。

我觉得可以带走的经验

抛开具体业务，这套东西的内核，对"平台 + 大量动态业务物料"的场景应该都通用：

• 当业务单元迭代远快于宿主时，用运行时组合把两者解耦，让业务单元独立发布，是规模化迭代的关键。
• "中心化管控"和"去中心化发布"并不矛盾：中台做治理，独立仓加 SDK 做生产，两边用清晰的协议对接就行。
• 下发链路要多留几条后路，实时通道、边缘兜底、本地兜底，任何一环挂了都别黑屏。
• 研发体验往往是平台能不能被用起来的隐形门槛，把联调成本压到接近零，比多写几个功能更值。

最后回头看

回过头看，这套一体化方案最有价值的地方，其实不是用了多新的技术，而是：

它把"玩法迭代"和"容器发版"这两件原本绑死的事彻底分开了。玩法可以自己快跑，容器可以稳着不动。

直播这种又快又怕出事的业务，最难的从来不是把功能做出来，而是让"快速上新"和"安全可控"同时成立。这套方案没有什么银弹，更多是把每一段都拆开、各自做扎实，再用一条能兜底的链路重新连起来。