博客

企业环保数字化监管：从边缘采集到云原生部署

环保监管技术架构技术架构总览

整体分层模型

一套可落地的监管系统，通常划分为设备层、边缘层、数据层、平台层、应用层和运维安全层。

设备层连接废气、废水、噪声、能耗和视频监控设备，负责获取企业现场的原始数据。

边缘层部署工业网关或边缘服务器，完成协议转换、数据清洗、断点续传和本地联动。

数据层承担时序数据、业务数据、文件数据和空间数据的分类存储，并建立统一数据标准。

平台层提供设备管理、规则计算、报警处理、工单流转、报表服务和第三方系统集成能力。

应用层面向监管部门、企业管理者和运维人员，提供不同视角的网页端与移动端应用。

运维安全层贯穿所有层级，覆盖身份认证、访问控制、日志审计、备份恢复和安全监测。

架构图中的数据流

现场仪表通过RS485、以太网、4G或5G接入网关，再由网关向中心平台发送标准数据。

实时监测数据进入消息队列，经过规则引擎处理后，分别写入时序库和报警事件库。

视频、图片和检测报告进入对象存储，业务记录则写入关系型数据库。

应用端不直接访问数据库，而是通过API网关调用服务，避免数据接口失控。

监管指令沿反向链路下发，可触发现场声光报警、设备控制或运维工单。

数据上行与指令下行必须分开授权，防止普通查询账号误操作生产设备。

技术选型理念

技术选型不能只看产品功能，还要计算五年周期内的采购、实施、扩容和运维成本。

设备数量少于500台时，可采用单体服务加模块化设计，降低早期部署复杂度。

设备达到数千台后，应引入微服务、消息队列和分布式时序数据库。

选型时需要确认国产操作系统、国产数据库、信创环境及私有化部署的适配能力。

核心组件要支持横向扩容，新增企业和监测点时不应重做系统架构。

采购经理问“多少钱”时，应按点位数、数据频率、保存周期和并发用户量进行核算。

环保监管技术架构数据层架构

数据采集方案

数据采集要覆盖在线监测仪、PLC、DCS、智能电表、流量计、摄像机和门禁设备。

常见工业协议包括Modbus RTU、Modbus TCP、OPC UA、BACnet和IEC 104。

平台侧可采用MQTT、HTTPS或TCP长连接，减少不同设备厂商带来的接入差异。

一个点位每分钟上报一次，一年约产生52.56万条记录，容量规划必须按实测频率计算。

对秒级采样设备，可在边缘端完成聚合，只上传均值、最大值、最小值和异常值。

网关需要具备本地缓存能力。网络中断时持续保存数据，恢复后按时间顺序补传。

每条数据应带设备编号、点位编号、采集时间、接收时间和质量码。

采集时间用于还原现场状态，接收时间用于判断链路延迟，二者不能混用。

怎么做设备接入验收？可检查协议一致性、时间同步、丢包率和断网补传完整率。

建议将丢包率控制在0.1%以内，网关缓存周期不少于7天。

数据存储设计

业务配置、企业档案、工单和用户信息适合存入MySQL、PostgreSQL等关系型数据库。

高频监测值适合使用时序数据库，按设备、点位和时间建立索引。

图片、视频、检测报告及执法附件可进入S3兼容对象存储，数据库仅保存文件地址。

行政区划、厂区边界、排口坐标等空间数据，可使用PostGIS统一管理。

热数据可保存3至6个月，用于实时查询；冷数据转入低成本存储，保存3至5年。

采用按月分区或按企业分片的方式，可避免单表记录达到亿级后查询性能下降。

存储层需要配置读写分离，但监管告警、处置状态等关键业务要保证强一致性。

原始数据不能被更新覆盖，修正值应作为新版本保存，并记录修改原因。

为了控制成本，可对秒级数据做分层压缩，同时保留分钟、小时和日统计结果。

容量估算还要计算索引、备份和副本空间，实际采购量通常是原始数据量的3至5倍。

数据治理策略

数据治理重点不是补一份文档，而是把标准直接落实到采集和接口流程中。

企业、排口、设备、污染因子和行政区划需要建立统一编码，避免一物多码。

量纲必须标准化，例如浓度统一使用毫克每立方米，流量统一使用立方米每小时。

数据质量规则应识别缺失、恒值、突变、越界、倒流、时间漂移和设备离线。

异常数据不能简单删除，应保留原值、质量标签、处理结果及责任人信息。

平台可按完整性、及时性、准确性生成质量评分，为设备维护提供量化依据。

环保监管技术架构平台层架构

微服务架构设计

平台可按设备接入、企业档案、监测数据、规则告警、工单和报表拆分服务。

服务边界应围绕业务能力划分，不要按数据库表机械拆分。

设备接入服务关注连接稳定性，告警服务关注规则计算，两者扩容方式并不相同。

注册中心负责服务发现，配置中心统一管理数据库地址、阈值和环境参数。

API网关承担路由、鉴权、限流和审计，外部系统不应直接访问内部服务。

服务之间优先使用REST或gRPC，异步事件则通过消息队列传递。

每个服务应独立发布、独立扩容、独立回滚，减少一次升级影响全平台。

微服务数量也不能过多。一个10人团队维护数十个服务，会显著增加排障成本。

项目早期可采用模块化单体，待设备量和团队规模达到阈值后再拆分。

服务拆分前要建立链路追踪和自动化发布，否则故障定位时间可能从分钟变成小时。

消息中间件选型

