GBHub 国标视频平台：一款 Rust 实现的高性能 GB/T 28181 视频接入与分发平台
前言
最近在做一个视频监控相关的项目，需要将不同品牌、不同型号的摄像头统一接入和管理。调研了一圈，发现市面上的国标视频平台要么是商业闭源的，价格不菲；要么是基于 Java 或 Go 实现的开源方案，性能和资源占用上总觉得差点意思。
于是自己动手用 Rust 写了一个——GBHub 国标视频平台。
经过一段时间的开发和实际部署，目前已经稳定运行在生产环境中，接入了几百路摄像头。在这里把项目的设计和实现思路分享出来，希望对有类似需求的朋友有所帮助。
项目官网：https://gb.automate.org.cn
为什么选择 Rust？
在开始之前，先聊聊为什么用 Rust。
视频监控平台是一个典型的长时间运行、高并发、对稳定性要求极高的服务端程序。设备注册、心跳保活、信令处理、媒体流转发……任何一环出问题，都可能导致整个系统不可用。
Rust 的优势恰好匹配这个场景：
内存安全：没有 GC 停顿，不会因为垃圾回收导致请求延迟抖动 零成本抽象：高性能的同时保持代码的可维护性 强大的异步生态：Tokio 提供了高效的异步运行时，单机轻松支撑数万并发实际测试下来，GBHub 的空闲内存占用不到 50MB，单机可以稳定承载 5 万+ 设备并发注册。
系统架构
GBHub 采用微服务架构，由三个核心服务和一套共享库组成：
服务 功能 端口
gbhub-mgr 管理服务器，提供 HTTP API 3002
gbhub-sip SIP 信令服务器 6060 (SIP) / 3003 (API)
gbhub-scheduler 定时任务调度器 无外部端口
管理服务（gbhub-mgr）统一对外提供 HTTP API，同时将未匹配的请求自动代理到 SIP 服务，对调用方来说就像是一个完整的服务。
定时任务调度器是独立运行的，每 30 秒扫描一次 Redis 中的任务配置，按 Cron 表达式触发截图、录制、清理等任务，不需要额外部署 cron。
核心功能
- 设备接入与管理
完整支持 GB/T 28181-2016 和 2022 标准，设备通过 SIP 协议注册接入。
实际测试中，海康、大华、宇视等主流厂商的 IPC 和 NVR 都可以正常接入。传输协议自动适配 UDP/TCP，注册认证支持 Digest 摘要认证（MD5 和 SHA-256 都支持）。
设备注册成功后，平台会自动查询 Catalog 获取通道列表，不需要手动配置。
2. 实时直播与回放
直播支持多种输出协议：
协议 延迟 适用场景
WS-TS < 1s 通用浏览器播放
WebRTC < 500ms 低延迟场景
HTTP-FLV / HLS 1-3s 移动端、兼容性优先
回放支持精确到秒的检索，播放过程中可以暂停、跳转进度。
3. 录像与转录
两个比较实用的功能：
自动录制：通过定时任务配置，按计划自动录制指定通道 录像转录：将设备的历史录像片段异步转录为 MP4 文件，支持去重和并发控制转录功能在实际项目中帮了大忙——有些设备的录像格式不兼容，转录后统一为 MP4，方便归档和分享。
4. 级联与目录管理
支持作为下级平台向上级 SIP 域注册，也支持作为上级平台接收下级注册。
目录管理支持三种推送方式：
扁平列表：仅推送通道列表 行政目录：按省/市/区组织通道 业务目录：按业务分组（215/216）组织通道通道可以绑定自定义名称，上级平台看到的目录树会更直观。
5. 定时任务
内置了 Cron 调度器，支持以下任务类型：
定时截图（snapshot） 定时录制（record） 清理残留会话（cleanup_sessions） 同步设备在线状态（sync_device_status） 清理过期录像（cleanup_media） 清理过期截图（cleanup_snapshot）清理任务在实际运维中非常实用——录像文件占满磁盘是视频平台最常见的问题之一，配置一个每天凌晨执行的清理任务就能自动解决。
几个值得说的技术点
Redis 性能优化
早期版本使用 KEYS 命令和 SCAN 遍历 dev_info:* 来获取设备列表，设备数量超过 5000 后接口响应明显变慢。
后来改成了 Redis Set 维护全局索引：
all_devices：存储所有设备 ID，查询 O(1) cascade_ids：存储级联服务器 ID，启动恢复不再需要 KEYS cascade:*优化后，设备列表查询延迟从几百毫秒降到了 1 毫秒以内。
连接池方面用了 deadpool-redis，解决了之前单连接断连需要重启服务的问题。
级联信令与媒体解耦
早期版本中级联实例创建时强制依赖 ZLM 在线，如果 ZLM 重启，级联实例就丢了。
后来做了改造：SipState 的 zlm 字段改为 Option，级联实例创建和恢复时不依赖 ZLM。INVITE 处理时再动态获取 ZLM 客户端。
这样 ZLM 重启不会影响级联注册状态，系统可靠性提升了不少。
反向索引
通道绑定用了两个 Hash：
channel_bindings：app:stream → 通道 ID（正向） channel_bindings_rev：通道 ID → app:stream（反向）反向索引让级联场景下的流查找变成了 O(1) 常数时间，不用遍历查找。
部署体验
部署流程比较简单：
配置好 Redis、PostgreSQL/GreptimeDB、ZLMediaKit 创建 .env 文件，配置数据库连接、SIP 参数等 启动三个服务项目提供了 systemd 服务配置模板，可以用 systemctl 管理服务生命周期。
授权方式采用的是 Ed25519 数字签名 + 硬件指纹绑定，授权文件 license.lic 放在服务目录下即可。
一些踩过的坑
设备注册失败：最常见的原因是 SIP 端口没开放（默认 6060），或者密码配置不一致。查看 logs/sip.log 可以快速定位。
流播放黑屏：一般有两种情况——ZLM 节点离线，或者设备端码率过高。前者检查 zlm_nodes:online 集合，后者在设备端降低码率试试。
录像转录超时：如果设备不支持回放或者时间范围内没有录像，转录任务会超时。建议先通过设备录像查询确认时间范围内有数据。
后续计划
Docker 镜像支持，进一步降低部署门槛 更多流媒体协议的支持 智能分析能力接入总结
GBHub 是我在 Rust 国标视频平台方向的一次尝试，目前已经能够稳定支撑实际项目使用。如果你也在做视频监控相关的项目，或者对 Rust 在安防领域的应用感兴趣，欢迎交流。
项目官网：https://gb.automate.org.cn
在线演示：https://mgr.automate.org.cn（用户名 admin / 密码 admin123）
