实时音视频这一行，有个挺有意思的现象：刚入行的人觉得它难在“怎么把画面传过去”，做了两三年的人觉得它难在“怎么在弱网下传得稳”，真正扛过线上大流量的人才会意识到，最难的其实是“怎么让服务器扛住”。这三层认知，分别对应三种技术架构——Mesh、MCU、SFU。而 Colibri（蜂鸟）这个名字，正是奔着第三层去的。它是一只很“轻”的鸟，项目本身也追求轻：把传统 SFU 里最重的那个包袱——服务器的“状态”——直接卸掉。我第一次看到这个设计时的第一反应是“这不可能”：一个 SFU 要是没有房间、没有轨道映射关系，媒体往哪转？看完它的思路才明白，它不是不要状态，而是把状态挪到了一个更合适的地方。这篇就聊聊 Colibri 这个开源 SFU 项目，拆清楚它解决的问题、背后的架构取舍、能落地的最小实现，以及我在实际接触边缘媒体转发时踩过的那些坑。不管你是刚接触 WebRTC 的开发者，还是正在给产品选实时音视频方案的技术负责人，应该都能从中拿到点能直接用的东西。

1. Colibri 到底站在实时音视频的哪个位置

1.1 三种架构：Mesh、MCU、SFU 怎么选

聊任何 SFU 之前，得先把三条路线摆清楚，不然讨论没有坐标系。Mesh 是最朴素的做法：每个参与者和房间里其他所有人各建一条连接，自己发自己的，也自己收所有人的。好处是服务器几乎不参与媒体处理，架构最简单，成本最低。坏处也很直白——上传带宽随人数线性甚至超线性增长。一个 6 人房间，你一个人就要上传 5 路、下载 5 路，手机端直接烧起来。所以 Mesh 只适合 2 到 3 人的小场景，比如一对一客服、双人远程协作。

MCU 走的是另一个极端：所有人都把流发给服务器，服务器把画面合成一路（混流）再下发给每个人。客户端的压力小，带宽也省，因为它只收一路。但代价全压在服务器上——解码、缩放、合成、编码，每一步都是实打实的 CPU/GPU 开销，人数一多，服务器成本是爆炸式增长。而且混流之后画面是“死”的，你想单独放大某个人、想切换成只看某个人的视图，都做不了，因为服务器只给了你一张拼好的图。MCU 常见于传统电话会议和直播连麦，胜在终端兼容性好。

SFU 是这两者之间的折中，也是现在主流实时音视频产品的选择。它的核心原则只有一句话： 只转发，不混流 。每个人上传一路（或几路分层流），服务器根据订阅关系，把对应的流原样转发给需要的人。服务器不做解码、不做合成，只做“选路和搬运”。这样一来，上传成本是每人 1 路，服务器带宽随人数温和增长，客户端拿到的还是独立的流，可以自由布局。代价是下行带宽比 MCU 高一些，因为客户端要同时收多路。但对今天的网络环境来说，这个代价完全可以接受。

架构	服务器压力	客户端上行	客户端下行	灵活布局	适用规模
Mesh	极低	随人数线性增长	随人数线性增长	天然支持	2~3 人
MCU	极高（编解码混流）	1 路	1 路	不支持	中小型会议
SFU	低（只转发）	1 路或数层	随订阅数增长	支持	中大型、直播连麦

理解了这张表，后面 Colibri 的所有设计就都能对号入座了——它属于 SFU，但又不是传统意义上的 SFU。

1.2 传统 SFU 的“状态包袱”有多重

传统 SFU 的实现，无论是用 Go 写的 Pion、用 C++ 写的 mediasoup，还是其他同类项目，本质上都是一个 长驻进程 。这个进程里维护着房间对象、参与者对象、每一条 RTP 流的解析状态、序列号映射、抖动缓冲、NACK 重传队列……一整套东西都在内存里。这意味着什么？意味着一个房间里的所有参与者，必须连接到 同一台服务器、同一个进程 上。

这个约束带来的连锁反应，做过线上服务的人应该很熟悉。第一，扩容不能随便扩。你没法简单加机器，因为加进去的新机器上没有房间的状态，用户连上去就是空白。你得做“房间亲和”路由，保证同一个房间的人始终落在同一台机器上。第二，故障恢复很麻烦。那台机器一挂，上面所有房间的状态全丢，用户要么重连重建，要么直接掉线。第三，资源利用率难做高。热门房间把某台机器打满，冷门房间的机器却闲着，负载天生不均衡，还得额外做调度。

