GB28181与RTSP双协议接入的视频融合网关架构设计与实践

1. 为什么要有视频融合网关：碎片化问题的真实场景

先说我自己的经历。之前在某个做园区安防的项目里，甲方园区里前后装了三批摄像头：最早一批是海康的老设备，只支持 RTSP 拉流；中间补了一批大华的国标设备，走 GB28181 注册上平台；后来做智慧楼宇改造，又加了一批支持 ONVIF 的球机。结果呢？监控大屏上要同时开三套客户端，运维排查故障要分别登录三个平台，上层业务系统想统一调视频流，得自己写三套适配器。这种局面在行业里太常见了，本质上就是视频系统碎片化：协议碎片化、设备碎片化、平台碎片化。

所以我在设计企业级视频融合网关时，核心目标很明确：把 GB28181 和 RTSP 这两大类最主流的接入方式统一收敛到一套系统里，对外暴露标准化接口，对内屏蔽协议差异。GB28181 解决的是“国标设备如何注册、如何被调度”的问题，RTSP 解决的是“存量设备如何直接拉流”的问题，两者并不是替代关系，而是互补关系。网关的价值，就是让上层业务不再关心摄像头是海康还是大华、走国标还是裸流，只要告诉我“我要看某条通道的视频”，网关就能把流拉回来、转出去。

这篇文章我会先把协议的关键机制讲透，再给出整体架构分层设计，然后重点拆解注册、拉流、转码、播放这几个核心链路的源码实现，最后整理一批我们实际踩过的坑。如果你正在做视频接入平台、流媒体服务，或者只是想在项目里通过 GB28181/RTSP 对接摄像头，这篇文章应该能帮你省不少时间。

2. 核心协议梳理：GB28181 与 RTSP 的关键机制

2.1 GB28181 不是“一个协议”，而是一套会话体系

GB28181 全称是《安全防范视频监控联网系统信息传输、交换、控制技术要求》，它规定的是 SIP 信令 + RTP/PS 媒体传输的整套交互流程。很多新手容易犯的错误是：把 GB28181 理解成“像 RTSP 一样有一个 URL 直接拉流”。实际上 GB28181 是设备作为 SIP UA 主动向上级平台注册，平台通过 SIP 信令向设备发起 INVITE 请求，设备才被动开始推流。整个链路里，信令面和媒体面是分开的。

注册流程大概是这样的：设备启动后，向 SIP 服务器发送 REGISTER 请求，携带设备 ID、域、IP、端口等字段，服务器返回 200 OK 并带上 expires 有效期。设备需要周期性刷新注册，否则服务器会把设备标记为离线。这一步是后续一切操作的基础，如果注册都不稳定，后面目录查询、实时点播全都会失败。

实时点播的流程更关键：平台向设备发送 INVITE 请求，SDP 里带上 ssrc、媒体端口、编码格式等参数，设备收到后回复 200 OK，然后通过 RTP 把 PS 封装好的音视频数据推到平台指定端口。平台侧要做的核心工作，就是完成“PS 解封装 -> 提取 H.264/H.265/AAC 裸流 -> 重新封装成统一格式”这一串处理。这里有个容易忽略的点：GB28181 的 RTP 包结构跟普通 RTSP 拉流的 RTP 包不完全一样，它是把 PS 流整体塞进 RTP payload，所以解包时要先按照 RFC 2250 的方式组 PS 包，再用 PS 解复用去剥出基础流。很多自研网关视频花屏、卡死，问题就出在这一层没有处理对。

2.2 RTSP 的简洁与复杂并存

RTSP 本身是一个”带外信令“协议，控制指令（OPTIONS、DESCRIBE、SETUP、PLAY）走 TCP，媒体数据走 RTP/RTCP。它的好处是简洁直接，一条 RTSP URL 加用户名密码就能拉流，但实际对接中你会发现细节非常多。比如海康摄像头默认的取流地址格式是：

code复制rtsp://username:password@192.168.1.64:554/Streaming/Channels/101

注意这个 101 代表通道 1 主码流，102 是通道 1 子码流。如果你只改 IP、不改通道号，会发现拉回来的视频要么没有，要么卡顿，因为子码流分辨率低、码率小，但画质差很多。

