开源项⽬实例源码_物联⽹时代-ThingsBoard源码分析-项⽬结
构说明
指南logo
系列⽂章：
⾼质量的 IOT 技术教程，代码主要源于国外开源物联⽹平台ThingsBoard和对阿⾥云物联⽹平台的感悟
源码解析系列
a.『准备篇』
《物联⽹时代-Thingsboard源码分析-调试环境调试》
《物联⽹时代-Thingsboard源码分析-项⽬结构说明》
b.『设备连接协议篇』
MQTT
《MQTT⼊门篇》
《物联⽹时代-ThingsBoard源码分析-MQTT设备连接协议-上》
背景图
概述
开源mqtt服务器本⽂主要分享开源物联⽹平台ThingsBoard的项⽬结构。
希望通过本⽂能让朋友们对thingsboard的整体项⽬有个简单的了解。
在拉取thingsboard项⽬后，我们会发现拆分了很多Maven项⽬。是不是内⼼⼀紧，产⽣了恐惧感?不要⽅，我们就是继续怼。
项⽬结构
代码统计
这⾥先分享⼀个⼩技巧。笔者在开始源码学习时，会⾸先了解项⽬的代码量。
第⼀种⽅式，使⽤IDEA Statistic 插件，统计整体代码量。
代码统计
我们可以粗略的看到，总的代码量在85787⾏。这其中还包括单元测试，⽰例等等代码。所以，不慌。
第⼆种⽅式，是⽤Shell脚本命令逐个Maven模块统计。
⼀般情况下，笔者使⽤find . -name "*.java"|xargs cat|grep -v -e ^$ -e ^s*//.*$|wc -l 。这个命令只过滤了部分注释，所以相对IDEA Statistic会偏多。
当然，考虑到准确性，朋友需要⼿动到 cd到每个Maven项⽬的 src/main/java ⽬录下，以达到排除单元测试的代码量。
代码量
架构设计
ThingsBoard旨在将⼯作负载分布在多个节点上，⽽不会出现单点故障。每个ThingsBoard节点都是相同的，可以处理来⾃设备和服务器端应⽤程序的请求。
⾼级概述
⾼级概述
设备连接
ThingsBoard⽀持⽤于设备连接的MQTT，CoAP 和 HTTP 协议。可以插⼊不同协议的⽀持和定制现有实现。
规则引擎
ThingsBoard Rule Engine允许处理来⾃设备的消息并触发称为插件的可配置处理模块。
核⼼服务
ThingsBoard包含⼀组允许管理以下实体的核⼼服务:
设备及其凭据
规则链和规则节点
租户和客户
⼩部件和仪表盘
警报和事件
规则能够调⽤此API的某个⼦集。例如，规则可以为某些设备创建警报。
服务器端API⽹关
每个ThingsBoard服务器都为注册⽤户提供REST API。System Telemetry服务允许使⽤websocket和REST API管理属性并获取时间序列数据。系统RPC服务提供REST API以⾃定义命令推送到设备。在此处了解有关ThingsBoard REST API的更多信息
Actor模型
只要服务端API调⽤，Actor模型就可以从设备⾼性能并发处理消息。ThingsBoard使⽤Akka作为具有以下actor层次结构的actor系统实现。
Actor
下⾯列出了每个actor功能的简要说明:
App Actor - 负责管理租户演员。此actor的⽰例始终存在于内存中。
租户演员 - 负责管理租户设备和规则链演员。此actor的实例始终存在于内存中。
Device Actor - 维护设备的状态：活动回话，订阅，挂起的RPC命令等。出于性能原因，将当前设备属性缓存在内存中。处理来⾃设备的第⼀条消息时，将创建⼀个actor。当设备在⼀段时间内没有消息时，actor停⽌。
规则链Actor - 处理传⼊的消息，将它们保存到队列中并将它们分派给规则节点actor。此actor的实例始终存在于内存中。
规则节点Actor - 处理传⼊消息，并将结果报告给规则链actor。此actor的实例始终存在于内存中。
设备会话管理器Actor - 负责管理设备会话actor。在具有相应会话ID的第⼀条消息上创建会话actor。关闭相应会话时关闭会话actor。
Session Actor - 表⽰设备和ThingsBoard服务器之间的通信会话。会话可以是同步的(HTTP,COAP)和异步的(MQTT，带有Observe 选项的CoAP)。
RPC会话管理器Actor - 负责管理集RPC会话actor。新服务器启动时创建会话actor。服务器关闭时关闭会话actor。
RPC Session Actor - 表⽰集模式下2个ThingsBoard服务器之间的通信会话。使⽤基于gPRC的HTTP/2进⾏通信。
集模式
服务发现
ThingsBoard使⽤Zookeeper进⾏服务发现。所有ThingsBoard节点都是相同的，并在Zookeeper中注册为短暂的。Apache Curator路径缓存接受⽤于跟踪所有可⽤的兄弟节点。
⼀致的哈希
ThingsBoard采⽤⼀致的散列来确保可扩展性和可⽤性。可以基于设备ID的散列将在特定节点上接收的来⾃设备A的消息转发到另⼀节点。虽然这会引⼊某些⽹络开销，但它允许使⽤确定的服务器上的相应设备actor处理来⾃特定设备的所有消息，这带来了以下优点：
提⾼缓存命中率。设备属性和其他设备相关数据由特定服务器上的设备actor获取。
避免竞争条件。特定设备的所有消息都在确定的服务器上处理。
允许根据设备ID定位服务器端api调⽤。
下图演⽰了ThingsBoard如何处理对Device D1的RPC请求。在这种情况下，请求到达服务器A，但D1使⽤MQTT连接到服务器C.在最坏的情况下，D1 Device Actor将位于另⼀个显然与A或C不匹配的服务器B上。
微服务
安全
传输加密
作为系统管理员，您可以将ThingsBoard配置为使⽤HTTP和s和MQTT传输的安全套接字层。⽬前尚不⽀持DTLS for CoAP。
设备认证
ThingsBoard旨在⽀持多种类型的设备凭据。当前版本为所有协议提供基于令牌的凭证的 ⽀持，并⽀持基于X.509证书的MQTT协议凭证。有关更多详细信息，请参阅MQTT over SSL指南。
第三⽅⼯具
ThingsBoard使⽤以下主要第三⽅项⽬：
Akka - ⽤于Actor系统实施
Zookeeper - ⽤于服务协调
gRPC - ⽤于⾼性能RPC
Cassandra - 作为可扩展且可靠的数据库
项⽬依赖图
ThingsBoard的Maven项⽬之间主要依赖如下图:

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。