从工程角度看，这些都不是不能解决，而是要花大量精力去解决。粘性路由、状态快照、房间迁移、优雅重启……每一样都是复杂度。Colibri 的切入点很聪明：它没有去优化这个“有状态”的模型，而是直接问了一句—— 这个状态，真的必须待在媒体转发的进程里吗？

1.3 Colibri 的答案：把状态和媒体拆开

Colibri 给出的答案是把 SFU 拆成两层：一层负责 状态 ，一层负责 媒体转发 。状态层放在一个专门存储房间和订阅关系的地方，媒体层则做成尽量无逻辑的“搬运工”。这样一来，媒体层就不再需要知道自己服务于哪个房间的长期状态，它只要拿到“把 A 的这路流转发给 B”的指令，干完活就行。任务结束，进程可以随时回收，下次换个节点重建也没关系。

这个拆分带来的最大好处是 弹性 。因为媒体转发节点不再持有房间的长生命周期状态，它就可以像无服务器函数一样被随意调度、按需拉起、用完即弃。用户离得近的边缘节点可以就近承接媒体流，转发完就释放。容量规划从“给固定房间预留机器”变成了“为并发流按需分配算力”，整个成本模型都不一样了。

当然，天下没有免费的午餐。拆开之后，媒体层每次转发都要去状态层取一次“谁该发给谁”的映射，这就引入了额外的调用和延迟。Colibri 所做的，是把这套查询做得足够轻、足够快，让额外的开销低于它省下来的调度成本。这个权衡能不能成立，取决于状态层的性能和边缘网络的密度——这也正是它设计里最值得琢磨的部分。

2. 架构拆解：无状态 SFU 是怎么跑起来的

2.1 状态层：谁记住“房间里有哪些人”

既然媒体层不记状态，那状态就得有个归宿。Colibri 用的是一个 带持久化能力的对象存储模型 （可以理解成“一个房间对应一个独立的小服务实例”）。每个房间有一个对应的对象，参与者加入、发布轨道、订阅轨道这些操作，都是对这个对象的调用。对象内部维护着房间成员列表、每个人的轨道 ID、谁订阅了谁这些信息。

这个设计有几个细节值得注意。第一，房间对象是 按房间隔离 的，两个房间的状态互不干扰，一个房间的操作不会阻塞另一个房间。第二，对象本身是单点串行的——同一个房间的所有状态变更都经过它，这保证了订阅关系不会出现竞态。听起来像瓶颈，但状态操作本身很轻，一次加入或订阅就是几次内存操作加持久化，单房间的并发量远不到瓶颈的程度。真正重的是媒体流，而那个已经被挪走了。

第三，也是最重要的一点：媒体层不需要长期持有房间对象。当参与者 A 要发流给 B 时，媒体节点向房间对象确认“B 在当前订阅列表里、订阅的就是 A 这路”，拿到确认后就开始转发。转发过程中，如果 B 取消了订阅，房间对象会通知媒体节点停止。 状态是查询来的，不是缓存一辈子的 ，这样即使媒体节点中途重启，重连后重新查询一次就能恢复转发关系。

注意：无状态不等于没有状态，而是状态不绑定在转发进程上。设计时要时刻分清“哪些信息必须持久”“哪些信息用完即弃”，混淆这两类会直接把架构带回有状态的老路。

2.2 媒体层：WASM 让转发逻辑跟着用户走

媒体层是 Colibri 最有意思的地方。它把 SFU 的转发逻辑——接收 RTP、解析头部、按订阅关系改写序列号和 SSRC、再发出去——编译成了 WebAssembly 模块 ，运行在边缘计算平台的运行时里。这个选择的直接后果是：媒体处理逻辑不再需要一个常驻的操作系统进程，而是随请求拉起、随请求销毁。

为什么这很关键？因为它把“部署一个 SFU”这件事的门槛降到了和“部署一个边缘函数”差不多。传统 SFU 你得准备服务器、配网卡、开 UDP 端口、做进程守护，还要考虑 RTP 走的端口范围。而 WASM 跑在边缘运行时里，扩展和调度由平台负责，你只需要提交代码。对于中小团队来说，这意味着不用再维护一套专门的媒体服务器运维体系。