RTSP 拉流还有一个特点是状态机复杂：每次都需要先发送 DESCRIBE 获取 SDP，再根据 SDP 里的 media 描述逐个 SETUP，最后 PLAY 才开始推流。如果在 SETUP 阶段没有把 RTP over TCP 的选项协商好，很多摄像头默认只走 UDP，而跨网段场景下 UDP 经常被防火墙丢包，导致画面狂掉帧。所以企业级网关在做 RTSP 客户端时，一定要支持 TCP 优先、UDP 兜底的降级策略。

2.3 网关为什么选择“双协议栈”而不是二选一

我见过不少自研项目，一上来就说“我们全部走 GB28181”，结果发现一批老设备根本不支持国标，只能让厂家升级固件，增加成本还拖延工期。反过来，如果只做 RTSP，又没法接入那些只愿意开放 GB28181 的平台型设备。所以网关最合理的设计是双协议栈并行：新建项目或对国标有强制要求的场景走 GB28181，存量设备或快速接入场景走 RTSP。网关内部把两种协议统一映射成“通道”这个抽象模型，上层只跟通道打交道。

这样做还有一个好处：协议解析和媒体处理可以分层解耦。比如信令层由 GB28181 SIP 模块或 RTSP 客户端模块负责，两者互不感知；媒体层统一处理 RTP 接收、PS/MP4 解封装、转码、分发。后续哪怕要接入 ONVIF、私有 SDK，也只需要新增一个接入适配器，媒体层完全不动。

3. 网关整体架构设计：分层与模块化

3.1 分层架构：接入层、媒体层、服务层、管理面

企业级视频融合网关不能只是一个“中转盒子”，它至少要支撑上千路视频接入、多租户调用、鉴权、录像、转码、分发等能力。所以我在设计时把系统拆成了四层：

• 接入层：负责各种协议接入，目前实现了 GB28181 SIP UA（注册、心跳、INVITE 点播、语音对讲）和 RTSP 客户端（拉流、重连、自动恢复）。这一层遵循统一的接入接口，每个协议模块可以独立部署升级。
• 媒体层：负责 RTP 接收、PS 解封装、编码数据提取、转码（透明转封装，必要时转码）、录像存储、RTSP/HLS/WebRTC/GB28181 输出分发。这是整个网关里性能要求最高的部分。
• 服务层：向上层业务系统提供 RESTful API、WebSocket 消息推送、后台任务调度（定时拉流、轮询设备状态）。
• 管理面：设备管理、通道管理、用户权限、告警日志、配置中心。

这里想特别强调一个设计原则：接入层和媒体层一定要分离。如果信令处理和流媒体处理耦合在一起，一个视频流异常就可能导致整个 SIP 线程卡死，拖垮所有设备的注册状态。我早期做一个原型就吃过这个亏：一路 RTSP 拉流因为摄像头密码改了就 hang 在那里，结果整个 Netty 线程池被占满，其他设备的点播全部超时。后来把媒体处理放到独立的线程池 + 队列里，才彻底解决。

3.2 关键技术选型：为什么是 Netty + ZLMediaKit 的组合

信令层面我用 Netty 实现 SIP 协议栈和 HTTP 服务，主要原因是 Netty 的异步非阻塞模型非常适合 SIP 这种高并发、短连接、有大量定时任务的场景。GB28181 的 SIP 消息本质上就是一个文本协议，用 Netty 的 Decoder/Encoder 可以很干净地处理消息解析、事务匹配、超时重传。

媒体层我建议优先考虑 ZLMediaKit 这类成熟开源流媒体服务器，而不是自己从头实现 RTP 接收和分发。原因是音视频底层坑太多：RTP 时间戳抖动、PS 流拼接、音视频同步、TCP 粘包拆包，这些问题不是一两个星期能调通的。ZLMediaKit 提供了完善的 RTP 代理、PS 解封装、HLS/RTSP/WebRTC 输出能力，我们只需要关注上层业务逻辑。需要注意的版本锁定：在生产环境不要频繁升级 ZLMediaKit，要多做回归测试，因为它的 API 调整比较频繁。