MQTT适合设备接入，支持低带宽、长连接、心跳检测和不同服务质量等级。

Kafka适合海量数据流和历史重放，常用于监测数据分发与实时计算。

RabbitMQ适合工单、通知等业务消息，路由机制清晰，确认模式成熟。

选型要看每秒消息量、单条消息大小、积压时间和是否需要顺序消费。

报警消息建议配置持久化和消费确认，避免服务重启时丢失关键事件。

同一设备的数据可按设备编号分区，保证局部有序，同时提升并行处理能力。

缓存与性能优化

企业列表、设备档案、行政区划和规则配置可以缓存到Redis，减少数据库压力。

实时看板不应每次读取全部明细，可预计算分钟级统计结果并缓存查询结果。

缓存键需要包含租户、企业和业务类型，防止不同组织之间发生数据串读。

对热点数据设置5至30分钟过期时间，配置数据变更后主动清理缓存。

告警计算可采用流式处理，将固定窗口和滑动窗口规则部署到实时计算引擎。

查询接口应强制分页，并限制单次时间范围，避免用户一次导出数亿条数据。

大批量报表采用异步任务生成，完成后通过站内消息通知下载。

性能指标要在合同中量化，例如95%的查询响应时间不超过2秒。

压力测试应覆盖设备集中上报、报警风暴、批量补传和多人报表导出等场景。

平台扩容怎么做，要提前验证无状态服务扩容、数据库分片和消息分区调整流程。

环保监管技术架构应用层架构

前端技术方案

管理端可采用Vue或React构建，配套TypeScript降低大型项目中的类型错误。

大屏展示可使用ECharts、地图引擎和WebSocket，实时更新排口及报警状态。

地图组件要支持企业分布、污染源热力、河道流向和区域边界叠加。

移动端可采用原生应用、跨端框架或企业微信，根据离线需求和硬件调用能力选择。

现场运维场景经常遇到弱网，移动端应缓存工单、设备档案和巡检表单。

实时曲线只加载可视范围内的数据，缩放后再请求对应时间粒度。

页面组件要统一指标口径，避免大屏、报表和移动端显示不同结果。

API设计规范

API建议采用REST风格，资源名称使用名词，并统一版本号、状态码和返回结构。

查询接口必须支持分页、排序、时间范围和企业维度过滤。

写入接口需要配置幂等键，防止网关重试造成监测数据重复入库。

设备数据批量上报时，应限制单批数量和报文大小，避免占满服务线程。

开放接口通过网关发布，并配置调用方标识、签名、时间戳和随机数。

接口文档可使用OpenAPI自动生成，参数变更需要保留兼容期。

调用日志应记录请求方、接口名称、响应时间和结果状态，但不能明文保存密码。

权限与安全机制

权限体系可以采用RBAC模型，并增加企业、区域、项目等数据权限条件。

监管人员查看辖区企业，集团用户查看下属工厂，企业账号只能查看自身数据。

敏感操作需要二次确认，并记录操作人、时间、来源IP和变更前后内容。

用户密码、设备密钥和数据库凭据应加密保存，不能写入代码仓库。

外网访问应启用HTTPS，设备通信可使用双向证书或设备级密钥。

对连续登录失败、异常地点登录和高频接口调用设置自动阻断策略。

权限校验必须在服务端完成，前端隐藏按钮不能替代安全控制。

环保监管技术架构部署架构与运维

部署方案选择

环保监管技术架构可部署在政务云、公有云、企业私有云或本地数据中心。

单厂项目可以使用虚拟机加容器，减少Kubernetes带来的额外维护工作。

多区域、多租户项目适合采用Kubernetes，统一处理扩容、发布和故障迁移。

生产、测试和开发环境应隔离，数据库账号、消息主题和对象存储桶不能共用。

边缘侧可部署轻量容器平台，统一更新采集程序和协议驱动。

采购时需要明确服务器、操作系统、中间件授权、实施和年度运维分别多少钱。

如果监管数据不能出园区，可采用本地计算加中心汇总的混合部署方式。

监控与日志体系

基础监控应覆盖CPU、内存、磁盘、网络、容器状态和数据库连接数。

业务监控还要关注在线设备数、数据延迟、丢包率、报警量和工单完成率。

Prometheus可采集指标，Grafana负责看板，日志可进入ELK或Loki体系。

每次请求应生成唯一追踪编号，用于串联API网关、服务、消息和数据库日志。

告警要设置分级。磁盘容量超过80%可以预警，核心服务不可用需要立即通知。

通知渠道可接入短信、电话、邮件和企业微信，并配置值班升级机制。

日志保存周期要结合法规与审计要求，安全日志通常需要保存6个月以上。

容灾与备份策略

数据库可采用主从复制或高可用集群，避免单节点故障导致平台停机。

消息队列至少部署3个节点，副本数量根据业务可靠性要求设置。

备份策略应包含每日增量、每周全量和异地副本，并定期执行恢复演练。

只检查备份文件是否存在没有意义，恢复时间和数据完整性才是验收指标。

关键业务可设定RPO不超过15分钟、RTO不超过2小时。

边缘网关在中心平台中断时继续采集，恢复连接后完成有序补传。

跨机房部署要评估网络延迟，避免数据库同步链路反过来拖慢生产业务。

上线前应模拟服务器宕机、数据库切换、消息积压和机房断网。

通过演练记录恢复步骤、耗时和问题，形成可执行的应急预案。

声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：sales@idmakers.cn删除，任何个人或组织，需要转载可以自行与原作者联系。