2. 核心需求分析：功能需求与非功能需求
好，咱们进入正题。需求分析这事儿，说白了就是搞清楚系统到底要干什么。我见过不少项目，上来就画架构图、选技术栈，结果做到一半发现连采集频率都没定下来——那后面全是白干。
所以这一节，我会把需求拆成三块来讲：功能需求、非功能需求、以及典型性能指标。这三块是设备监控系统的地基，地基不稳，上层建筑再漂亮也没用。
2.1 功能需求：系统要做什么
功能需求，就是用户能直接感知到的能力。我习惯把它归纳为三个核心：数据采集、告警、展示。你想想看，一个监控系统如果连这三点都做不好，那还监控个啥？
2.1.1 数据采集
这是最基础的一环。设备的数据怎么上来？用什么协议？采集频率多高？这些都是要提前定死的。
我在项目中遇到过最典型的问题：客户说“支持Modbus TCP就行”，结果现场设备一半是Modbus RTU串口，另一半是OPC UA。嗯，这就很尴尬了。
所以，数据采集层必须支持多种协议。我一般会列一个清单：
- 工业协议：Modbus TCP/RTU、OPC UA、PROFINET、EtherNet/IP
- 物联网协议：MQTT、CoAP、HTTP/HTTPS
- 私有协议：预留自定义解析接口
另外，采集频率要区分场景。温度传感器可能5秒一次就够了，振动信号可能需要毫秒级采集。千万别一刀切。
2.1.2 告警
告警是监控系统的“嗓子”。数据采集上来，如果没人看，那等于没采。告警要解决三个问题：什么时候告、怎么告、告给谁。
先说“什么时候告”。我建议设置多级阈值：
- 警告级：温度超过80°C，发通知，不处理也行
- 严重级：温度超过90°C，必须立即处理
- 紧急级：温度超过100°C，自动触发停机保护
再说“怎么告”。别只发短信或邮件，现在都2025年了，企业微信、钉钉、飞书都得支持。我有个项目，客户要求告警必须同时推送到3个渠道，还要能自定义升级策略——比如5分钟没人确认，自动升级给上级。
2.1.3 展示
展示层是用户直接打交道的界面。我个人的原则是：让数据自己说话。别搞花里胡哨的动效，用户要的是快速定位问题。
展示层一般包含：
- 实时仪表盘：关键指标的实时曲线、数字
- 历史趋势图：支持按时间范围、设备、指标筛选
- 告警列表：按时间、级别、状态排序，支持确认和备注
- 拓扑图：设备之间的连接关系，故障时高亮显示
这里我多说一句：展示层的延迟一定要低。用户点一下查询，3秒才出结果，那体验就很差了。后面我会讲怎么优化。
2.2 非功能需求：系统要跑得稳
功能需求决定系统“能不能用”，非功能需求决定系统“好不好用”。我把它归纳为三个关键词：高可用、低延迟、可扩展。
2.2.1 高可用
设备监控系统通常是7×24小时运行的。如果系统挂了，产线可能停摆，损失巨大。所以高可用是硬指标。
我一般要求做到：
- 服务冗余：关键服务至少部署2个实例，用负载均衡分发
- 数据持久化：采集的数据实时写入数据库，支持主从切换
- 故障自动恢复：服务挂了能自动重启，或者切换到备用节点
举个例子，我曾经给一个化工厂做监控系统，要求全年可用性99.99%。算下来，一年只能宕机52分钟。那怎么办？只能上多活架构，每个机房都部署一套，流量自动切换。
2.2.2 低延迟
低延迟分两个维度：数据采集延迟和展示延迟。
数据采集延迟，指的是从设备产生数据到系统收到数据的时间。对于实时性要求高的场景（比如电机振动监测），延迟必须控制在毫秒级。我常用的方案是边缘计算——在设备端先做初步处理，只把关键数据上传。
展示延迟，指的是用户操作到界面刷新的时间。这个我一般要求控制在500毫秒以内。如果超过1秒，用户就会觉得“卡”。
2.2.3 可扩展
系统不是一成不变的。今天接100台设备，明天可能接1000台。所以架构必须支持水平扩展。
我建议从这几个方面考虑：
- 采集层：支持动态增加采集节点，每个节点负责一部分设备
- 消息队列：用Kafka或RabbitMQ解耦采集和存储，吞吐量不够就加分区
- 存储层：时序数据库（如InfluxDB、TimescaleDB）天然支持分片和扩展
说白了，就是每个组件都能独立扩容，互不依赖。
2.3 典型性能指标：用数字说话
需求不能光说“要快”、“要稳”，得用数字量化。我列出三个最关键的指标：
| 指标 | 典型值 | 说明 |
|---|---|---|
| 采集频率 | 1秒 ~ 5分钟 | 根据设备类型动态调整，高频场景可到100ms |
| 告警延迟 | < 5秒 | 从数据异常到告警推送，含采集+判断+推送 |
| 并发量 | 1000 ~ 100000 台设备 | 取决于系统规模，单节点建议不超过5000台 |
这里我特别说一下并发量。很多人以为并发量就是“同时在线设备数”，其实不对。并发量指的是同时上报数据的设备数。10000台设备如果每5秒上报一次，那每秒的并发就是2000。这个数字直接决定了消息队列和数据库的选型。
2.4 知识体系总览
为了让你更直观地理解这一章的内容，我画了一张图。它把功能需求、非功能需求和性能指标串在了一起，方便你对照着看。
这张图把这一章的核心内容都串起来了。你可以看到，功能需求、非功能需求和性能指标是相互关联的。比如，采集频率这个指标，既影响数据采集的功能设计，也影响低延迟这个非功能需求。
好了，核心需求分析就讲到这里。下一节我们会进入架构设计，看看怎么把这些需求落地成具体的系统方案。