如果你对 MediaMTX 更熟悉也行，它轻量、部署简单，做 RTSP 到 Web 播放的转换链路很快。但 MediaMTX 在 GB28181 的国标接入能力上较弱，它更擅长 RTSP/RTMP 的互相转换。我的取舍是：GB28181 接入自研信令 + 对接 ZLMediaKit 做媒体，RTSP 接入自研客户端 + 同样走 ZLMediaKit 分发，这样整个媒体面是统一的。

3.3 关键数据模型设计：设备、通道、流会话

把协议差异收敛掉之后，中心数据模型就只有三个核心概念：

• Device（设备）：一个物理设备或一个 SIP 代理节点。包含设备 ID、厂商、协议类型（GB28181/RTSP）、IP、端口、在线状态、最后心跳时间。
• Channel（通道）：设备下的一个视频源。一个设备可能有多路通道，比如 16 路 NVR。每个通道包含通道 ID、名称、编码格式、分辨率、码率、以及针对不同协议的“取流参数”映射表。
• StreamSession（流会话）：一次实际的拉流/分发过程。记录通道 ID、源协议、目标协议、开始时间、当前状态、错误信息。所有上层业务（直播、回放、AI 分析）都围绕 StreamSession 进行生命周期管理。

这个模型的巧妙之处在于：虚拟组织“设备->通道”是固定的，而“流会话”是动态的。同一路通道可以被多个下游同时观看，网关内部做按需拉流和引用计数，最后一个观众离开后自动关闭源拉流。这个特性可以解决一个很常见的浪费问题：几十个人同时看同一路摄像头，如果没有引用计数，网关就会对每个观众都建立一路独立的源拉流，把摄像头和带宽都拖垮。

4. 核心源码解析：GB28181 信令接入与音视频会话

4.1 REGISTER 注册与心跳保活

GB28181 注册这一块，最核心的是要处理好“事务状态”和“超时重传”。下面是我们在 Netty 基础上实现的简化版 SIP REGISTER 处理器：

java复制public class RegisterHandler extends SimpleChannelInboundHandler<SipMessage> {

    private final DeviceRegistry registry;
    private final SipTransactionManager transactionManager;

    @Override
    protected void channelRead0(ChannelHandlerContext ctx, SipMessage msg) {
        if (!"REGISTER".equals(msg.getMethod())) {
            ctx.fireChannelRead(msg);
            return;
        }
        String deviceId = parseDeviceId(msg.getFrom());
        String domain = parseDomain(msg.getTo());
        int expires = Integer.parseInt(msg.getHeader("Expires"));

        Device device = registry.find(deviceId, domain);
        if (device == null) {
            // 新设备注册：首次注册时可以先返回 401 携带鉴权要求
            sendUnauthorized(ctx, msg);
            return;
        }
        if (expires == 0) {
            // 注销
            device.setOnline(false);
            registry.save(device);
            sendOk(ctx, msg);
            return;
        }
        OnlineStatusTracker.refresh(deviceId, System.currentTimeMillis());
        device.setOnline(true);
        device.setContactAddress(msg.getContact());
        registry.save(device);
        sendOk(ctx, msg);
    }
}

这里有几个容易踩的坑。第一，注册有效期要和设备端协商一致，一般设备默认 3600 秒，但部分设备注册时携带的 expires 不同，服务器在 200 OK 里必须回写同样的 expires，不能自己随意改。第二，注册鉴权：GB28181 的鉴权一般用 Digest 认证，需要保存设备密码（通常是平台侧配置的密码），并在 401 响应的 WWW-Authenticate 头里带上 nonce。第三，心跳保活：很多设备除了 REGISTER 刷新，还会周期性发送 MESSAGE 消息作为心跳，平台要识别两种心跳来源，不能重复判断离线。我们内部的做法是：收到任何来自该设备的 SIP 消息都刷新在线状态，如果超过 3 个心跳周期没收到任何消息，才判定离线。

