1 總體說明
1.1 產品概述
1.1.1 Thingsboard作用
1.置備並控制設備。
2.采集設備數據並進行數據可視化。
3.分析設備數據，觸發告警。
4.將數據傳輸到另一個系統。
5.允許根據用例的具體需求自定義規則並使用插件。
6.是為物聯網應用提供開箱即用的物聯網雲服務器端基礎設施。
7.是一個開源IoT平台，用來快速開發、管理、擴展的物聯網項目
1.1.2 Thingsboard特點
1.可擴展： 使用領先開源技術構建的可水平擴展平台。
2.容錯： 無單點故障，集群中的每個節點都是相同的。強大、
3.高效： 單個服務器節點可以根據用例處理幾十甚至數十萬個設備。
thingsBoard集群可以處理數百萬台設備。
4.可定制： 可輕松使用可自定義的可視化小部件、規則引擎和插件系統添加新功能。
5.持久保存：永遠不會出現數據丟失現象。
6.開源： 100%開源
1.1.3 產品架構
Thingsboard性能利用三個主要項目：
Netty用於 IoT 設備的高性能MQTT服務器/代理。
Akka為高性能actor系統協調數百萬設備之間的消息。
Cassandra用於可擴展的高性能NoSQL DB，用於存儲來自設備的時間序列數據。
使用Zookeeper進行協調和以集群模式使用gRPC。
規則引擎：動態配置設備消息的處理流程
核心服務：租戶和客戶、設備認證、規則和插件、小組件和儀表盤、告警和事件
安全：SSL用於HTTP和MQTT
設備安全認證：Token和X.509
1.1.3 前后端分離之前端
1.前端知識准備：Nodejs, Angularjs，ES6，Reactjs，webpack。
2.了解thingsboard項目：
3.前端MVC、MVVM框架
4.前端打包方案
5.主要開發可視化小部件，后台管理平台數據ui展示
1.1.4 前后端分離之后端
1.熟悉工業標准IOT通信協議：
- MQTT：發布訂閱模式
- COAP：請求響應模式
- HTTP ：請求響應模式
2.熟悉postages和cassandra數據庫結構
3.規則鏈的使用
4.其它系統與TB的對接
5.物聯網網關：物聯網網關主要的三個功能
1、協議轉換能力
2、可管理能力
3、廣泛的接入能力
物聯網網關的兩個因素
1、數據安全
2、可維護
對平台來說物聯網網關也只是一個設備：只不過網關的消息體和其他設備不一樣，網關監聽的是消息代理發送的消息，針對MQTT來說，網關只不過選擇性監聽了topic，構建了一個映射“map”關系。
1.2 ThingsBoard實際接入項目
1.2.1 目前協議支持
1.目前支持HTTP,MQTT, COAP
2.官網原文：
Extend default platform functionality using customizable rules, plugins, widgets and transport implementations. In addition to MQTT, CoAP and HTTP support, ThingsBoard users can use their own transport implementations or customize behaviour of existing protocols.
使用可定制規則、插件、小部件以及傳輸協議擴展平台默認功能。支持MQTT, CoAP and HTTP 協議，此外，用戶可定制MQTT, CoAP and HTTP 協議或使用自己的協議。
3.添加第三方協議，需要二開,項目包名:Transport 代碼改動量較大，建議將Thingsboard不支持的協議中間轉換為Thingsboard支持協議，再推送到Thingsboard。
4.相似產品及公司協議支持對比
1.2.2 項目接入
- 內網部署設備：
通過MQTT協議對於Thingsboard也是網關的概念去接入
- 通外網設備：
外網設備，對於MQ，WebsSocket WebService等協議可以二開接入ThingsBoard或者統一轉換為HTTP協議，建議十分不常見的其他協議不用考慮二次開發Thingsboard接入，對於ThingsBoard平台不支持的常見協議可以開發去接入，一次開發后通用。
- 數據可視化：
- 設備數據可視化對於力石可以起到輔助作用用於實時展示接入數據的變化，可以及時排查第三方接入故障。
- 設備數據接入Thingsboard平台后可以有多種可視化展示方式，echarts圖標 數據走勢圖等，而且可以自己開發組件去展示數據。
- 數據使用：
我司看重的最重要的對於ThingsBoard作用就是對外第三方接入，對於公司需要調用第三方的需求的部分，可以統一接入ThingsBoard平台
1.3 ThingsBoard解決痛點
1.痛點描述：對於公司業務來說項目中大量使用第三方的接口，以及各種協議，沒有統一去處理這些第三方的業務，每個新的協議過來，研發去研究接入。
當第三方的調用較少時，或者項目少的時候，痛點還不突出，當業務量越來越大，調用越來越多，項目越來越多的時候，隨着項目的時間越來越遠，維護起來會變的很痛苦，老舊項目第三方的代碼的調用邏輯和管理就會變得很混亂。
2.接入ThingsBoard后 公司對接所需數據是對接中間介質ThingsBoard能解決的問題：
（1）統一了對外調用 我司設備對接完ThingsBoard后,不用再去考慮設備對接問題。
（2）Thingsboard對外提供的對接方式可以統一轉換為主流的HTTP接口形式
（3）可擴展性也強大 特殊情況下，不需要HTTP形式的數據，Thingsboard通過規則鏈也可以對接到管道，例如：Kafka
（4）對於每個廠商可以通過租戶(Thingsboard)的概念去區分管理，十分清晰。
（5）協議接入越多，平台功能越強大，類型滾雪球，后期會變得更輕松。
1.4 ThingsBoard難點
- 對於不支持的協議前期接入，當選用在ThingsBoad源碼上二次開發，需要研發熟悉Thingsboard 協議接入模塊的代碼
- 對於不支持的協議接入，如果考慮統一中間轉換一下協議再接入ThingsBoard,前期工作量較大，但是該轉換協議的項目設計合理的前提下功能強大起來，后期接入其他相同協議的設備會十分省時。
- ThingsBoard部署問題,關鍵數據庫postages和cassandra服務器大小的預估。
- 當內網設備接入時，雖說可以通過網關接入，例如使用MQTT接入需要說服設備廠商本地安裝客戶應用服務器，MQTT客戶端。
1.5 相關資料
1.https://blog.csdn.net/github_35631540/category_10844433.html
2.https://fizzz.blog.csdn.net/article/details/114286380
3.https://thingsboard.io/
