协议融合与边缘协同：基于 GB28181/RTSP 的企业级 AI 视频中台架构解析

引言：多品牌设备的"战国时代"

在复杂的工业现场与智慧城市项目中，架构师面临的最大挑战往往是存量设备的整合 。客户现场可能同时存在海康的 IPC、大华的 NVR、宇视的平台服务器，甚至还有老旧的 Onvif 设备。传统的视频管理平台（VMS）往往需要针对每种协议写一套驱动，开发周期长，维护成本极高。

如果能有一种架构，能够像"万能翻译"一样，将 GB28181、RTSP、RTMP 等协议统一纳管，实现从"设备接入"到"AI 分析"的全流程解耦，将能为企业节省巨大的研发成本。今天，我们将深入解析 YiheCode Server 的接入层架构，看它如何通过标准化的流媒体设计，兑现"减少 95% 开发成本"的承诺。

一、接入层架构：协议无关的流媒体设计

YiheCode Server 的核心设计理念在于**"信令与媒体分离"。系统并不直接与物理摄像头硬编码交互，而是构建了一层流媒体代理网关（Media Gateway）**。

其工作流如下：

信令层：负责与设备握手（GB28181 注册、RTSP Describe、Onvif Probe）。
拉流层：根据信令获取的地址，统一拉取 RTSP/RTMP 流。
转封装层：将拉取到的 H.264/H.265 流统一转封装为平台内部标准的 FLV 或 RTC 格式。
分发层：将标准流分发给播放器、录像模块或 AI 推理模块。

这种设计使得上层业务（如算法分析、录像存储）完全不需要感知底层设备的品牌和协议差异。

二、核心解密：多协议统一接入与边缘推流

2.1 GB28181 国标设备的智能化纳管

对于符合 GB/T 28181-2016 标准的设备，系统通过独立的国标信令服务 进行管理。系统支持跨网域的级联，能够自动发现下级平台的摄像头资源。

自动分配策略：根据 Gitee 仓库文档中的架构图，当新增国标流时，系统会自动按照"负载最小"原则，将流分配给 ZLMediaKit 节点。
被动/主动拉流机制 ：
- 对于手动新增的摄像头，录像控制程序会主动拉流并录制。
- 对于国标流 ，系统默认不主动拉流（避免信令风暴），仅在算法启动时，由边缘节点主动发起拉流请求。

GB28181 设备接入配置逻辑：

json 复制代码

{
  "device_type": "GB28181",
  "sip_server": {
    "host": "192.168.1.100",
    "port": 5060,
    "id": "34020000001320000001",
    "password": "123456"
  },
  "media_proxy": {
    "node_id": "zlm_node_01", // 指定代理节点
    "auto_pull_stream": false // 算法触发时再拉流
  }
}

2.2 RTSP/RTMP 的边缘推流与智能调度

对于非国标设备（如 RTSP 流地址、RTMP 推流），系统提供了极其灵活的边缘推流模式。这在处理大量分散的前端设备时尤为关键。

边缘推流的工作机制：

边缘盒子（Edge Box）：部署在前端的 ARM 设备，负责从老旧 IPC 拉取 RTSP 流。
协议转换：边缘盒子将拉取到的 RTSP 流，重新推送到中心的 ZLMediaKit 服务器（RTMP 或 RTC 协议）。
中心统一调度：中心平台只认 ZLMediaKit 的流地址，不再关心原始设备的网络位置。

ZLMediaKit 节点分配算法（伪代码）：

python 复制代码

def allocate_zlm_node(camera_list):
    """
    根据最小负载原则分配 ZLM 节点
    """
    zlm_nodes = get_online_zlm_cluster() # 获取在线集群
    
    for camera in camera_list:
        # 策略：按当前节点的流数量排序
        best_node = min(zlm_nodes, key=lambda node: node.stream_count)
        
        if camera.protocol == "GB28181":
            # 国标流：仅注册，不主动拉流
            register_to_sip_server(camera, best_node)
        else:
            # 非国标流（RTSP/RTMP）：直接下发拉流指令
            best_node.start_pull(camera.source_url)
            
        camera.assigned_node = best_node.id
        log.info(f"摄像头 {camera.name} 已分配至节点 {best_node.ip}")

三、部署实战：基于 ZLMediaKit 的流媒体集群

根据开源文档中的《新系统架构》图示，YiheCode Server 采用了 ZLMediaKit 作为核心流媒体服务。为了应对高并发场景，我们需要构建一个高可用的流媒体集群。

3.1 流媒体集群拓扑

text 复制代码

[ 中心管理平台 ]
       |
       | (HTTP/MQTT 控制信令)
       v
[ ZLMediaKit 集群 ]
   |-- Node 1 (负责 1-100 路摄像头) -> 录像存储 MinIO
   |-- Node 2 (负责 101-200 路摄像头) -> 录像存储 MinIO
   |-- Node 3 (边缘节点，负责拉取外网 RTSP) -> 推流至中心
       |
       | (RTSP/RTMP 拉流)
       v
[ 物理设备层 ]
   |-- 海康威视 IPC (RTSP)
   |-- 大华 NVR (GB28181)
   |-- 手机直播 (RTMP)
   |-- 无人机 (RTSP)

3.2 关键配置参数 (application.yml)

yaml 复制代码

zlm:
  # 流媒体节点配置
  media_server:
    - id: "node_01"
      ip: "192.168.10.101"
      http_port: 80
      rtmp_port: 1935
      secret: "035c73f7-b6ed-4792-99be-4c0a3c5e8e5e" # 鉴权密钥
    - id: "node_02"
      ip: "192.168.10.102"
      http_port: 80
      rtmp_port: 1935
      secret: "035c73f7-b6ed-4792-99be-4c0a3c5e8e5e"

  # 摄像头分配策略配置
  camera_strategy:
    # 固定分配模式：手动指定
    assign_mode: "FIXED" 
    # 或者 最小负载模式：auto
    # assign_mode: "MIN_LOAD"

  # 录像控制策略
  record:
    check_interval: 300 # 5分钟检查一次录像状态
    enable: true
    # 对于国标流，收到算法告警后才上传文件到对象存储
    upload_on_alarm: true

四、总结

YiheCode Server 在协议兼容性上的设计非常具有工程智慧。

它通过**"国标信令服务 + ZLMediaKit 流媒体代理"**的组合，完美解决了安防行业最头疼的"多品牌设备接入"难题。无论是标准的 GB28181，还是私有的 RTSP，亦或是复杂的跨网域环境，都能通过这套架构实现统一的视频流处理。

对于集成商而言，这意味着你不再需要为每一种新品牌的摄像头去研究 SDK，只需要确保它能输出标准视频流，系统就能自动完成接入、转码和分发。这种**"协议无关"**的架构，正是它能大幅降低开发成本、加速项目交付的关键所在。

🚀 演示环境与部署资源

如果您正在寻找一套能够真正落地、支持多种硬件环境的 AI 视频管理方案，请参考以下信息：

开源地址 ：Gitee - YiheCode Server

架构师建议 ：

在处理海量摄像头接入时，请务必部署 ZLMediaKit 集群。利用文档中提到的"最小负载分配策略"，可以有效避免单台流媒体服务器过载，确保视频流的稳定性。对于纯内网环境，建议在内网部署边缘 ZLM 节点，仅将关键视频流回传至中心。