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/
