动环监控软件

1. 立项背景和目标
传统机房运维长期依赖 24h 人工巡检，动力、环境、安防各成一套独立子系统，告警响应慢、值班记录手写难以追溯、出事无法定责；而关键信息基础设施机房又有"7×24 实时监测、关键事件留痕可审计"的硬性要求。我们希望做一个统一平台，把动力（UPS、配电、空调）、环境（温湿度、漏水、烟雾、门禁）、告警、运维工单全流程打通，并把关键证据上链，解决"现场说不清、事后追不回来"的痛点。
2. 软件功能与核心模块
① 实时采集网关：适配 Modbus RTU/TCP、SNMP、DL/T 645、DI/DO 干接点等异构协议，统一抽象为"测点"模型；
② 2.5D / 三维动环图：机房全景可视化，设备定位、温湿度热力图、配电链路联动；
③ 告警引擎：阈值、复合、趋势三类规则，分级通知（短信、语音、邮件、企业微信/钉钉）；
④ 运维工单：告警→派单→处理→销警闭环，全流程留痕，可审计；
⑤ 区块链存证：严重告警、巡检签到、设备配置变更的哈希上链（联盟链），原文存 IPFS；
⑥ 设备/资产管理：设备台账、维保周期、生命周期；
⑦ 报表中心：能耗、告警趋势、SLA、可用率。
3. 业务流程
现场设备 → 边缘网关协议转换 → MQTT Broker 接入 → Go 后端 → 时序库（InfluxDB/TDengine）+ 关系库（PostgreSQL）→ 告警判定 → 通知 / 工单 / 上链 → Web 看板展示。
4. 功能路径
登录（管理员 / 运维 / 巡检 / 访客，权限分级）→ 总览看板（实时态势地图）→ 进入单机房动环图 → 查看测点趋势与实时告警 → 接单处理工单 → 上传处置证据与复核销警 → 报表导出与签名留档。

1. 整体架构与技术栈
采用端-边-云分层：
· 端：智能传感器与动环设备；
· 边：边缘网关（协议转换、本地缓存、断线续传）+ EMQX 作为 MQTT 消息总线；
· 云：Go 后端按职责拆 5 个微服务——collector-service（采集）、alarm-service（告警引擎）、ops-service（工单/运维）、chain-service（区块链网关）、api-gateway（BFF），存储用 InfluxDB / TDengine（时序）+ PostgreSQL（业务）+ Redis（缓存 / 会话）+ 联盟链（FISCO BCOS）+ IPFS（原文存证）；
· 前端：Vue 3 + TypeScript + Vite + ECharts + Three.js（机房 3D）；
· 部署：Docker Compose 一键起，K8s 平滑迁生产。
2. 我负责的模块与可量化结果
我作为主后端开发，独立负责 collector-service、alarm-service、chain-service 三个核心模块的从 0 到 1 实现。关键指标：
· 单实例支撑 8000 测点 / 5s 全量采集，服务 QPS 1.2 万，日处理时序数据约 6000 万条；
· 告警端到端判定延迟 P95 < 1.2 s（采集 → 判定 → 通知）；
· 关键证据上链平均 2.3 s，含批量打包默克尔根入链；
· 试点客户机房上线半年，月均告警 1200+，误报率从行业常见的 ~8% 降到 1.6%，人工巡检工时下降约 40%。
3. 我遇到的难点、坑与解决方案
① 协议碎片化：在线设备 200+ 型号，每家寄存器表都不一样，新型号接入要两周。→ 设计"设备驱动插件"模型，用一份 manifest JSON 描述寄存器映射和采集周期，把新设备接入压缩到一天。
② 弱网下网关告警风暴：现场 Modbus 长连接反复断，重连瞬间把网关打挂。→ 网关本地缓存最近 30 分钟数据，断线恢复后批量补传、去重，服务端用消息幂等键兜底。
③ 告警规则爆炸：规则堆到上万条时 CPU 成为瓶颈。→ 把"测点-规则"预编译为倒排索引 + 布隆过滤器，热规则常驻内存，并按机房分片并行判定。
④ 上链吞吐与成本：所有告警全上链会把区块塞爆。→ 本地按严重等级过滤，仅把严重告警哈希（默克尔根）入链，原文存 IPFS，可验证但不臃肿。
⑤ 大屏渲染卡顿：500+ 设备同屏时浏览器掉帧。→ Canvas 分层 + 视口剔除 + 热点元素 WebGL 化，FPS 稳定在 60。