Thingsboard物理部署方案

                        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中转上传数据的方式，相对复杂、服务器台数多。具体采用那一种方案，需根据实际的用户需求来定！

 

参考文献

1. https://thingsboard.io/docs/reference/
2. https://thingsboard.io/docs/iot-gateway/what-is-iot-gateway/
3. https://docs.datastax.com/en/ddac/doc/datastax_enterprise/config/configRecommendedSettings.html#configRecommendedSettings