当然，WASM 也有它的约束。它对网络 I/O 的访问是受限的，UDP 收发需要运行时提供专门的能力；它的内存模型和传统的 C 进程也不完全一样。所以 Colibri 的核心转发逻辑虽然是 C，但外面裹了一层与运行时对接的胶水层。 把性能敏感的部分用 C 写，把调度和 I/O 交给平台 ，这个分工是它能跑通的前提。

2.3 为什么选 C 而不是 Go 或 Rust

很多同类的 SFU 用 Go 或 Rust 写，Colibri 的核心却选了 C，这一点经常被讨论。原因其实很实际。第一是 性能可预测 。媒体转发是典型的“每包都要做一点点事”的场景，一秒几万个包，每次都是定长的头部解析和拷贝，这种场景下 C 的零抽象开销很有优势，没有运行时 GC 的停顿，延迟抖动更小。第二是 可移植性 。C 编译成 WASM 的成熟度是所有语言里最高的，工具链稳定，产物体积小，启动快。第三是 依赖少 。一个 SFU 核心如果依赖一大堆运行时特性，塞进 WASM 沙箱里就会变得处处受限，纯 C 加上少量标准库，反而最容易塞进去。

当然，选 C 意味着内存安全和并发模型都要自己扛，开发效率也低。所以 Colibri 的做法是把 C 限定在“媒体转发内核”这个小范围内，房间管理、信令、API 这些外围逻辑用更适合的语言去写。 核心窄、边界清 ，是这种“多语言混搭”方案能成立的关键。如果你的团队没有 C 的积累，完全可以用 Rust 或 Go 实现同样的思路，牺牲一点包处理性能换取开发效率，架构本身不受影响。

2.4 一次完整的发布-订阅链路

把上面的模块串起来，一次完整的链路大致是这样走通的。参与者 A 要和 B 建立音视频，先各自和信令端点建立连接，携带房间标识。信令端点在状态层为这个房间找到（或创建）对应的房间对象，把 A、B 注册进去。接着 A 发起“发布”，告诉房间对象“我要发一路视频”，房间对象记录一条轨道信息，并返回一个用于媒体上传的地址。

A 拿到地址后，和对应的边缘媒体节点建立连接，开始推流。媒体节点收到 A 的 RTP 包，向房间对象查询“当前有哪些人订阅了 A 的这路流”，得到 B 的标识。随后媒体节点把 A 的流按 B 的订阅参数（比如指定要哪一层的 Simulcast）改写后转发给 B。B 这边同样有自己的媒体下行连接。整个过程中，媒体节点只做“查关系、改包、转发”，房间的长生命周期信息始终在状态层。

如果 B 中途离开，状态层更新订阅列表并通知媒体节点停止向 B 转发；如果 A 断线重连，媒体节点重新向状态层查询一次，就能恢复转发。 链路里的每一步都是可重建的 ，这正是“无状态媒体层”带来的最大工程红利——任何一环挂掉，都不至于把整个房间拖垮。

3. 关键实现细节：转发、带宽、编码这三件事

3.1 Selective Forwarding 的取舍：绝不混流

SFU 的名字里那个 S 是 Selective，意思是“有选择地转发”。这个“选择”体现在两个层面。一是 选择转发对象 ：只发给订阅了这路流的人，不订阅就不发，省带宽。二是 选择转发内容 ：同一路视频如果发了多个质量层，可以根据订阅者当前的网络状况只转发其中某一层。这两个选择都是“转发”，而不是“处理”——服务器不理解画面内容，也不重新编码，它只是根据订阅关系和网络反馈，决定“搬哪一包、搬给谁”。

坚持不混流，好处是延迟低、画质不被二次压缩、终端布局自由；代价是下行带宽更高，且客户端要自己处理多路流的同步（多路音频对齐、音视频对齐）。Colibri 在这个取舍上毫不含糊，因为一旦引入混流，服务器就得解码和重编码，那它“轻、无状态、可弹性伸缩”的全部优势就都没了。所以它宁可把同步和布局的复杂度交给客户端，也要保住服务端的轻量。这个取舍值得所有做 SFU 的人想清楚： 你省下的服务端成本，最终会以某种形式转移到客户端 ，关键看哪一端更容易承受。

3.2 拥塞控制：SFU 场景下最容易被忽视的一环

