第2章系统总体架构设计

第二章：系统总体架构设计——分层架构与模块交互

好，咱们直接进入正题。智能安防视觉系统，说白了就是把摄像头拍到的东西，变成有用的信息，再做出反应。这个链条看着简单，但真要落地，架构设计就是地基。地基不稳，后面全是坑。

我个人习惯，做系统架构先画分层图。为什么？因为分层能解耦。每一层只关心自己的事，出了问题也好定位。你想想看，如果所有代码揉在一起，摄像头采集、网络传输、算法分析、报警推送全在一个模块里，那改一个地方可能就崩一片。我早期一个项目就吃过这个亏，后来老老实实分层了。

咱们这套系统，我把它分成四层。不多不少，刚好够用。

嗯，这里要注意：分层不是绝对的。比如边缘计算场景下，感知层和分析层可能会合并在一个边缘设备上。但架构设计时，逻辑上还是要分开，方便后续扩展。

感知层是系统的眼睛。很多人觉得就是装个摄像头，其实没那么简单。

我在项目中遇到过，某工厂的摄像头装好了，但晚上画面全是噪点，算法根本跑不起来。后来发现是选型时没考虑低照度场景。所以感知层设计，我建议至少考虑三点：

小技巧： 如果摄像头支持ONVIF协议，尽量用。它能让你的感知层设备接入更标准化，省去很多适配的麻烦。

传输层是系统的血管。数据流不通，分析层再强也没用。

常见的传输方案有两种：

我个人的经验是：视频流走RTSP，事件数据走消息队列。两者互补，别混用。曾经有个团队把视频帧也塞进Kafka，结果消息体太大，队列直接堵死了。嗯，这是个教训。

传输层还有一个关键点：协议转换。不同厂商的摄像头可能用不同的协议，你需要一个统一的网关来适配。我一般用GB28181作为国标协议，再转成内部统一的RTSP流。

分析层是核心。它接收传输层送来的数据，跑算法模型，输出事件结果。

分析层的模块划分，我建议这样：

避坑指南： 我曾经在分析层犯过一个错——把AI推理和规则引擎放在同一个进程里。结果模型推理卡住时，整个规则引擎也挂了。后来改成独立进程+消息通信，问题就解决了。记住：分析层内部也要解耦。

应用层是系统的脸面。用户不关心你底层用了什么算法，只关心好不好用。

应用层我一般分三个子模块：

你想想看，如果用户点开告警记录，要等3秒才看到画面，那体验就太差了。所以应用层要跟传输层配合好，预加载关键帧。

光说分层还不够，咱们得看看数据到底怎么流。我画一个典型的交互流程：

感知层（摄像头） 
    ↓ RTSP视频流
传输层（流媒体网关） 
    ↓ 解码后的帧数据（通过消息队列）
分析层（AI推理引擎 → 规则引擎） 
    ↓ 事件结果（JSON格式）
传输层（事件消息队列） 
    ↓ 
应用层（告警管理 → 用户界面）

这个流程里，有几个关键点：

注意： 如果分析层处理速度跟不上感知层的采集速度，就会造成数据积压。我建议在传输层加一个“背压”机制，当队列满了就丢弃旧帧，保证实时性。别让旧数据把系统拖死。

最后说点实在的。架构没有完美的，只有适合的。比如：

我记得有一次做智慧园区项目，客户要求所有告警延迟不超过1秒。我们最后把分析层直接部署在边缘服务器上，传输层只做事件上报，视频流不走网络。嗯，效果很好。

好了，这一章就到这里。下一章咱们聊聊感知层的具体选型和部署细节。有什么问题，欢迎交流。