★ FEATURED ARTICLE 见过太多类似的场景设备端的传感器、PLC、仪表都调试通了数据也能上报了结果卡在平台选型上。找现成的云平台功能确实全可就是太重了部署要好几台服务器定制一个字段要等厂商排期数据还不好迁出来完全从零自研又得折腾协议解析、消息并发、时序存储这些跟业务关系不大、但哪一个都绕不开的底层问题。后来我把自己在几个项目里沉淀下来的轻量级物联网方案整理成了开源项目UNIHH-IOT前后端代码全部开源核心目标就一个让工业数字化转型项目用得起、跑得动、改得动。这篇文章会把这套平台的架构设计、部署流程、设备接入实操和二次开发路径完整地梳理一遍给正在做方案选型或者准备自建物联网平台的朋友一个能直接参考的路线。先说清楚一件事UNIHH-IOT不是什么功能堆砌的大杂烩。它聚焦在工业物联网最核心的四件事上设备接入、数据存储、告警通知、可视化展示。在这个范围里做到够用、好用、可扩展而不是急着把MES、ERP、BI全都塞进来。轻量级不是功能少而是复杂度可控高性能也不是单纯堆机器而是用合理的设计把钱花在刀刃上。1. 先聊清楚工业物联网平台到底该不该“轻”我见过太多项目把平台选得又重又豪华最后项目不是死在设备接入上而是死在平台本身的复杂度上。重平台在大型集团项目里可能是必要条件但在大量中小规模场景里反而是最需要警惕的坑。1.1 重平台为什么在中小项目里容易翻车第一个问题是硬件成本和运维成本。一个产线监测项目可能只有几十台设备、几百个点位数据量远没有想象中那么大但平台侧动不动就要求几台高配服务器还要配专门的运维人员。要知道工业项目的利润本来就不算厚预算大头已经花在传感器、网关和施工上了留给平台的钱很有限。第二个问题是学习曲线。重平台通常有自己的一套配置体系和术语体系新来的人要学很久才能上手项目交付后企业自己没人能维护后续每次改动都要靠外部团队时间成本和费用都不可控。第三个问题是定制闭环。大平台改一个字段、加一种存储策略、对接一套内部系统常常要等厂商排期一个很简单的需求排到几个版本之后业务早就等不及了。1.2 UNIHH-IOT的定位边缘友好、云端可扩UNIHH-IOT的定位正好卡在“小项目不浪费、大项目能扩展”这个区间。最低配置2核4G内存就能把后端服务、时序数据库、前端页面全部跑起来普通工控机或者一台闲置服务器就能撑起一个小型车间的监控需求。等设备数量上来之后接入服务可以单独拆出来部署通过负载均衡横向扩展数据存储层也能从单机平滑演进到集群。这种设计照顾了两类项目一种是预算有限、希望一次部署长期运行的中小项目另一种是前期规模不大、但后期明确会扩容的成长型项目。两条路都能走不用一上来就赌一个庞大架构。1.3 全开源带来的三个直接优势“前后端全开源”这个点实际项目里的价值远不止省授权费。首先是安全性可控代码都在自己手里有漏洞可以自己审计修复不用担心闭源系统的黑盒风险尤其政企项目对外包代码做安全评估时全开源能省掉大量沟通成本。其次是集成自由工业现场往往要对接MES、ERP、协同办公工具还有一堆内部定制的业务系统这些对接没人比内部团队更熟悉有了源码想加接口就加接口想改逻辑就改逻辑。第三是成本结构透明没有按连接数收费的授权费没有“高级功能”付费墙预算可以提前算清楚不会突然冒出额外账单。对很多企业来说这三点比任何花哨的功能都实在。2. 核心架构拆解高性能和轻量靠什么撑起来轻量不等于简陋。一个平台能跑起来不难难的是在低配置下还能扛住工业设备高频上报的压力。UNIHH-IOT的架构思路可以概括成四层设备接入层、消息路由层、数据存储层、业务与展示层。2.1 模块划分接入、路由、存储、展示各管一段接入层负责协议解析像Modbus、OPC UA、MQTT、泛化的HTTP上报都放在这一层以插件形式注册。消息路由层处理设备上下线、消息分发和简单的规则前置判断比如某些点位在进存储之前先做阈值过滤。数据存储层同时使用时序数据库和关系库点位历史数据进时序库设备元数据、用户权限、告警记录进关系库。业务与展示层通过统一API取数不直接操作数据库。这样拆的好处是边界清楚换数据库、加协议、改前端都不会牵一发动全身。如果哪一层出了问题排查范围也能迅速缩小。2.2 设备接入层协议插件化与线程模型接入层最忌讳把所有协议解析逻辑写在一个大类里会导致互相耦合、难以测试、上线容易出问题。UNIHH-IOT把每个协议设计成独立插件比如modbus-tcp、opc-ua、mqtt、dl645通过配置动态加载。协议插件和主服务之间定义好统一接口新增协议只需要在插件层做适配主服务代码不用动。线程模型上网络读写使用少量长连接线程协议解析不阻塞IO线程避免某台设备交互卡住拖累整个接入服务。这块的代码逻辑大致是这样的public interface ProtocolProcessor { // 协议标识比如 modbus-tcp、opc-ua String protocolName(); // 设备连接建立后完成初始化 void onConnected(DeviceSession session); // 处理平台下发给设备的指令 void onCommand(DeviceSession session, CommandPayload payload); // 处理收到的原始报文解析后交给消息路由层 void onData(DeviceSession session, byte[] rawData); }插件化之后项目的接入能力扩展就变成了一个“按插件开发”的常规任务很多现场遇到的私有协议也能快速接入不会因为改主流程而引入新的风险。2.3 数据层选型时序库加业务库的搭配工业物联网的数据特征非常明显写入量大、读取集中在最近一段时间、需要按时间聚合计算。普通关系库在千万级点位数据面前很容易出现写入瓶颈查询聚合也要花不少功夫。专门为时序数据设计的存储引擎在写入吞吐、分区策略、数据压缩上都做了针对性优化能省下大量存储空间。UNIHH-IOT默认采用开源时序数据库TDengine存点位历史数据用关系库存业务数据。点位比较少的项目可以只用关系库但点位一旦超过一万个强烈建议老老实实把时序数据独立出来否则后面做报表、做趋势分析的时候性能差距非常明显。2.4 前端和后端的通信方式前端采用Vue技术栈业务数据走RESTful API实时点位和告警推送走WebSocket。大屏页面如果点位很多前端不会每秒钟把全量数据重新拉一遍而是订阅增量变化后端把同一时间点变化的点位打包推送过来这样带宽占用和页面刷新频率都能压下来。用这个思路做几百个点位的大屏页面流畅度会明显好于轮询方案。前端页面和后端服务之间只走API契约也方便以后把页面替换成企业自己的定制界面不改动后端逻辑。3. 部署一套UNIHH-IOT从空机器到跑通全流程部署这块其实没那么神秘但确实有一些细节容易踩坑。下面按照实际动手的顺序把从准备到验证的完整流程过一遍。3.1 最小部署硬件清单以车间级规模来算几十台设备、几千个点位用2核4G内存的虚拟机或工控机就够了。如果点位规模再大一点建议数据存储服务单独给一台4核8G的机器磁盘用SSD。这里特别想提醒一句时序数据写盘非常频繁机械硬盘在高频写入下延迟会明显升高别在这个地方省成本。如果现场需要串口采集Modbus RTU设备还得配一个串口服务器或者USB转485模块平台侧通过网络访问串口服务器。角色建议配置主要用途核心服务2核4G以上后端服务、告警引擎、API接口数据存储4核8GSSD时序库、关系库前端静态资源1核1GNginx托管静态页面边缘接入网关可选2核4G协议解析、本地缓存、断网续传这个清单不是一个绝对值而是给“刚刚够用”一个参考。真到项目里我会先按上表估算再留出一倍的余量避免业务增长后马上又得换机器。3.2 基于Docker Compose的一键拉起UNIHH-IOT仓库里提供了完整的容器编排文件本地只要装了Docker和Docker Compose一条命令就能启动整套服务。services: unihh-tsdb: image: tdengine/tdengine:3.0 environment: - TAOS_FOObar volumes: - tsdb-data:/var/lib/taos unihh-core: image: unihh/iot-core:latest ports: - 8088:8088 - 1883:1883 unihh-web: image: unihh/iot-web:latest ports: - 80:80 volumes: tsdb-data:实际部署时要注意一个常见的坑很多工业现场是纯内网环境无法直接访问外部镜像仓库。我的建议是在有网络的环境下先把镜像pull下来再用docker save打成tar包拷进生产环境后用docker load导入。这一步能省去大量现场网络问题尤其是项目时间紧的时候非常管用。3.3 配置文件和初始化步骤核心配置文件主要三个部分数据库连接信息、接入服务监听端口、前端可访问的API地址。初始化步骤也不复杂先把时序库和关系库的表结构初始化好创建默认管理员账号然后在平台上创建一个产品定义物模型。物模型的作用会在下一节详细展开这里先理解成设备的“数据说明书”就行。初始化完用浏览器访问前端地址能正常登录就说明后端和数据库之间通信正常。3.4 验证部署是否健康的三个指标部署完成后别急着大批量接设备先用最小代价验证三个指标。第一服务能不能持续稳定运行连续观察十几分钟看有没有进程退出、内存溢出或者连接被重置的报错。第二日志里有没有周期性噪声比如数据库连接池不够用、磁盘空间告警、Redis连接失败这类这些噪声会在设备量上来之后被无限放大。第三用自带的设备模拟器发一条MQTT数据确认点位变化能实时出现在前端页面上告警规则也能正常触发。三步走通后整个平台的核心链路就验证过了再开始大规模接入设备心里才有底。4. 设备接入实操Modbus和MQTT两条主流路线工业协议非常多但真实项目里碰到最多的还是Modbus和MQTT。Modbus用来从PLC、仪表、电表里采集数据MQTT用来做设备状态上报和平台下发指令。把这两条路线走通整个接入逻辑基本就通了。4.1 通过物模型先定义设备是什么物模型可以理解成给设备立一份标准的数据说明书定义设备有哪些属性、哪些可读可写、哪些指令可下发。设备接入之前先要在平台上建产品产品下面再挂具体设备。设备唯一标识一般叫DeviceKey后续所有消息都会带上这个字段。属性定义时要写清楚数据类型和单位比如温度是float、单位是℃压力是float、单位是MPa。这样后续告警规则、可视化图表都能自动读取这些定义不用每个页面再配一遍。{ productKey: air_compressor, productName: 空压机监测, properties: [ { code: pressure, name: 出口压力, dataType: float, unit: MPa }, { code: temperature, name: 排气温度, dataType: float, unit: ℃ } ] }物模型定义得越规范后面的开发量越小。有些团队一开始嫌麻烦不建物模型直接让设备往平台塞数据短期看着省事等报表、告警、大屏做起来时每个地方都要额外处理字段含义和数据单位反而更痛苦。4.2 Modbus RTU/TCP接入轮询策略和寄存器映射Modbus是典型的主从协议由平台主动发起请求设备被动响应。这意味着平台侧必须有轮询策略而且轮询周期要考虑现场复杂情况。周期太短串口带宽和设备响应能力跟不上周期太长数据实时性又变差。一般现场设备轮询周期在1到10秒范围内具体要看点位数量和串口波特率。寄存器映射表是Modbus接入的重心一个点位对应一个寄存器地址、数据类型、缩放系数地址对不上数据就全是乱的。接新设备时第一件事就是对照设备手册把寄存器映射表整理出来。点位寄存器地址数据类型缩放单位排气温度40001uint160.1℃出口压力40003uint160.01MPa运行状态40005uint161布尔缩放系数是一个特别容易出错的点。很多仪表上报的是整数比如数值856实际代表85.6℃如果忘了乘以0.1后面所有分析都是错的。这类问题排查起来很隐蔽一定要在接入阶段就把映射表核对清楚。4.3 MQTT接入主题设计、QoS选择和心跳保活MQTT适合网络环境相对稳定的设备或网关很多DTU、边缘网关原生支持MQTT上报。主题建议按照设备维度划分例如devices/{DeviceKey}/telemetry这样消息的归属清晰后端订阅也方便。QoS建议用1保证消息至少到达一次代价是可能产生重复消息后端在入库时按消息ID做去重或者幂等处理。QoS0虽然网络开销最小但可能丢消息采集关键状态时不太合适。心跳保活是另一个容易忽略的点比如设备每30秒发一次心跳平台连续多个周期没收到就判定离线离线事件同时推送给前端和告警模块运维人员能第一时间知道哪台设备掉线了。4.4 在线状态和设备影子的处理设备离线时平台需要缓存最后一次上报的数据这个机制叫设备影子。设备重启之后前端可以立刻看到设备最后一次上报的状态不需要等下一次上报才能展示。在运维场景里特别有用比如晚上停电了设备在凌晨2点离线影子数据就能告诉你离线前最后一刻的温湿度是多少离线了多长时间什么时候恢复的。UNIHH-IOT把设备影子作为基础能力内置接入层不用自己重复实现。5. 数据到底怎么用规则、告警、可视化设备接入只是第一步真正让平台有价值的是数据加工和呈现。如果数据进来之后只是一个一个堆在库里那平台最多算个数据库外壳。5.1 数据预处理清洗、计算、压缩原始数据直接入库不是不行但点位多了之后存储会爆炸查询也会变慢。常规做法是先做清洗把明显超范围的数据、传感器故障产生的无效值过滤掉再做计算把瞬时流量累积成日流量把三相功率合成总功率最后做压缩和保留策略原始数据保留30天5分钟聚合数据保留1年。这样数据量能降一个量级最近一个月的明细查询、长周期的趋势报表都能兼顾。数据保留策略在设计时就要想好不要等磁盘满了再临时删数据那时候往往已经晚了。5.2 告警规则的配置逻辑告警不是越灵敏越好。最典型的例子是温度小幅抖动如果把告警阈值设置成超过80度立即触发一个毛刺就会产生几十条告警值班人员很快就麻木了。UNIHH-IOT支持持续时长判断比如说连续3个采集周期都超限才算触发这样能过滤掉大部分瞬时抖动。告警级别分提醒、警告、严重三级不同级别推送不同渠道。告警产生之后进入未确认状态值班人员确认后保留记录等数据恢复正常后告警自动解除。这套流程看起来简单但在实际现场能大幅减少误报和告警疲劳。5.3 可视化大屏和报表的实现思路大屏页面高不高大上是其次最重要的是信息密度和可读性。点位数量多的场景列表式监控加状态颜色变化比花哨的3D动效实用得多。图表部分用开源图表库接时序数据趋势图、柱状图、热力图都能覆盖。报表按天、周、月做聚合导出成Excel或PDF方便企业内部流转。如果企业有更强的可视化需求UNIHH-IOT的API也能把数据开放给其他BI工具页面层完全可以替换成企业已有的平台。6. 二次开发路径开源项目拿到手该怎么改前后端全开源的项目直接部署使用没问题但大多数企业还是希望对界面、协议、接口做一些定制。这一节讲的是拿到代码之后从哪里入手怎么改才不至于把项目改坏。6.1 读懂代码的正确顺序我建议新接手的人按这个顺序来读代码先看部署和配置文档知道系统由几个服务组成、端口怎么分配、配置项是什么意思再看数据模型和表结构知道数据存在哪里、表之间的关联关系然后看接入层的协议插件理解一条数据从设备到数据库的完整链路最后才看API层和前端页面。很多初学者一上来就扎进某个协议插件里结果只见树木不见森林。按顺序建立起整体认知之后再去做具体改动效率会高很多。6.2 常见二次开发场景和对应改动点不同定制需求对应的修改位置差别很大。加一个新协议改动集中在接入层新增插件修改设备属性点直接改物模型定义配置不需要动代码对接第三方系统在API层新增接口或者订阅事件定制大屏风格改前端可视化组件修改告警推送渠道改告警引擎的通知插件。以下表格可以作为一个快速指引场景主要改动位置增加新协议接入层新增协议插件修改设备属性点物模型定义无需改代码对接第三方系统API层新增接口或事件订阅定制大屏风格前端可视化组件、主题配置修改告警推送渠道告警引擎的通知插件这里最重要的一条原则是能通过配置解决的不要改代码能通过插件解决的不要动主流程。改动范围越小升级主版本时越轻松。6.3 从技术选型走向长期维护的注意事项开源平台的维护最大的风险就是停滞和分叉。有些团队从开源项目拉了一个分支改动越积越多跟主线版本彻底脱节后面想合并上游更新都合并不回去。建议每年规划一次版本升级把改动尽量做成插件和配置外置。前端组件也尽量少改源码通过主题配置和扩展路由来实现定制。维护一个开源项目就像维护一套生产系统引入外部代码时要谨慎评估自己产生的代码也要写好注释和文档不然半年后连自己都看不懂。7. 性能表现与卡顿排除经验最后聊一下性能和排障。UNIHH-IOT在模拟环境里做过一些测试这里放几个参考数据再说说实际项目里最容易遇到的卡顿点。7.1 模拟环境下的性能参考在配置为8核16G内存的普通服务器上接入1000台设备、每台每秒上报一条消息消息从设备到达平台到写入时序数据库端到端延迟平均在30毫秒以内。当接入量继续往上翻时瓶颈通常不在CPU而在数据库写入和日志IO。小规模项目跑到几百上千台设备单机完全够用。如果单机扛不住优先考虑把接入服务独立部署并做负载均衡而不是盲目升级单台机器的配置。需要说明的是这个数字和协议类型、消息大小、数据库参数都有关系不能直接换算成所有场景的承诺值但可以作为一个参考基线。7.2 几个容易翻车的性能坑我实际遇到过的坑按频率排序大概是这几个第一采集频率设置过高点位每秒采一次但实际根本用不到大量无用数据把磁盘塞满第二数据库连接池配置过小高并发时请求排队表现为页面偶尔卡死第三前端页面高频轮询接口比如每秒拉一次全量点位把API服务打满第四日志级别长期开着debug生产环境每秒刷几千行日志磁盘IO基本被占满。这些坑在测试环境里不容易暴露设备量上去之后才会爆发所以设计阶段就要预留好日志规范、连接池参数、点位频率控制这些基础约束。7.3 性能瓶颈排查方法论遇到卡顿时按数据链路分层排查而不是在页面上一通乱试。设备侧先确认上报频率和数据量接入层看消息堆积情况和线程池状态存储层看慢查询、磁盘IO和内存占用前端看接口耗时和WebSocket消息量。一层一层排除通常很快就能找到卡点。排查时可以用系统自带的资源监控命令也可以看平台内部的链路追踪日志。关键是先把“现象”和“链路”对应起来再动手去改配置不要看到卡顿就直接把机器的配置翻倍。我自己在几个项目实施中最大的体会是轻量级平台的价值不是省那点服务器钱而是让团队把精力花在设备、业务和运营上而不是花在伺候平台本身。UNIHH-IOT前后端全部开源不绑定任何商业服务任何人拿到代码都能在自己的内网里跑起来、改起来。如果你正在做一个工业数字化项目不妨先用模拟设备把平台完整跑一遍再决定值不值得把它用在你的现场环境里。设备接入走不通的场景把具体协议和现场情况描述出来我看到了都会认真回复这类问题聊起来特别有价值。
阅读完成 · 觉得有帮助？