很多人做 SFU 时只关心“能不能转发”，却忽略了“转发得稳不稳”。媒体转发链路上，服务器并不解码，它怎么知道对方的网络好不好？靠的是 RTCP 反馈和带宽估计 。接收端会定期上报丢包、延迟、抖动信息，发送端据此调整码率。在 SFU 场景下，这条反馈链被拉长了：接收端上报给 SFU，SFU 需要把反馈转回给真正的发送端，或者由 SFU 自己做一层带宽估计，决定给这个接收端转发哪一层质量。

这一步如果没做好，典型症状是：弱网用户画面卡住但码率不降，因为发送端根本不知道接收端不行了。Colibri 的处理思路是在转发层做 轻量的反馈汇聚 ，把接收端的网络状况和订阅的质量层关联起来，动态切换转发哪一层。切换时要注意层与层之间的关键帧对齐，否则用户会看到一段花屏或者黑屏。实操中一个很有效的技巧是： 只有在关键帧到达时才切层 ，平时先把收到的目标层帧缓存住，等关键帧再切，这样切换可以做到几乎无感。

提示：带宽估计不是“估得越准越好”，而是“估得越稳越好”。频繁剧烈地切换质量层，用户的观感比一直停在低清还差。给码率调整加一点迟滞（hysteresis），比追求瞬时最优更实用。

3.3 Simulcast 与 SVC：让不同网络的人各取所需

要让不同网络状况的用户都看得舒服，SFU 依赖两个技术：Simulcast 和 SVC。Simulcast 是发送端同时发多个独立质量层（比如 720p、360p、180p），每一层是一个完整的编码流。SFU 按订阅者情况，给网络好的人转 720p，给差的人转 180p。它的优点是兼容性好，实现相对简单；缺点是发送端要编码多路，上行带宽和 CPU 占用都更高。

SVC（可伸缩视频编码）则是发一路“分层”的流，基础层加若干增强层，按需丢弃增强层就能降质量。它的优点是发送端只编码一路，上行更省；缺点是编码复杂度高、设备支持参差，跨浏览器兼容性需要仔细测试。Colibri 这类 SFU 通常两者都支持，具体用哪个，取决于你的终端类型和浏览器版本覆盖。

不管用哪种，SFU 这边要维护的是 一条“质量层映射” ：哪个订阅者当前对应哪一层。这张表要随 RTCP 反馈动态更新，还要处理层切换时的关键帧等待，以及订阅者数量变化时的带宽重算。这几件事听起来琐碎，但恰恰是 SFU 从“能跑”到“能上线”的分水岭。

方案	发送端编码路数	上行带宽	兼容性	降质量粒度
Simulcast	多路（3 路常见）	高	好	粗（整层切换）
SVC	1 路	低	参差	细（逐层丢弃）

3.4 信令与 ICE 的衔接方式

媒体能不能连通，信令和 ICE 是绕不过去的。WebRTC 的媒体连接建立，需要交换 SDP 和 ICE 候选，这个过程在 SFU 场景下要复杂一些，因为 SFU 处在两端之间，它自己也要参与协商。参与者不是直接和另一个参与者协商，而是分别和 SFU 协商，SFU 相当于一个“媒体代理”。这就意味着 SFU 要能解析和改写 SDP，把发送端的能力、接收端的能力、自身的能力求交集。

ICE 这边，SFU 需要暴露可被公网访问的连接地址，并处理候选收集。在边缘部署的场景下，SFU 节点很多，给每个节点分配公网地址和端口是件麻烦事，通常的做法是通过中继或者 TURN 类组件来收敛地址，或者利用平台的网络能力把媒体引入到边缘运行时。这部分是整个方案里最“脏”的地方，涉及网络配置、NAT 穿透、端口管理，实际落地时一定要留足测试时间。

注意：信令和媒体最好走不同的通道。信令用 WebSocket 或 HTTPS，媒体走低延迟通道。把信令塞进媒体通道，会导致重连和状态同步变得极其混乱，排查问题时无从下手。

4. 动手跑通一个最小 Demo

4.1 环境与依赖准备

