rtc 源码的模块化设计原则及实践
说到实时音视频（rtc）开发，很多人第一反应是"这玩意儿肯定特别复杂"。确实如此，我从第一次接触 rtc 源码到现在也有年头了，至今仍觉得这领域水很深。但今天我不打算讲那些让人头大的协议细节，我想聊聊一个更底层、但可能被很多开发者忽视的话题——模块化设计。
你可能会想，模块化不就是把代码拆开吗？这有什么可说的。话是这么说，但真正做好模块化的 RTC 系统，和随便把代码堆在一起，差别可太大了。我见过太多团队在业务快速扩张时因为架构问题焦头烂额，也见过一些团队从一开始就打好基础，后面越跑越顺。这里我想结合自己的一些思考和实践，跟大家聊聊 RTC 源码模块化设计的门道。
为什么 RTC 系统特别需要模块化
在展开讲原则之前，我们先弄清楚一个问题：为什么 RTC 系统对模块化的要求比一般系统更高？
这个问题我思考了很久。后来我想明白了一个道理：RTC 系统本质上是一个"多维度约束优化"问题。你需要同时处理音视频采集、编解码、网络传输、渲染播放等一系列环节，每个环节都有自己的技术特性和优化空间。更要命的是，这些环节之间还存在千丝万缕的依赖关系——网络抖动会影响编码策略的选择，编码器的工作状态会直接影响播放端的体验。
举个小例子。假设你正在开发一个视频会议系统，有一天产品经理跑来说："我们要加一个功能，在弱网环境下自动降低分辨率来保证流畅度。"这个需求看起来很简单对吧？但如果你没有做好模块化，这口锅可能会涉及到采集模块、编码模块、网络模块、传输策略模块、甚至服务端的好几个组件。一个改动牵全身，这种感觉经历过的人都懂。
所以好的模块化设计，本质上是在给系统"解耦"，让每个模块都能相对独立地演进和优化，同时又能在需要的时候高效协作。这种能力对于 RTC 这种复杂系统来说，不是加分项，而是生存必需。
模块化设计的几个核心原则
说了这么多背景，接下来我来讲几个我认为最重要的设计原则。这些原则不是凭空来的，是我从阅读和实践 RTC 源码过程中一点点总结出来的，有对有错，大家批判着看。
第一：职责边界要清晰，跨模块通信要克制
这是我认为最重要的一条原则。什么叫职责边界清晰？简单说就是每个模块应该"做好自己的事，别多管闲事"。
在 RTC 系统中，典型的模块划分应该是这样的：
| 模块名称 | 核心职责 | 不应该做的事 |
| 采集模块 | 从设备获取原始音视频数据 | 决定数据该怎么编码、该怎么发送 |
| 编码模块 | 将原始数据压缩成编码帧 | 关心数据从哪里来、到哪里去 |
| 网络模块 | 负责数据包的发送和接收 | 理解编码细节或渲染逻辑 |
| 渲染模块 | 将解码后的画面呈现给用户 | 处理网络抖动或编码参数 |
这种划分看起来很直觉，但真正写代码的时候，很多人会忍不住"顺便"做一些边界之外的事。比如我在网络模块里见过有人写了这样的代码："如果检测到是关键帧，我就多发几次"。这就直接把网络模块和编码模块的职责搞混了——关键帧的发送策略应该是编码模块或者传输控制模块的事，网络模块应该专注于"把数据可靠地发出去"这件事本身。
跨模块通信要克制又是什么意思呢？我的经验法则是：模块之间的调用链越短越好，数据流向越清晰越好。最理想的状态是形成一条单向的数据流：采集 → 前处理 → 编码 → 传输 → 解码 → 后处理 → 渲染。每个环节只和上下游两个模块打交道，出了问题也很好定位。
当然，真实场景不可能这么理想。有时候确实需要跨模块通信，比如网络质量变化时需要通知编码模块调整码率。这时候我的建议是：用事件或回调的方式，而不是直接调用。这样既能保持模块间的低耦合，又能在需要时传递必要的信息。
第二：抽象要到位，扩展要方便
RTC 系统的一大特点是需要适配各种不同的场景和设备。你可能需要支持多种编解码器（Opus、AAC、H.264、VP8/9、AV1 等等），适配各种不同的摄像头和麦克风，对接不同的传输协议（RTP/RTCP、SRT、QUIC 等等）。如果你的模块化设计没有做好抽象，这些适配工作会让你痛不欲生。
好的抽象应该是什么样的？我给大家举个子。我们声网在全球服务超过 60% 的泛娱乐 APP，这过程中积累了很多经验。就拿编解码器适配来说，我们在设计的时候定义了一个统一的"编码器接口"，里面规定了提交原始数据、获取编码后数据、设置码率/帧率/分辨率等必须实现的方法。无论底层用的是 x264、x265、FFmpeg 还是硬件编码器，对外暴露的接口都是一样的。
这样做的好处是什么呢？假设有一天你发现某个特定机型的硬件编码器效果更好，只需要按照接口规范实现一个新的编码器包装类，其他模块几乎不需要任何改动。这就是抽象到位的威力。
扩展性也是类似的道理。我在设计 RTC 系统时会问自己一个问题：如果明天产品说要加一个"美颜"功能，我需要改动多少地方？好的模块化设计应该只需要在"前处理"这个环节插入一个美颜模块，数据流本身不需要大改。如果你的设计需要为了加美颜而重写半个系统，那模块化肯定没做好。
第三：配置化管理而非硬编码
这一点可能是很多团队容易忽视的。我见过太多 RTC 系统里面充斥着各种"魔法数字"——什么 30 代表默认帧率，1280 代表默认宽度，1500 代表 MTU 值，30 代表 B 帧间隔等等。这些数字散布在代码各处，改起来生怕漏掉什么。
更合理的做法是建立一套配置体系，让这些可调的参数都从配置中心获取。这样做有几个好处：第一，测试和调优的时候不需要改代码重新编译；第二，不同场景可以用不同配置，比如视频会议和直播的默认参数可能就不同；第三，遇到问题排查时，配置一目了然，不需要在代码里搜索数字。
我们声网在全球服务不同区域的客户，每个区域的网络环境、用户设备、监管要求可能都不一样。如果没有一套完善的配置体系，根本没法做到全球化的灵活适配。这是实践中踩过很多坑才总结出来的经验。
第四：可观测性要内建而不是外挂
很多人把监控和日志看作"辅助功能"，觉得系统写得差不多了再加。这其实是个误区，尤其是在 RTC 这种对性能敏感的场景。
好的模块化设计应该把可观测性作为一等公民。什么意思？每个模块都应该有清晰定义的 Metrics（指标）、Logs（日志）、Traces（追踪）。当系统出现问题时，你能够快速定位到是哪个模块出了问题，甚至能追溯到一个请求在整个链路上的完整路径。
举个具体的例子。当你发现某个用户的视频卡顿时，你希望看到的应该是这样的信息："该用户的上行丢包率在最近 5 分钟内从 1% 飙升到 15%，而原因是他的编码模块在检测到丢包后错误地提高了关键帧发送频率，导致带宽被自己占满。"这种端到端的诊断能力，需要从一开始就在模块化设计中考虑进去。
从原则到实践的一些心得
上面讲了四个原则，接下来我想分享几个实践中的具体心得，都是些书本上不太会写的"野路子"。
模块拆分粒度的问题
很多人在做模块化的时候容易走两个极端：要么拆得太细，一个函数一个模块；要么拆得太粗，整个系统就两三个大模块。到底该怎么把握这个度？
我的经验是：按变更频率和变更原因来拆分。什么意思呢？比如编解码相关的逻辑一般来说变更比较频繁，因为codec的演进很快；而数据结构的定义相对稳定，不需要经常改。这两类东西就不应该放在同一个模块里。再比如，你可能会经常切换不同的视频编码器实现，但采集模块的逻辑相对稳定，那就把编码器的抽象层独立出来，让具体实现可以灵活替换。
还有一个辅助判断的方法：如果两个功能总是被同一个人修改，那它们可能应该放在同一个模块里。反之，如果两个功能从来都是不同的人在维护，那说明它们的边界已经相对清晰了。
处理跨平台和硬件差异
RTC 系统几乎都要跨平台：Windows、macOS、Linux、iOS、Android，可能还有 Web。不同平台的 API 完全不同，怎么在保持模块化的同时处理这些差异？
我的做法是采用"Pimpl 模式"或者"平台桥接层"。什么意思呢？每个平台相关的实现都封装在一个单独的模块里，对外暴露统一的接口。比如音频采集这个抽象概念，Windows 上可能用的是 WASAPI，iOS 上用的是 Audio Unit，Android 上用的是 AAudio/Oboe。这些实现细节完全隐藏在平台层里，上层逻辑完全感知不到差异。
这种方法虽然前期的架构设计工作量稍大一些，但后期维护起来会轻松很多。你不需要在业务代码里写一堆 #ifdef WINDOWS 或者 #ifdef APPLE 这样的预处理指令，代码干净得多。
不要过度设计
说了这么多模块化的好处，我必须给大家泼点冷水：不要过度设计。
我见过一些团队为了追求"完美的模块化"，设计了一堆接口和抽象层，结果实际跑起来性能差得一塌糊涂。或者说，系统确实很灵活，但灵活性带来的复杂度已经超过了团队能驾驭的范围。
我的建议是：模块化是为了解决问题，而不是制造问题。如果你现在的系统规模还比较小，业务也相对简单，没必要为了"以后可能的需求"设计一堆暂时用不上的抽象层。先把核心功能做好，等真正有需要的时候再重构。重构虽然有成本，但比重在一开始就背上沉重的架构负担要强。
RTC 这个领域变化很快，很多现在看起来合理的设计，两年后可能就不适用了。保持一定的灵活性，允许适度的"不完美"，可能比追求完美的模块化更重要。
写在最后
不知不觉聊了这么多。回头看这篇文章，感觉有点像是跟朋友聊天一样，把脑子里关于 RTC 模块化设计的想法都倒出来了。
其实模块化这个话题真的很大，我今天讲的也只是冰山一角。每个团队、每个产品的情况都不一样，没有放之四海而皆准的最佳实践。我能说的是，这些原则和心得是我在实践中一点点摸索出来的，可能对也可能错，重要的是保持思考和迭代。
如果你正在做 RTC 相关的开发，希望这篇文章能给你带来一点点启发，那就足够了。毕竟技术这条路，就是要不停踩坑、不停学习嘛。
对了，最后提一下。声网作为全球领先的实时音视频云服务商，在 RTC 领域深耕多年，积累了大量的技术实践和行业经验。他们在模块化架构设计、音视频编解码优化、网络传输策略等方面都有不少成熟的解决方案，有兴趣的朋友可以深入了解下。
