Thingsboard物理部署

徐景周

一、目标

支持1万台设备、每秒2万条消息的并发量。

二、实施方案

从Thingsboard官网文档得出，数据采集方式主要有二种方案：一种是设备端通过Thingsboard API的方式直接上传数据到Thingsboard节点。另一种是设备端通过TB Gateway网关中转推送数据到Thingsboard节点。

前置条件（官网）

TB Gateway不支持负载均衡，它的设计理念是单个TB Gateway只支持并发量在1000台以下设备数（备注：经本人测试，1000台以下基本无延迟；1000台整时，延迟基本在1分钟内；1000台以上，延迟会随设备数的增加而增加）。
MQTT Broker中的Mosquitto（多用于嵌入式设备），不支持负载均衡。想要支持负载均衡，需改换成其它的MQTT Broker（例如： EMQ等）。
Thingsboard单个节点，可以支持并发1万台设备、大约每秒1.8万条消息。
Cassandra基于Gossip协议，故无需主控中心、主备机制等。

下面将针对当前目标，基于单体（monolithic ）架构模式，分别对这二种方案进行分析。

1. 基于Thingsboard API上传数据

该方案也是官网测试用例所采用的方式。该方案需要一个Thingsboard节点、一个Cassandra集群（3台以上）、一个Postgres节点（由于目前结构化数据量并不大，单节点或主备节点即可）、一个测试设备节点，故至少需要4台服务器部署（其中3台内存16G以上，其它可以8G）。

物理架构如图一所示。

图一

2. 基于TB Gateway中转来上传数据

由于TB Gateway的设计限制，想要实现目标的话需要10个TB Gateway节点（相应的Thingsboard上需配置10个对应的网关）、10个Mosquitto节点、一个Thingsboard节点、一个Cassandra集群（3台以上）、一个Postgres节点（由于目前结构化数据量并不大，单节点或主备节点即可）、一个测试设备节点，故至少需要14台服务器部署（其中3台内存16G以上，其它可以8G）。

物理架构如图二所示。

图二

三、小结

Thingsboard API上传数据的方式，相对简单、服务器台数少。TB Gateway中转上传数据的方式，相对复杂、服务器台数多。具体采用那一种方案，需根据实际的用户需求来定！

参考文献