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