在分布式部署场景下，注册状态不能只存在单机内存里，否则网关一台机器重启，所有设备都要重新注册。建议把设备在线状态存到 Redis，并用 pub/sub 广播给所有信令节点。在线状态的上报延迟控制在 1 秒内即可，不用追求极端实时。

4.2 INVITE 实时点播与 200 OK 处理

实时点播是 GB28181 里最核心、也最容易出问题的环节。平台发起 INVITE 时，SDP 描述里需要指明接收媒体的 IP、端口、ssrc、以及媒体格式。这里有一个很关键的点：INVITE 里带不带 ttl 参数，以及 ssrc 用什么规则生成，不同厂商的设备解析结果不一样。我们最终采用的兼容做法是：平台侧固定一个媒体接收端口段，ssrc 由设备 ID 哈希生成，并在 SDP 中同时携带 sendrecv 属性。

设备接收到 INVITE 后，如果参数 OK，会回复 200 OK 并在 SDP 里带上它要推流的端口和 ssrc。平台侧收到 200 OK 后，需要用 ACK 确认，然后在指定端口接收 RTP。这个流程里最容易出现的问题是：设备推流的地址和平台 INVITE 中指定的地址不一致。比如设备在 200 OK 里回复的媒体端口是 56000，但实际推流源端口可能是 56002，因为 NAT 或多网卡原因。所以我们实现了一个“端口自适应”逻辑：收到 200 OK 后创建媒体接收套接字，但同时在 RTP 接收回调里校验包来源地址，如果收到的是来自其他端口的包，就把会话的远端地址动态更新。

下面是点播会话的伪代码框架：

java复制public class InviteSessionManager {

    private final Map<String, StreamSession> sessions = new ConcurrentHashMap<>();

    public void onInviteOk(String callId, SdpDescription remoteSdp) {
        StreamSession session = sessions.get(callId);
        session.setRemoteHost(remoteSdp.getMediaHost());
        session.setRemotePort(remoteSdp.getMediaPort());
        session.setSsrc(remoteSdp.getSsrc());
        // 关键：在媒体接收端口上启动 RTP 接收器
        MediaReceiver receiver = new MediaReceiver(session);
        mediaEngine.bind(session.getLocalMediaPort(), receiver);
        // 发送 ACK 给设备
        sendAck(callId);
    }
}

4.3 语音对讲会话与双向音频

GB28181 语音对讲是一个大家关注比较多、但实现很少被讲透的能力。普通实时点播是设备推流到平台，对讲则是平台推流到设备。我实现时主要处理了三个难题：

• SDP 协商方向：对讲 INVITE 的 SDP 里要明确方向标记，一般用 recvonly 表示平台只收设备音频（单向喊话），用 sendrecv 表示双向音频。不同厂商对方向协商的支持不太一致，有些老设备只支持单向。
• 音频编码格式：GB28181 对讲通常使用 G.711A/U 或 G.722 编码，平台侧需要把来自业务方的音频数据（如 Web 端的 PCM/Opus）转成目标编码格式再推给设备。
• RTP 发送节奏：音频 RTP 包必须按照采样率节奏发送，不能一次性把所有包都发出去。G.711 一个包一般是 20ms 音频，也就是 160 字节净荷，发送间隔 20ms。我们用了一个定时发送器，把编码后的音频包放入阻塞队列，由发送线程按时间戳投递。

对讲功能的引入让网关系数一下子丰富了很多，从纯视频监控扩展到了音视频调度场景，比如指挥中心喊话、门禁对讲。如果要做，建议尽早规划音频编解码的抽象层，别在业务里硬编码 G.711。

4.4 GB28181 403 错误和请求超时的排查

热词里特别多人在搜“gb28181 403”和“gb28181 对接 请求超时”，这两个问题我在项目里都亲自处理过。403 的根因通常是鉴权失败，具体而言可能是设备管理里面的密码配置不对，或者是摘要鉴权用的 nonce 过期。我们调试时的排查顺序是：

