2. ThingsBoard边缘版概述
在工业物联网的实际落地中，纯云端集中式架构往往面临网络不稳定、数据量激增、实时控制延迟高以及敏感数据合规等挑战。ThingsBoard边缘版（ThingsBoard Edge）正是为解决这些问题而设计的轻量级、可独立运行的边缘计算平台。它继承了云版的核心实体模型与规则引擎能力，但以更小的资源占用部署在靠近数据源的位置。本章将系统梳理边缘计算的基本概念，深入剖析ThingsBoard边缘版的功能特性、系统架构，并重点阐述其与云版之间的协同关系及数据同步机制，帮助学员建立对边缘版整体轮廓的清晰认知。
上图展示了ThingsBoard边缘版与云版的基本协同关系。边缘版部署在工厂车间、变电站或智能楼宇等靠近设备的位置，负责设备接入、本地数据处理和实时控制；云版则部署在数据中心，负责多租户管理、全局数据汇聚和高级分析。两者通过双向数据同步通道保持配置一致与数据流动。下面我们将从边缘计算概念出发，逐步深入各个知识模块。
2.1 边缘计算核心概念与工业场景价值
核心原理：为什么需要边缘计算
边缘计算是一种分布式计算范式，将数据处理和应用运行从中心云服务器迁移到网络边缘（即数据源附近）。在工业物联网中，一台PLC可能每100毫秒产生一条数据，一条产线数百个测点一天可产生数亿条记录。若全部上传云端，不仅消耗巨大带宽，还会因网络抖动导致数据丢失或延迟。更关键的是，某些控制指令（如紧急停机）要求毫秒级响应，云端往返路径无法满足。边缘计算的核心思想是“本地决策、云端协同”——在边缘节点完成实时数据处理、过滤、聚合和本地控制，仅将有价值的结果或摘要同步到云端。
- 实时性要求：设备保护、工艺联锁、质量闭环控制，响应时间需小于50ms。
- 数据治理要求：原始高频数据在本地压缩、清洗，只上传特征值或事件，降低存储成本。
- 网络韧性要求：工厂网络中断时，边缘节点仍能独立运行，恢复后自动补传数据。
判断方法：何时选择边缘版而非云版
评估一个项目是否需要ThingsBoard边缘版，可以从以下四个维度进行判断：
| 评估维度 | 适合边缘版 | 适合云版 |
|---|---|---|
| 网络条件 | 带宽有限、网络不稳定、存在断网风险 | 网络稳定、带宽充足 |
| 响应时延 | 要求亚秒级本地控制 | 允许秒级以上延迟 |
| 数据量 | 高频采样（>1Hz），数据量大 | 低频数据或已聚合数据 |
| 合规要求 | 数据不能出园区/车间 | 允许数据上公有云 |
如果项目同时满足“网络不稳定”和“需要本地实时控制”两个条件，则强烈建议采用边缘版架构。
案例拆解：某汽车零部件工厂的设备数据采集
某工厂有80台注塑机，每台设备配置5个温度传感器和3个压力传感器，采样频率为10Hz。原方案将所有数据直接上传至云端，但工厂网络存在周期性抖动（每2小时约中断30秒），导致数据丢失率高达3%。同时，注塑机温度超限时需要立即触发声光报警并联动切断加热电源，云端方案延迟约2-5秒，无法满足安全要求。
改造后，在车间部署一台ThingsBoard边缘版（4核CPU/8GB内存），所有传感器通过Modbus RTU接入边缘网关，边缘版规则引擎实现本地温度阈值判断，超限时直接通过Modbus写寄存器触发设备急停，响应时间小于20ms。同时，边缘版将每秒聚合后的均值、最大值、最小值以及报警事件同步至云端，数据量从原来的每秒800条降至每秒10条，带宽占用降低98%。断网期间数据暂存本地SQLite，恢复后自动补传，数据丢失率降为0。
常见误区与总结
- 误区一：认为边缘版功能弱，只能做数据转发。实际上ThingsBoard边缘版具备完整的规则引擎和实体管理能力，可独立完成复杂逻辑。
- 误区二：将所有数据都同步到云端，失去边缘计算的意义。应设计数据过滤策略，只同步必要信息。
- 误区三：忽略边缘节点的资源限制。边缘版虽轻量，但仍需合理规划存储容量和CPU占用，避免因日志过多导致磁盘写满。
2.2 ThingsBoard边缘版功能特性详解
核心原理：边缘版的功能边界
ThingsBoard边缘版基于与云版相同的核心代码库构建，但针对边缘场景进行了裁剪和优化。它保留了设备管理、资产建模、规则引擎、告警、RPC控制等核心功能，同时增加了边缘特有的“资源”管理机制（如边缘实例、边缘事件队列）。边缘版支持SQLite或PostgreSQL作为本地数据库，默认推荐SQLite以降低运维复杂度。其规则引擎支持与云版几乎相同的节点类型，包括过滤、变换、动作、外部调用等，但部分需要访问云端服务的节点（如发送邮件、Kafka）在边缘版中需要额外配置或不可用。
操作流程：边缘版功能清单与适用场景
| 功能模块 | 边缘版支持情况 | 典型应用场景 |
|---|---|---|
| 设备接入 (MQTT/HTTP/Modbus) | 完整支持 | PLC、传感器、网关直接接入 |
| 规则引擎 | 支持，节点类型约80% | 本地数据清洗、阈值告警、设备联动 |
| 实体关系建模 | 支持设备、资产、租户、客户 | 建立产线-设备-传感器的层级关系 |
| RPC双向控制 | 支持，延迟更低 | 远程下发参数、设备校时、紧急操作 |
| 仪表板 | 支持，但建议轻量化 | 车间本地大屏展示实时状态 |
| 多租户隔离 | 支持，但通常单租户使用 | 集团下属多个工厂共用一台边缘服务器 |
| 云同步 | 核心特性，支持双向同步 | 配置下发、数据上报、告警同步 |
案例拆解：边缘版规则引擎实现本地闭环控制
某水处理厂需要监控沉淀池的浊度值，当浊度超过15NTU时自动增加絮凝剂投加泵的频率。在边缘版中，通过规则引擎配置如下链路：
- 消息接入：浊度传感器每5秒上报一次遥测数据。
- 过滤节点：判断浊度值是否大于15NTU。
- 变换节点：将投加泵频率设定值映射为0-50Hz的Modbus寄存器值。
- 动作节点：通过Modbus写寄存器指令控制变频器。
- 存储节点：将本次调整记录存入本地数据库，并生成一条“投加调整”事件。
整个过程在边缘版内部完成，不依赖云端。即使云端维护或网络中断，水处理过程依然安全可控。该案例中，边缘版规则引擎的毫秒级响应能力是云端方案无法比拟的。
常见误区与总结
- 误区一：认为边缘版不支持仪表板。实际上边缘版支持仪表板功能，但建议只展示实时数据，历史分析类图表应放在云端。
- 误区二：忽略边缘版的资源限制。边缘版默认JVM堆内存为512MB，若设备数量超过1000台，需调整内存配置并考虑使用PostgreSQL。
- 误区三：将边缘版当作云版的完全镜像。部分云版专属功能（如SMS通知、Kafka插件）在边缘版中不可用，需提前确认。
2.3 系统架构：从部署形态到内部模块
核心原理：边缘版的进程与存储架构
ThingsBoard边缘版以Java Spring Boot应用形式运行，主要包含以下核心模块：
- Transport模块：负责MQTT、HTTP、CoAP等协议的设备接入，与云版共享同一套传输层代码。
- Core模块：处理设备生命周期管理、实体关系维护、RPC请求等核心逻辑。
- Rule Engine模块：独立于Core进程运行（在边缘版中可配置为同一进程或独立进程），负责消息处理与规则链执行。
- Edge Sync模块：这是边缘版特有的模块，负责与云版建立持久连接，执行双向数据同步。
- 本地数据库：默认使用SQLite，存储设备属性、遥测数据、告警、规则链定义等。若数据量较大，可切换至PostgreSQL。
操作流程：边缘版部署形态选择
边缘版支持两种部署形态：
- 单机部署（推荐）：所有模块运行在同一台服务器或边缘网关中，适合车间级应用。资源占用约1GB内存、10GB磁盘。
- 高可用部署：将Transport、Core、Rule Engine拆分为多个实例，使用负载均衡。适合大型园区或对可靠性要求极高的场景，但运维复杂度显著增加。
对于大多数工业项目，单机部署已足够。建议使用Docker Compose方式部署，便于版本升级和回滚。
案例拆解：边缘版与云版协同的典型部署拓扑
某集团拥有三个工厂（A、B、C），每个工厂部署一台边缘版服务器，集团总部部署一套云版。各工厂边缘版负责本厂设备接入和实时控制，同时将设备状态、产量数据、告警信息同步至总部云版。总部通过云版的多租户功能，为每个工厂分配独立租户，实现数据隔离。管理层在总部通过云版仪表板查看三个工厂的对比分析报表，而各工厂车间大屏则直接访问本地边缘版仪表板，获取实时数据。
该拓扑的优势在于：
- 工厂网络中断不影响本地生产监控。
- 总部无需直接连接工厂设备，降低网络安全风险。
- 数据在边缘侧已进行初步清洗，云端存储成本降低。
常见误区与总结
- 误区一：将边缘版部署在虚拟机中，且未分配足够资源。边缘版虽轻量，但规则引擎复杂时CPU占用会飙升，建议至少分配2核CPU。
- 误区二：忽略边缘版与云版的版本兼容性。边缘版和云版必须使用相同的主版本号（如3.6.x），否则同步可能失败。
- 误区三：未规划本地存储容量。高频数据若未设置TTL（数据保留策略），磁盘可能在数周内写满。
2.4 与云版的关系及数据同步机制
核心原理：双向同步的语义与实现
ThingsBoard边缘版与云版之间通过基于MQTT的持久连接进行双向同步。同步的核心原则是“配置从云到边，数据从边到云”。具体包括：
- 云到边（下行同步）：设备配置、规则链定义、仪表板、租户/客户信息、设备凭据等由云版统一下发。边缘版启动时先进行全量同步，之后通过订阅云端的变更事件进行增量同步。
- 边到云（上行同步）：设备上报的遥测数据、属性更新、告警事件、RPC响应等由边缘版主动推送至云版。边缘版内置队列机制，确保数据不丢失。
操作流程：数据同步的详细步骤
以“设备遥测数据上报”为例，同步流程如下：
- 设备通过MQTT将遥测数据发送至边缘版Transport模块。
- 边缘版Core模块将数据写入本地数据库，并触发规则引擎。
- 规则引擎处理完毕后，将数据同时放入“本地存储队列”和“云同步队列”。
- Edge Sync模块从云同步队列中取出数据，通过MQTT连接发送至云版。
- 云版收到数据后，写入云端数据库，并返回ACK确认。
- 边缘版收到ACK后，从云同步队列中移除该条数据；若未收到ACK，则定时重发。
对于配置下发（如修改设备名称），流程相反：云版修改后，将变更事件推送给边缘版，边缘版更新本地数据库并返回确认。
案例拆解：断网场景下的数据同步恢复
某风电场边缘版与云版之间的网络因运营商故障中断了45分钟。在此期间，边缘版继续采集风机振动数据，本地规则引擎正常触发告警。所有遥测数据和告警事件均存储在边缘版的云同步队列中（基于内存+磁盘持久化）。网络恢复后，边缘版自动重连云版，按照时间顺序补传中断期间的数据。云版收到数据后，根据时间戳正确排序，未产生数据错乱。该案例验证了边缘版同步机制的可靠性。
queue.edge.sync.persist=true，启用磁盘持久化，确保数据安全。
常见误区与总结
- 误区一：认为边缘版与云版的数据是实时强一致的。实际上同步是异步的，存在秒级到分钟级的延迟，设计应用时应考虑这一延迟。
- 误区二：在边缘版上直接修改设备配置，期望云版自动同步。边缘版上的配置修改不会自动上传，除非通过云版下发，否则会被云版的下发配置覆盖。
- 误区三：忽略同步冲突处理。当云版和边缘版同时修改同一设备属性时，以云版为准。因此，应避免在边缘版上直接编辑设备属性。