寻找统一与定制的平衡点：我们直播间的五年演进之路

回头看我们直播间业务的发展，就像看着一个孩子长大——从最初的单一模式，到后来的"分家单干"，再到现在的"分久必合"，每一步都是摸着石头过河。

一、起步阶段：业务驱动的野蛮生长

记得五年前，我们只有一种直播间——那个被称为"三分屏"的固定模式。随着业务拓展，各个学科都提出了自己的需求：

"我们英语需要PK功能" "数学要有个填空卡" "语文需要朗读点评"

于是，小数直播间、小英直播间、小语直播间、IMC直播间相继诞生。每个学科都有自己的专属直播间，就像给每个孩子都准备了独立的房间。是的我们采用了典型的业务驱动架构模式。

当时的技术选择很直接：每个直播间独立开发，代码各写各的，项目、容器、域名全都分开申请。 好处是：改动不会互相影响，开发速度快，快速响应各业务特定需求。

现在回想起来，这种模式在业务从 0 到 1 的阶段确实帮了大忙。毕竟那时候，快速验证业务模式比代码优雅更重要。

二、成长的烦恼：重复造轮子的痛苦

随着业务发展，问题开始显现。最让我头疼的是那个"聊天区头像"功能。

产品经理说："所有直播间都要支持用户头像展示。"

于是，小数直播间开发一遍，小英直播间复制一份改改，小语直播间再来一次...同样的功能，我看着团队前前后后写了四遍。虽然每次都是复制粘贴，但总有些细微的调整：小数要支持勋章展示，小英要有个性化边框，小语要支持语音消息...

更让人崩溃的是：互动题功能每个直播间都要做, 每次新增业务都要重新申请资源, 修一个bug要在四个项目里分别修复

短期来看，这种模式确实影响面小、风险可控。但长期来看，团队陷入了"开发-复制-修改"的恶性循环。大家开始抱怨："我们不是在创新，我们是在重复劳动。"

重复开发问题凸显、资源开销已然不可忽视、代码碎片化严重、长期维护成本高昂。

三、统一之路：配置化平台的理想与现实

痛定思痛，我们开始推动统一化。核心理念是：从“按业务定义直播间”转向“按功能配置直播间”，通过配置化实现业务差异。

我们设计的配置体系包括： 直播/回放模式切换 拉流方式选择 学生区域展示内容（视频流、头像墙等）

功能模块组合配置 理想很美好：新业务只需要配一下就能上线，共同功能开发一次大家都能用。实际上，初期确实看到了效果——新业务上线速度从2周缩短到2天。

渐渐的，新的问题出现了。

四、统一后的新挑战：当简单变复杂

在数字化直播间。有个特殊需求：下课后时间依然在变。这个功能其他学科都用不到。

如果为了这一个需求在统一平台里增加配置，会让系统变得更复杂。 结果你猜怎么着？开发同学直接在配置平台的基础上，写了一段硬编码：

if (businessType === 'digital') {
  // 数字化特殊逻辑
  this.renderAttentionCurve();
}

这成了我们系统的"特权代码"。虽然违背了统一平台的初衷，但确实解决了当下的业务需求。

• 配置化本身的挑战也不小：
  • 配置复杂度爆炸： 配置项越来越多，新同学要看半天才能理解，有些配置之间还存在依赖关系，一不小心就掉坑里，新增配置需要考虑对现有业务影响。
  • 影响面控制难题：改一个配置可能影响所有业务，测试工作量巨大
  • 配置设计的平衡艺术：过度细化的配置增加了使用复杂度，需要找到合适的抽象层级
  • 功能组合的思考：相关功能是否应该打包成功能组合、配置开关需要适当收敛，避免碎片化

五、找到平衡：分层治理的实践

经过多次试错，我们逐渐找到了适合自己的平衡点——分层治理策略。

核心层（必须统一）：直播拉流、信令通信这些基础能力、安全规范和监控体系。就像房子的地基，必须牢固统一

业务层（配置化实现）：通过配置满足大部分业务差异；比如是否显示头像、是否支持回放。像房子的装修，可以通过不同风格满足需求

扩展层（允许定制）：真正特殊的业务需求通过插件化实现；比如数字化的注意力分析功能。像房子的扩展空间，需要时再加建

六、治理机制：让系统持续健康

光有架构不够，还需要配套的治理机制。

配置治理方面： 我们建立了配置项生命周期管理，每季度回顾一次配置项的使用情况。发现有些配置项从来没人用过，就果断下线。

代码治理方面： 我们设置了代码重复度检测，定期重构消除重复。对于业务特定的代码，要求必须有明确的升级路径。

组织架构调整： 我们成立了平台团队负责核心架构，业务团队基于平台能力快速迭代。这种模式既保证了技术底座的稳定，又给了业务创新的空间。

七、写在最后：平衡的艺术

五年过去了，我深深体会到：没有一劳永逸的解决方案，只有持续演进和优化的过程。在统一和定制之间找平衡，就像走钢丝——太偏向统一，会扼杀业务创新；太偏向定制，会导致系统腐化。 架构的本质就是在不断变化的业务需求和技术环境中，找到最适合当前阶段的平衡点。

我们的经验教训：

没有银弹：不要追求完美的解决方案，适合当前阶段的才是最好的 保持敏感：要能感知到什么时候该统一，什么时候该放开 建立机制：比单次决策更重要的是建立持续优化的机制

现在，当新的业务需求过来时，我们会先问三个问题： 这个需求是暂时的还是长期的？ 其他业务未来会有类似需求吗？ 通过配置还是扩展来实现更合适？

这种思维方式的转变，或许比任何技术方案都更有价值。

回头看，这一路的磕磕绊绊都是宝贵的财富。最好的平衡不是消灭张力，而是学会驾驭张力，让统一和定制这对看似矛盾的力量，共同推动系统向前发展。

毕竟，架构的本质就是在不断变化的环境中，找到那个最适合当下的平衡点。而这，正是软件工程最迷人的地方。