要自己验证 Colibri 的思路，不一定非得从零编译它的全部代码，更实际的做法是先跑通一个“房间状态 + 媒体转发”的最小闭环。所需的环境大致是：一个能跑边缘函数或轻量服务的运行时、一个支持 UDP 或等效低延迟通道的媒体收发环境、一个浏览器用来做收发端。如果你用的是 Colibri 官方提供的能力，通常是通过它的 API 来创建会话和轨道，而不是自己从头搭媒体节点。

前置检查清单如下，这几项漏一项都会导致后面卡住：

• 确认运行时支持所需的网络访问能力，尤其是媒体收发用到的通道类型。
• 确认浏览器端支持你打算使用的编码格式，用 RTCRtpSender.getCapabilities 查一遍。
• 准备一个能稳定访问的信令端点，本地开发可以用简单 HTTP 服务。
• 准备好日志采集，媒体问题没有日志基本等于盲调。

如果你打算自己编译核心模块，通常是一条类似下面的流程，具体命令以项目文档为准：

# 拉取源码
git clone <colibri-repo-url> colibri
cd colibri

# 检查 WASM 工具链
which clang
clang --version

# 按项目提供的脚本编译核心为 WASM 产物
make build-wasm

# 部署到边缘运行时（示意，命令以平台为准）
make deploy

编译环节最常见的坑是工具链版本不匹配。C 编译到 WASM 对 clang 和 sysroot 的版本有要求，版本差一点就可能报一堆找不到符号的错误。 先用项目里锁定的版本，别急着升级到最新。

4.2 建房间、发流、收流的三段式流程

整个接入流程可以概括成三段：建房间、发流、收流。下面给出的是概念性示意，具体字段和接口以你使用的实现为准。

第一段，创建会话并加入房间。核心是把参与者和房间绑定，并拿到后续操作的凭据：

// 示意：创建会话并加入房间
async function joinRoom(roomId, userToken) {
  const res = await fetch(`/api/rooms/${roomId}/join`, {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${userToken}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({ displayName: 'demo-user' })
  });
  const session = await res.json();
  // session 里通常包含: 参与者 id、房间内其他参与者、可用的发布/订阅地址
  return session;
}

第二段，发布本地轨道。拿到会话后，把本地的摄像头、麦克风轨道发布上去，通常会得到一个用于媒体上传的连接信息：

// 示意：发布本地音视频轨道
async function publishTracks(session, localStream) {
  const published = [];
  for (const track of localStream.getTracks()) {
    const res = await fetch(`/api/sessions/${session.id}/tracks`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        kind: track.kind,           // 'audio' | 'video'
        // 若使用 Simulcast，这里可能要声明多个质量层
        layers: track.kind === 'video'
          ? [{ width: 1280, height: 720 }, { width: 640, height: 360 }]
          : undefined
      })
    });
    const info = await res.json();
    published.push({ track, info });
  }
  return published;
}

第三段，订阅远端轨道。其他参与者发布后，状态层里会出现新的轨道，你订阅它，媒体节点就会开始给你转发：

// 示意：订阅远端轨道
async function subscribe(session, remoteTrackId) {
  const res = await fetch(`/api/sessions/${session.id}/subscriptions`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      trackId: remoteTrackId,
      // 指定初始期望的质量层，后续由带宽反馈动态调整
      preferredLayer: 'medium'
    })
  });
  return res.json();
}

这三段走完，理论上就已经有一条端到端的媒体链路在跑了。但“理论上”这三个字要打个引号——实际能不能通，取决于信令、ICE、编码协商每一环都对齐。不要一次性把所有功能都加上去， 先跑通一路音频，再加一路视频，最后再加 Simulcast ，出问题也容易定位。

4.3 本地验证与延迟观测

验证链路是否真的通了，不能只看“界面显示了画面”，得看数据。建议在客户端打开 WebRTC 的内部统计，重点看几个指标： packetsLost （丢包数）、 jitter （抖动）、 roundTripTime （往返延迟）、 framesPerSecond （帧率）、 bytesReceived （接收字节数）。如果画面显示但 bytesReceived 长时间不增长，那多半是卡在一帧上没动，问题出在转发或解码链路。

延迟观测要区分几个概念：端到端延迟（采集到播放）、网络往返延迟（RTT）、抖动缓冲带来的延迟。SFU 转发本身引入的延迟主要来自网络路径和转发处理，处理延迟通常很小，大头在网络。如果你测到端到端延迟很高，先看是不是走了很绕的路径，再看抖动缓冲是不是设得太大。 很多“延迟高”的锅其实是抖动缓冲背的 ，而不是 SFU 慢。

