打破视频孤岛：基于 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)：

yaml 复制代码

zlm:
  # 主节点地址
  primary_node: http://192.168.1.10:8080
  # 从节点集群列表 (支持动态扩缩容)
  cluster_nodes:
    - id: worker_01
      url: http://192.168.1.11:8080
      max_streams: 100 # 限制单节点最大流数
    - id: worker_02
      url: http://192.168.1.12:8080
      max_streams: 100
  # 拉流策略：自动按最小数指定到一个ZLM节点
  pull_strategy: LEAST_CONNECTIONS

2.2 智能拉流与录制控制

为了避免无效的带宽占用和算力浪费，系统设计了精细化的拉流控制逻辑（参考文档架构说明）：

按需拉流 ：
- 对于手动新增的摄像头：录像控制程序定时检测，若需录像则主动拉流。
- 对于GB28181 国标流：不主动拉流，仅在 AI 算法启动需要分析时，才触发拉流动作。这极大地节省了内网带宽。
跨网播放：通过 ZLM 的代理转发功能，支持跨网段（如内网摄像头通过公网访问）的视频播放，解决了复杂的 NAT 穿透问题。

三、视频流的全链路流转

为了让大家更清晰地理解视频从设备到 AI 的路径，我们模拟一次完整的"行人检测"业务流程。

3.1 数据流转拓扑

GB28181
RTSP
RTSP
海康/NVR
ZLM 节点 1
大华/IPC
ZLM 节点 2
Onvif 设备
ZLM 节点 3
中心管理平台
AI 推理服务
告警/大屏

3.2 关键代码逻辑：流媒体代理

在 Java 后端中，通过调用 ZLM 的 RESTful API 实现流的控制。

伪代码示例：

java 复制代码

@Service
public class StreamProxyService {

    @Autowired
    private ZLMediaKitApiClient zlClient;

    /**
     * 添加代理流（对接国标或私有协议设备）
     */
    public void addProxyStream(CameraDevice device) {
        Map<String, Object> params = new HashMap<>();
        
        // 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/FLV
        zlClient.post("/index/api/addStreamProxy", params);
    }

    /**
     * AI 触发拉流（针对国标设备的懒加载策略）
     */
    public void startAiPull(Camera camera) {
        if(camera.getProtocol().equals("GB28181")) {
            // 只有当算法开启时，才通知 ZLM 拉流
            zlClient.startPull(camera.getPushUrl());
        }
    }
}

四、总结

YiheCode Server 在协议兼容性上的设计，体现了一种"极简主义"的工程美学。

对于寻求低代码开发 和私有化部署的技术决策者来说，这套架构的价值在于：

彻底的硬件解耦：不再受限于芯片厂商的 SDK，只要有 RTSP 或 GB28181 接口，就能接入。
资源的极致优化：通过"算法触发拉流"的机制，避免了"空跑"浪费服务器资源。
高可用的集群：基于 ZLMediaKit 的分布式架构，轻松应对千路级视频并发。

这种"协议统一化"的能力，正是它能够帮助企业"减少约 95% 开发成本"的基石------因为它把最复杂的"让摄像头出图像"的问题，变成了一个简单的配置动作。

架构师建议 ：

在接入老旧设备时，如果遇到 H.265 播放兼容性问题，请在 ZLM 配置中开启"自动转码 H.264"功能。同时，建议将 GB28181 设备的 SIP 端口与媒体端口进行分离配置，以避免端口冲突。