📚 课程目录第2章 ThingsBoard系统架构

2. ThingsBoard 系统架构：微服务架构概览、核心组件与数据流

ThingsBoard 采用微服务架构设计，将传统单体应用拆分为多个独立部署、松耦合的服务模块。这种架构为租户隔离提供了天然的基础：每个微服务可以独立扩展、独立配置安全策略，并通过统一的消息队列实现数据交换，从而在保障多租户数据安全的同时，实现资源的高效利用。

2.1 微服务架构概览

ThingsBoard 的微服务架构围绕“设备连接 → 数据处理 → 规则引擎 → 持久化 → 可视化”的核心链路构建。主要包含以下关键服务：

微服务/组件	职责	租户隔离关注点
Transport 层	负责设备协议接入（MQTT、HTTP、CoAP、LwM2M）	设备认证、租户设备映射
Rule Engine	处理设备数据、执行规则链、触发告警与动作	规则链隔离、租户级数据处理
Web UI	提供用户仪表板、设备管理、租户管理界面	租户管理员与系统管理员权限分离
Core Service	设备管理、租户管理、用户管理、权限控制	租户数据存储隔离、API 鉴权
Queue Service	消息队列（Kafka / RabbitMQ / AWS SQS）	消息分区、租户级流量隔离
Database	时序数据（Cassandra / TimescaleDB）+ 实体数据（PostgreSQL）	租户级数据分片、查询隔离

架构要点：ThingsBoard 的微服务之间不直接通信，所有数据流都通过消息队列中转。这种设计使得每个服务可以独立扩缩容，并且可以在消息层面实现租户级别的流量控制和数据隔离。

2.2 核心组件详解

2.2.1 Transport 层：设备接入网关

Transport 层是 ThingsBoard 与物理设备之间的桥梁。它支持多种 IoT 协议，每个协议都有独立的 Transport 服务实例：

MQTT Transport：最常用的设备接入方式，支持 QoS 0/1/2，支持设备证书与 Token 认证。
HTTP Transport：适用于 RESTful 设备上报，支持 JSON/CSV 格式。
CoAP Transport：适用于低功耗、受限网络环境。
LwM2M Transport：适用于电信级设备管理场景。

Transport 层在接收设备数据时，会完成设备认证和租户映射：根据设备凭证（Token、证书、用户名密码）确定设备所属租户，并将租户 ID 注入消息元数据，供后续服务使用。

2.2.2 Rule Engine：数据处理中枢

Rule Engine 是 ThingsBoard 最核心的组件，负责对设备上报的数据进行过滤、转换、丰富、持久化，并触发告警、通知、RPC 调用等动作。每个租户可以拥有独立的规则链，规则链由多个节点组成：

节点类型	功能	租户隔离示例
Filter 节点	根据条件过滤消息（如设备类型、数据范围）	只处理本租户设备的数据
Transform 节点	转换数据格式、单位换算、字段映射	按租户需求定制数据格式
Action 节点	执行持久化、RPC 调用、发送邮件/短信	租户级告警策略、通知渠道
External 节点	调用外部 REST API、Kafka、RabbitMQ	租户级数据出口隔离

2.2.3 Web UI：多租户管理界面

ThingsBoard 的 Web UI 采用 Angular 框架开发，支持系统管理员和租户管理员两种角色视图：

系统管理员：管理租户、系统级配置、查看所有租户的统计信息。
租户管理员：管理本租户下的设备、仪表板、规则链、用户、资产等。

Web UI 通过 REST API 与 Core Service 交互，所有 API 请求都会经过租户 ID 校验和权限检查，确保租户管理员只能操作本租户范围内的资源。

2.3 数据流与消息队列

ThingsBoard 的数据流遵循“设备 → Transport → 消息队列 → Rule Engine → 消息队列 → Core/DB”的路径。消息队列在整个架构中起到解耦和缓冲的作用。

  数据流核心路径：

设备通过 MQTT/HTTP/CoAP 上报数据到 Transport 服务。

Transport 将数据封装为 ProtoBuf 消息，发布到消息队列的 tb_transport Topic。

Rule Engine 消费 tb_transport 消息，执行规则链处理。

处理后的数据（持久化、告警、RPC）发布到 tb_core 或 tb_rule_engine Topic。

Core Service 消费消息，写入数据库或执行设备 RPC 指令。

2.4 消息队列在租户隔离中的作用

消息队列是 ThingsBoard 实现租户隔离的关键基础设施。通过合理的 Topic 设计和消费组配置，可以实现以下隔离策略：

Topic 分区隔离：为不同租户分配独立的消息分区，避免租户数据混在一起。
消费组隔离：每个租户的 Rule Engine 实例使用独立的消费组，确保一个租户的消息处理不会影响其他租户。
消息元数据注入：Transport 层在消息中注入 tenantId，Rule Engine 和 Core Service 根据 tenantId 进行数据路由和权限校验。
流量控制：通过消息队列的限流机制，防止某个租户的突发流量压垮整个系统。

生产环境建议：在多租户高并发场景下，推荐使用 Kafka 作为消息队列。Kafka 的 Topic 分区机制天然支持租户级数据隔离，并且可以通过调整分区数实现租户级别的水平扩展。避免在单租户场景下使用过多分区，以免增加管理复杂度。

2.5 核心组件协作流程

以一个典型的设备数据上报场景为例，展示各组件如何协作：

设备连接：温度传感器通过 MQTT 协议连接到 ThingsBoard MQTT Transport，使用设备 Token 进行认证。
消息发布：Transport 验证 Token 成功后，将设备数据（温度值、时间戳）封装为 ProtoBuf 消息，并注入 tenantId 和 deviceId，发布到 Kafka 的 tb_transport Topic。
规则链处理：Rule Engine 消费消息，根据 tenantId 加载对应的规则链。规则链中的 Filter 节点检查设备类型，Transform 节点将温度从华氏度转换为摄氏度，Action 节点将数据持久化到数据库。
数据持久化：Rule Engine 将处理后的数据发布到 tb_core Topic，Core Service 消费后写入时序数据库（Cassandra/TimescaleDB）。
实时更新：Web UI 通过 WebSocket 订阅设备数据变化，实时更新仪表板上的温度图表。

  租户隔离在流程中的体现：

  - 步骤 2 中注入的 tenantId 贯穿整个数据流，后续所有服务都根据该 ID 进行数据路由和权限校验。

  - 步骤 3 中 Rule Engine 按 tenantId 加载规则链，确保租户 A 的规则不会影响租户 B 的数据。

  - 步骤 4 中 Core Service 根据 tenantId 将数据写入对应的数据库表或 Keyspace，实现存储隔离。

通过这种架构设计，ThingsBoard 在微服务层面实现了计算隔离（独立 Rule Engine 实例）、通信隔离（消息队列分区与消费组）、存储隔离（独立数据库表空间/Keyspace）和展示隔离（租户管理员只能看到本租户的仪表板），为多租户场景下的数据安全与资源管理奠定了坚实基础。