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中轉上傳數據的方式,相對複雜、服務器臺數多。具體採用那一種方案,需根據實際的用戶需求來定!
參考文獻
- https://thingsboard.io/docs/reference/
- https://thingsboard.io/docs/iot-gateway/what-is-iot-gateway/
- https://docs.datastax.com/en/ddac/doc/datastax_enterprise/config/configRecommendedSettings.html#configRecommendedSettings