1. 抓包看 REGISTER 的响应：如果是 401，但设备没有重发 REGISTER，说明设备端没有实现摘要鉴权，平台就要调整策略，允许白名单 IP 免鉴权。
2. 如果设备重发了 REGISTER 但平台仍返回 403，对比两次请求的 Authorization 头，检查 username 是否带域名后缀。有些设备要求用户名是“设备ID@域名”，如果只想配设备 ID，平台侧要强制补全域名。
3. 检查服务器时间：digest 鉴权的 nonce 有有效期，如果平台和设备的系统时间偏差超过 5 分钟，就可能导致鉴权失败。有一次故障就是服务器时钟漂移了 8 分钟，所有设备批量 403，真是惨痛教训。

请求超时则大多数发生在 INVITE 阶段。排查思路是先确认设备是否收到了 INVITE，没收到的话检查 SIP 端口可达性和 NAT 穿透配置；收到了但没回响应，多半是 SDP 参数不兼容，先把 SDP 里的 ssrc、媒体端口、编码列表简化，一次只协商一种编码，减少兼容性问题。如果设备回了 200 OK 但平台侧迟迟收不到流，就要重点排查媒体端口是不是被防火墙拦截了，以及设备推流的源端口和 SDP 里声明的是否一致。

5. 核心源码解析：RTSP 拉流、缓存与分发

5.1 RTSP 客户端状态机设计与重连策略

RTSP 客户端看起来简单，但要做得稳定并不容易。一个完整的拉流状态机包含这些状态：IDLE -> CONNECTING -> DESCRIBING -> SETUPING -> PLAYING -> PAUSED -> RECONNECTING -> CLOSED。每个状态之间都有超时保护和重试计数。

我实现的简化状态机逻辑：

java复制public enum RtspState {
    IDLE,
    CONNECTING,
    DESCRIBING,
    SETUPING,
    PLAYING,
    RECONNECTING,
    CLOSED
}

客户端从 IDLE 到 PLAYING 的切换过程中，最容易出的问题是 TCP 会话复用。RTSP 1.0 允许在一个 TCP 连接上串联发起多个请求，但很多摄像头实现不标准，如果你不等待上一个响应就发送下一个请求，就会收到 400 Bad Request。所以我们用了“串行请求队列”：每个命令必须等上一个命令的响应完成后再发送。这个设计在并发场景下保证了兼容性。

重连策略上，我采用的规则是：播放中如果检测到 RTP 超时（比如超过 5 秒没有收到任何 RTP 包），就进入 RECONNECTING，最多重试 5 次，间隔指数退避（2s、4s、8s、16s、32s）。重连成功后，通知上层 session 状态变更，让 Web 端做播放器重新拉流。注意：重连不能让业务层感知到断流时间过长，所以网关内部会做短暂缓存，尽量做到无缝切换。

5.2 RTP 接收、PS 解封装与编码数据归一化

不管是 GB28181 推送的 PS 流，还是 RTSP 拉流的 H.264 RTP 流，最终都需要归一化成统一的编码帧数据交给上层。这里面最重要的一个环节是 RTP 包乱序和丢包处理。

RTP 包有一个 16 位的 sequence number，正常情况下应该是递增的，但在 UDP 传输下可能出现乱序。如果直接把包按到达顺序交给解封装器，H.264 会出现大量花屏。所以我实现了一个“排序窗口”：每个会话维护一个小根堆，按 seq 排序，只有当收到比当前最大 seq 大一定数值（比如 50）的包时，才把窗口内的有序包批量交给解析器。如果检测到丢包（seq 跳变），则跳过并从下一个关键帧开始重新组装，避免花屏持续。

PS 解封装（针对 GB28181）的逻辑是：RTP 的 payload 是 PS 包的一部分，网络层先把多个 RTP 包组成完整的 PS 包，再通过 PS 头中的 stream_id 解析出 PES 包，最终剥离出 H.264/H.265 的 Access Unit。这个链路比较长，但每一步都有很好的开源参考。在实现时，我只保留了关键的业务关注点：时间戳同步、SPS/PPS 缓存、关键帧标记。SPS/PPS 真的很重要，如果回调帧里没有这两个参数，后面的解码器根本起不来。ZLMediaKit 在收到 PS 流时会自动提取并缓存 SPS/PPS，所以很多情况下你只要保证把 PS 包完整喂给它就行，不用自己做复杂解析。

