Thingsboard3.9.1全面架构详细解析说明

咚咚汇

已于 2025-05-07 16:05:31 修改

阅读量1.1k

点赞数 13

CC 4.0 BY-SA版权

分类专栏： ThingsBoard 文章标签：架构 iot thingsboard 微服务边缘

于 2025-05-07 15:56:33 首次发布

本文链接：https://blog.youkuaiyun.com/hssjf/article/details/147756487

ThingsBoard 专栏收录该内容

58 篇文章

订阅专栏

最近在整理thingsboard课程，基于最新thingsboard版本3.9.1/4.0，欢迎大家收藏、关注我，提问，在评论区留言，我争取把最新、最准、最好的课程，呈现在各位亦师亦友的csdn广大读者面前。

1.架构说明

1.1基础架构

说明：

(1) Transport与Core之间的通信队列：

Kafka (默认推荐的生产环境方案)

In-Memory Queue (主要用于开发环境或小规模部署)

（在thingsboard.yml文件中可以配置）

生产者TbQueueProducer，如下：

消费者TbQueueConsumer，如下：

(2) Gateways网关

此处网关默认是指TB团队研发的物联网关软件产品(使用python语言开发)，实际项目中可以替换为自己网关（软件或软硬件一体），市面上也有很多网关能够兼容TB平台，这类网关硬件基于STM32/ESP32/ARM+Linux都有。

TB分层架构可以理解为以下几个部分：

(1) 设备接入层

负责与IoT设备通信，支持多种协议（如 MQTT、CoAP、HTTP 等）。

使用Netty实现高效的网络通信，处理大量并发连接。

(2) 核心服务层

包括设备管理、规则引擎、数据存储等功能。

使用Actor构建分布式消息传递系统，确保高并发和容错能力。

(3) 数据存储层

支持多种数据库（如 Cassandra、PostgreSQL、TimescaleDB 等），用于存储设备数据和元数据。

(4) Web-ui层

基于Angular框架开发，提供用户界面，用于设备管理、仪表板展示等。

thingsboard系统中，设备数据从接入到处理的一般流程：

(1) 设备连接与数据传输

设备通过MQTT、CoAP或HTTP协议发送数据到TB平台。

基于Netty的Transport接收设备的数据流，并将其解析为内部消息格式。

(2) 消息路由

解析后的消息被传递到Actor系统中。

Actor负责将消息分发到不同的服务模块（如规则引擎、存储服务等）。

(3) 规则引擎处理

规则引擎基于预定义的规则对数据进行处理（如过滤、转换、触发告警等）。

处理结果可能被转发到其他服务或外部系统。

(4) 数据存储

处理后的数据被存储到数据库中，供后续查询和分析使用。

(5) 用户交互

用户通过Web-ui查看设备状态、历史数据、仪表板等。

1.2单体架构

在单体架构中，所有TB组件都在单个JVM中启动，并共享一个操作系统的资源。单体架构的优势是最小化运行，所需内存极少，比如达到256或512 MB就可以启动和运行；单体架构的缺点是，如果使用消息（如MQTT传输）重载一个组件，它也可能影响其他组件。例如，如果操作系统对TB进程的限制是4096个文件描述符，那么系统不能同时从设备和websocket用户会话中打开超过4096个MQTT会话。

文件描述符是操作系统中用于标识和访问文件或其他 I/O 资源（如管道、套接字、设备等）的抽象句柄。它是一个非负整数，由操作系统内核分配和管理。每个进程都有自己的文件描述符表，用于跟踪其打开的文件和 I/O 资源。

文件描述符是进程与操作系统之间交互的桥梁。通过文件描述符，进程可以读取、写入、关闭文件或网络连接等资源。

在大多数 Linux 系统中，每个进程默认的文件描述符限制是1024，可以修改内核参数提升文件描述符默认数量。

Core核心服务的功能：

1）所有REST API；

2）与前端交互（WebSocket）；

3）设备/资产/告警等实体管理；

4）租户/权限；

1.3微服务架构

（1）微服务架构概述

微服务主要为了解决高并发场景下的性能瓶颈和扩展性问题，其核心功能模块（如传输层、规则引擎、Web-ui 等）拆分为独立的服务，通过消息队列（如Kafka）进行通信，实现高可用性和负载均衡。

（2）传输层微服务

传输层微服务负责处理设备与平台之间的通信，支持MQTT、HTTP和CoAP协议。每个协议由独立的服务器组件实现，并通过消息队列（如Kafka）与核心服务通信。传输层使用tb.transport.api.requests和 tb.transport.api.responses主题进行设备凭证验证和消息传递。

（3）核心服务

核心服务是TB的中枢，负责处理REST API调用、WebSocket订阅、设备会话管理等功能。基于Actor模型，核心服务实现了租户、设备、规则链等实体的高效管理，并通过一致性哈希算法在集群节点间分配负载。

（4）规则引擎微服务

规则引擎是TB核心功能模块，负责处理设备上报的数据并触发预定义的动作。规则引擎使用Actor模型实现规则链和规则节点，支持多租户隔离和共享模式。规则引擎从消息队列（比如Kafka）订阅消息，并在处理完成后进行确认。

（5）Web-ui微服务

使用Express.js框架承载静态内容，并通过REST API和WebSocket这两个组件，与核心服务交互。Web-ui完全无状态，支持高并发访问和动态数据展示。

（6）消息队列与通信机制

消息队列（比如Kafka）是TB微服务架构所需要的核心通信组件，用于实现消息的持久化和负载均衡。每个微服务通过消息主题（如 tb.rule-engine 和 tb.core）进行通信，确保消息的可靠传递和处理。

（7）数据库与持久化

TB支持多种数据库选项，包括PostgreSQL、Cassandra和TimescaleDB。实体数据通常存储在PostgreSQL中，而时间序列数据可选择Cassandra或TimescaleDB，以此实现高效存储和查询。