打破视频孤岛：基于 ZLMediaKit 的 GB28181 与 RTSP 统一接入网关架构设计
引言：协议碎片化是安防 AI 最大的“拦路虎”
在企业级 AI 视频分析项目中，算法模型往往只是冰山一角。作为拥有 10 年经验的架构师，我深知“设备接入”才是最令人头疼的环节。客户的现场可能充斥着海康、大华、宇视等不同品牌的 IPC，甚至还有老旧的模拟采集卡；它们分别遵循GB28181、Onvif、RTSP或私有 SDK 协议。
如果为每种品牌开发独立的拉流模块，不仅开发周期长，且维护成本极高。据统计，处理复杂的设备兼容性和流媒体服务搭建，占据了传统开发模式中95%的无效投入。
本文将深入解析YiheCode Server如何利用ZLMediaKit构建统一的流媒体接入层，实现对多源异构设备的协议解耦与标准化转码，构建企业级的视频“底座”。
一、 协议层解耦：构建统一的视频接入标准
YiheCode Server 的核心设计理念在于“南向多协议兼容，北向标准化输出”。它不依赖于特定厂商的 SDK，而是通过标准协议与设备交互，从而实现了对硬件品牌的彻底解耦。
1.1 全协议支持矩阵
平台通过封装底层的复杂性，为开发者提供了一致的视频流接口：
| 协议类型 | 适用场景 | 技术特点 |
|---|---|---|
| GB/T 28181 | 政企、多级级联 | 国标协议，支持信令与媒体流分离，适合大规模组网 |
| RTSP/RTMP | 通用流媒体 | 低延迟拉流，兼容 H.264/H.265 编码，适用于边缘推流 |
| Onvif | 跨品牌互通 | 国际通用标准，主要用于设备发现与控制 |
| 自定义推流 | 特殊环境 | 支持本地文件、桌面捕获或第三方推流源接入 |
1.2 自动化设备分配机制
根据 Gitee 仓库文档中的架构图描述，系统在接入海量设备时，采用了“负载均衡 + 最小连接数”的分配策略。
接入流程逻辑：
- 信令交互：当摄像头通过 GB28181 注册或 RTSP URL 添加时，信令服务接收请求。
- 智能路由：系统自动根据当前节点的负载情况（最小连接数原则），将摄像头分配给指定的ZLMediaKit 节点。
- 拉流分发：目标 ZLM 节点执行拉流操作，并将流转码为统一的 FLV/HTTP-FMP4 格式，供前端播放和 AI 分析。
二、 流媒体架构：基于 ZLMediaKit 的集群化管理
传统的单体流媒体服务器在面对几百路并发时往往不堪重负。YiheCode Server 采用了“中心控制 + 边缘节点”的分布式架构。
2.1 ZLMediaKit 节点集群
文档中提到的“ZLM 组”设计，允许系统横向扩展多个流媒体节点。
- 无状态节点：每个 ZLMediaKit 实例都是无状态的，负责具体的拉流、录制和分发。
- 中心调度：Java 后端作为大脑，通过 HTTP API 或 Socket 通信控制 ZLM 节点的生命周期。
节点配置示例 (application.yml)：
zlm:# 主节点地址primary_node:http://192.168.1.10:8080# 从节点集群列表 (支持动态扩缩容)cluster_nodes:-id:worker_01url:http://192.168.1.11:8080max_streams:100# 限制单节点最大流数-id:worker_02url:http://192.168.1.12:8080max_streams:100# 拉流策略：自动按最小数指定到一个ZLM节点pull_strategy:LEAST_CONNECTIONS2.2 智能拉流与录制控制
为了避免无效的带宽占用和算力浪费，系统设计了精细化的拉流控制逻辑（参考文档架构说明）：
- 按需拉流：
- 对于手动新增的摄像头：录像控制程序定时检测，若需录像则主动拉流。
- 对于GB28181 国标流：不主动拉流，仅在 AI 算法启动需要分析时，才触发拉流动作。这极大地节省了内网带宽。
- 跨网播放：通过 ZLM 的代理转发功能，支持跨网段（如内网摄像头通过公网访问）的视频播放，解决了复杂的 NAT 穿透问题。
三、 视频流的全链路流转
为了让大家更清晰地理解视频从设备到 AI 的路径，我们模拟一次完整的“行人检测”业务流程。
3.1 数据流转拓扑
3.2 关键代码逻辑：流媒体代理
在 Java 后端中，通过调用 ZLM 的 RESTful API 实现流的控制。
伪代码示例：
@ServicepublicclassStreamProxyService{@AutowiredprivateZLMediaKitApiClientzlClient;/** * 添加代理流（对接国标或私有协议设备） */publicvoidaddProxyStream(CameraDevicedevice){Map<String,Object>params=newHashMap<>();// 1. 源地址（设备的RTSP地址）params.put("url",device.getRtspUrl());// 2. 流ID (映射为设备ID)params.put("stream",device.getDeviceId());// 3. 使能自动拉流params.put("enable_hls",true);params.put("enable_mp4",false);// 默认不开启录制// 发送指令到 ZLM 节点// ZLM 节点会自动拉取海康/大华的流，并转封装为 WebRTC/FLVzlClient.post("/index/api/addStreamProxy",params);}/** * AI 触发拉流（针对国标设备的懒加载策略） */publicvoidstartAiPull(Cameracamera){if(camera.getProtocol().equals("GB28181")){// 只有当算法开启时，才通知 ZLM 拉流zlClient.startPull(camera.getPushUrl());}}}四、 总结
YiheCode Server在协议兼容性上的设计，体现了一种“极简主义”的工程美学。
对于寻求低代码开发和私有化部署的技术决策者来说，这套架构的价值在于：
- 彻底的硬件解耦：不再受限于芯片厂商的 SDK，只要有 RTSP 或 GB28181 接口，就能接入。
- 资源的极致优化：通过“算法触发拉流”的机制，避免了“空跑”浪费服务器资源。
- 高可用的集群：基于 ZLMediaKit 的分布式架构，轻松应对千路级视频并发。
这种“协议统一化”的能力，正是它能够帮助企业“减少约 95% 开发成本”的基石——因为它把最复杂的“让摄像头出图像”的问题，变成了一个简单的配置动作。
架构师建议：
在接入老旧设备时，如果遇到 H.265 播放兼容性问题，请在 ZLM 配置中开启“自动转码 H.264”功能。同时，建议将 GB28181 设备的 SIP 端口与媒体端口进行分离配置，以避免端口冲突。