5.3 RTSP 流如何转成浏览器可播放：HLS 与 WebRTC 的选择

很多人问“rtsp://10.51.25.19:554/openurl/... 浏览器如何播”，这个问题本质上是浏览器不支持 RTSP，必须由服务端做协议转换。可选的方案有 HLS、WebRTC、HTTP-FLV（配合 flv.js）。我的经验是：

• HLS（m3u8/ts）：兼容性最好，Safari 原生支持，但延迟高，通常 5-10 秒。适合录制回放、对实时性要求不高的场景。
• HTTP-FLV + flv.js：延迟可以做到 1-3 秒，兼容性不错，适合低延迟直播，但 flv.js 对 H.265 的支持需要额外扩展。
• WebRTC：延迟最低，端到端 300-500ms，适合实时对讲、指挥调度，但对服务端 TURN/ICE 配置要求高，跨网穿透复杂。

我们网关目前采用“按需取流”的策略：当业务方请求一个通道的播放地址时，调用方可以指定目标协议（hls/webrtc/flv），网关按需启动一条从源到 ZLMediaKit 的推流管道。如果什么都没指定，默认用 HLS，因为兼容性最好，接大屏、接第三方平台都不会有问题。

MediaMTX 是另一个非常方便的工具，如果你只是想把一路 RTSP 转成 Web 播放，不要求大规模和国标接入，直接用 MediaMTX 的 HLS 输出就能快速搞定。它的配置很简单：

yaml复制paths:
  cam1:
    source: rtsp://admin:password@192.168.1.100:554/streaming/channels/101
    hls: true

但要注意：MediaMTX 如果只拉一路还好，拉多路时内存占用和 CPU 占用会明显增长，建议每路源转封装时限制 GOP cache 的大小，避免内存被无界队列打爆。

5.4 安卓端缓存 RTSP 流与离线重放

关于“安卓缓存 rtsp 流”这个热词，我理解大家想要的是：在移动端弱网环境下，先把 RTSP 流录成文件或切片，用于离线回放或断网续播。我们实现了一个简单但有效的方案：在网关的媒体层增加一个“录制任务”，把归一化后的 H.264/AAC 数据写入 MP4 文件，同时生成时间索引。安卓客户端在看直播时，如果检测到网络从 WiFi 切到 4G/5G，网关会自动把最近 30 秒的录像切片拉下来做无缝衔接。这个功能本质上是“边看边录 + 时间戳对齐”。

实现上需要注意的是 MP4 的 moov box 处理：如果一个文件边写边播，需要用到 fragmented MP4，也就是每几秒一个 moof/mdat 片段。Android 的 MediaExtractor 对 fragmented MP4 支持不错，但 iOS 端支持差一些。所以我们对外统一提供“录制列表”API，而不是直接把 mp4 文件暴露出去，这样可以屏蔽不同容器的兼容问题。

6. 常见问题与排查技巧实录

6.1 问题速查表

6.2 排查工具与方法论

排查音视频问题，纯粹看代码是不够的，必须依赖抓包工具。我常用这三板斧：

1. Wireshark / tcpdump：抓 SIP 信令包，看 REGISTER、INVITE、200 OK、ACK 的时序，确认哪一步断了。SIP 的 IP 和端口都很直观，配合过滤规则 sip || rtsp 就能快速定位。
2. ffprobe：拿到 RTSP 地址后，先用 ffprobe 确认媒流是否可读、编码参数是否正常：ffprobe -rtsp_transport tcp -i "rtsp://..."。如果 ffprobe 能出流，说明源侧基本没问题，问题在我们的转发链路。
3. 服务端日志：在网关里给每个 StreamSession 打上完整的生命周期日志，包括状态变更时间、错误码、错误描述。生产环境必须做到“一路流一条日志链路”，否则排查故障时只能靠猜。

6.3 避坑指南：认证、地址失效与缓存