一个实用的本地验证方法：在一端放一个计时器（显示毫秒数），另一端对着屏幕拍，用画面里两个时间差估算端到端延迟。这个方法粗糙，但能快速判断延迟是几十毫秒还是几百毫秒量级，比看统计值更直观。

5. 踩坑实录：这些问题我几乎每次都遇到

5.1 常见问题速查表

下面这张表是我在实际调试实时媒体链路时最常撞上的问题，整理出来方便对照排查。

现象	可能原因	排查方向
能连上但无画面	轨道没发布成功，或订阅关系没建立	查状态层里轨道和订阅记录是否都存在
画面卡在首帧	缺少关键帧，或层切换时未等待关键帧	查是否收到了 IDR 帧，检查切层逻辑
偶发花屏几秒	层切换或重传时的序列号/SSRC 改写有误	检查转发时 RTP 头部的改写是否连续
一方听得到一方听不到	单向链路问题，多半在 ICE 或端口	分别测试上下行，查候选地址是否可达
弱网用户画面糊但码率不降	RTCP 反馈没回传或带宽估计未生效	查反馈链路，确认层切换被触发
重连后画面不同步	音视频走了不同质量层	检查音视频订阅参数是否一致
转发节点重启后整个房间掉线	媒体层误缓存了长生命周期状态	确认状态只在状态层，媒体层重新查询即可恢复

这张表里的每一行，背后往往都是一次“看着简单、调起来要命”的经历。尤其是“偶尔花屏几秒”这种问题，它的触发条件很随机，可能只在特定网络抖动下出现，抓包和分析的成本很高。我的经验是： 给转发层加足够细的日志，把序列号、SSRC、时间戳的改写都记下来 ，出问题时对着日志比对，比盲目抓包快得多。

5.2 几条不太写在文档里的经验

第一条，别迷信“无状态就一定好”。无状态架构在弹性和容错上确实强，但它把复杂度转移到了状态层的调用频次和一致性上。如果状态层成为热点，或者每次转发都要等一次状态查询，那整体的延迟反而会上升。 评估时一定要把状态查询的开销算进去 ，用真实的并发量去压一压，别只看架构图漂亮就上。

第二条，媒体问题八成不是代码问题，是网络问题。我见过太多人把大量时间花在调代码上，最后发现是候选地址配错了、某个端口不通、或者路径绕了大半个网络。 遇到媒体不通，先抓包看 ICE 是否完成、候选是否配对、RTP 是否真的发出来了 ，确认是网络层的问题还是应用层的问题，再决定往哪调。

第三条，编码协商这件事，宁可窄一点也别贪多。有的团队一上来就想支持所有编码、所有分辨率、所有帧率，结果协商组合爆炸，兼容问题层出不穷。 先锁定一两个主流编码，把主流浏览器跑稳，再谈扩展。 这跟上面提到的“先音频再视频再 Simulcast”是同一个思路——分步验证，别一次性把所有变量都打开。

第四条，测试一定覆盖“非理想网络”。本地局域网跑得再顺，也说明不了什么。用网络损伤模拟工具制造丢包、延迟、抖动、带宽限制，能跑顺了再谈上线。实时音视频产品的质量，几乎都是在弱网下见分晓的。

第五条，如果你只是要一个稳定的实时音视频能力，不一定非要自己维护一套 SFU。像 Colibri 这类开源方案，它的价值更多在于提供了一种“把 SFU 做轻”的架构思路——你可以直接用它提供的托管能力，也可以借鉴它的分层思想改造自己的系统。 先想清楚自己要的是“架构启发”还是“开箱即用”，再决定投入多少。 前者看源码和设计文档就够了，后者要评估长期维护成本，包括版本升级、依赖变化、平台适配这些琐碎但耗人的事。

我个人在接触这类边缘媒体转发方案时最深的体会是：它的优雅之处不在于某个具体技术的先进，而在于把“状态”和“计算”这两件事的边界划得很清。这个边界一旦划对，后面的扩容、容错、成本优化都会顺很多；边界划错，再多的微优化也救不回来。所以如果你正打算做实时音视频，不妨先花半天时间，把“哪些信息必须长期存在、哪些可以随用随取”这个问题在纸上写清楚，再动手选型，往往比直接抄一个现成方案走得更远。