先说认证。RTSP 有 Basic 和 Digest 两种认证，摄像头配置改了密码后，网关里如果还缓存着旧密码，会出现间歇性 401。所以我在实现中每次认证失败都会清掉该通道的认证缓存，并立刻重试一次，避免因为缓存导致“密码已改但服务还认为没改”的尴尬。GB28181 的密码管理也一样，设备侧的密码可能通过平台批量下发，如果某台设备密码不一致，最好能在管理界面单独看到该设备的密码状态，不要只看“在线/离线”。

地址失效这一块，很多 RTSP 摄像头在 IP 地址或端口变化后，旧 URL 会一直握着重试，导致内存里堆积大量无效会话。我们的处理方式是：一旦连续重连失败 5 次，就把该会话置为 URL_INVALID，通知管理面做设备巡检，而不是无限重试。

缓存这个点容易被忽略。流媒体网关里面，SPS/PPS、GOP 缓存、HLS 切片列表、WebRTC 的 ICE 候选，这些都是不同类型的缓存。如果缓存策略不对，会导致播放延迟越来越大。我建议给每个会话设置一个最大缓存时间，比如 HLS 切片只保留最近 3 个，WebRTC 的 JitterBuffer 上限设置为 500ms，超出的包直接丢弃，宁可偶尔花一下，也不要让延迟越攒越大。

7. 架构演进与部署实践

7.1 单机到集群：媒体节点怎么扩容

网关刚上线时只有一两百路视频，单机部署完全够用。但视频项目增长往往很快，半年后接入上千路，CPU 和带宽双双吃紧。这时代码写得再好都不如架构上的水平扩展重要。我的扩容思路是：

• 信令节点无状态化：GB28181 的 SIP 注册和点播请求可以分布到多个节点，用负载均衡分发。每个节点共享 Redis 里的设备状态和会话数据。
• 媒体节点按“流会话”路由：同一路通道的拉流和分发必须绑定到同一个媒体节点，否则多个节点同时拉同一路源流，带宽翻倍。我们实现了一个会话路由表：从信令节点创建 StreamSession 时，根据通道 ID 哈希选择媒体节点，并将路由信息写入 Redis。
• 多网卡绑核：媒体节点通常有多个网卡和多核 CPU，建议将 RTP 接收、转封装、协议输出分别绑定到不同的 CPU 核心，减少锁竞争和缓存抖动。

7.2 容器化与云原生改造

目前我这边的新项目基本都跑在 Kubernetes 上。视频网关容器化时要特别注意几个点：首先，RTP 接收需要稳定的 UDP 端口，容器网络要使用 hostNetwork 模式，直接用宿主机的 IP 和端口，这样才能让摄像头顺利推流。其次，媒体节点要避免被调度器随意重启，用 StatefulSet 来部署，保证每个 Pod 有稳定的标识和存储。最后，日志和监控要尽早接入 Prometheus + Grafana，重点关注 RTP 丢包率、会话数量、内存队列积压、CPU 占用这几个指标。很多视频故障不是突然出现的，而是慢慢劣化的，有监控才能在用户投诉前发现问题。

7.3 从“能用”到“好用”：我的几点体会

做这种融合网关，技术难点其实不在某个协议的具体字段，而在于如何优雅地处理大量差异和不确定性。我的体会是：编码时要尽量保证核心的数据流不依赖特定厂商的奇葩行为，所有“兼容性”分支都放在适配层，这样即使某个厂商出了问题，也不影响到整条链路。

不管怎么说，视频接入的底层逻辑始终是“信令控制 + 媒体传输”两条线，只要把这两条线分离清楚，无论是 GB28181 还是 RTSP，都只是其中一种实现而已。真正的壁垒是在时间的积累和对细节的审美里沉淀下来的。

最后再分享一个小技巧：每次新增协议接入之前，不要急着写代码，先把市面上常见的设备抓包数据整理成一份“兼容性清单”，后面所有代码改动都用这份清单回归一遍。我踩过最深的坑就是自以为把 GB28181 调通了，结果临上线时换了一台不同厂商的摄像头，才发现自己的实现完全依赖了上一个厂商的私有行为。所以，好的网关不仅是写出来的，更是靠一台一台设备“喂”出来的。