Thingsboard 源码分析 -- Gateway mqtt网关原理实现
Thingsboard的网关通过tb核心服务提供的mqtt以客户端的形式连接到tb上，一个网关的mqtt连接同时只能在线一个客户端服务。正常情况下，网关下的所有设备上报数据都是通过网关上报，网关下所有设备都是先把数据上报到边缘端的mqtt上，然后网关通过订阅边缘端的mqtt获取设备数据，再统一通过tb的mqtt上传到tb上，网关服务上传操作还考虑到了服务掉线的情况，会把数据暂时存起来，待服务连接正常继续上报。
Thingsboard官方网关用的python写的，最早官方网关用的java，但是不知道什么原因下架换成python，有知道的朋友请留言。
Thingsboard网关核心功能有两个，
1，上报数据。
2，接收服务端rpc请求，转发给设备连接的边缘端mqtt，我们有些场景下，网关显得鸡肋，我们就可以按以下逻辑定制一个简易的网关。
3，多协议支持。
Thingsboard mqtt网关的核心代码都在MqttGatewayService类中，业务也比较简单，有兴趣可以跟一下代码看看。
但是某些场景下，我们业务很简单，边缘端又不想部署这么多服务，可以考虑去掉tb网关，采集服务模拟网关直接跟tb通信完成数据上报和控制。
首先说一下上报数据的核心逻辑，设备数据上报前要做一次connect，tb会为我们在设备列表中创建设备，否则，tb核心服务会为我们创建一个没有设备类型的设备出来。
topic：v1/gateway/connect
body: {"device":"1111",type:"sensor"}
上报遥测数据
topic：v1/gateway/telemetry
body：{"1111":[{ "switch1": 1, "switch2": 1}]}
上报客户端属性
topic：v1/gateway/attributes
body：{"1111":{"deviceType":"xxx","supplier":"xxx"}}
再说下rpc请求的核心逻辑
单向和双向的topic都需要订阅以下topic，主要在规则引擎里区分好单向还是双向，写到body里，便于网关区分返回响应。
v1/gateway/rpc
订阅上述topic，rpc请求可以收到如下body
{"device":"F8EF6B0F004B1200","data":{"id":123,"method":"set/njwl/switch1","params":{"state":1,"supplier":"njwl","deviceId":"F8EF6B0F004B1200","deviceType":"switch","isOneway":"false"}}}
双向rpc 响应，body中的id就是requestid。
v1/gateway/rpc
body: {"id":123,"device":"F8EF6B0F004B1200","data":"{\"state\":1111,\"supplier\":\"njwl\"}"}
网关心跳
MqttGatewayService 在init方法中会定时运行reportStats()方法，默认好像是10秒一次，向topic v1/devices/me/telemetry 发送以下数据。
{"ts":1606267309953,"values":{"devicesOnline":111,"attributesUploaded":0,"telemetryUploaded":0}}
设备心跳，完全依赖设备自身上报，无论是属性还是遥测数据，都会认为是心跳
至此，可以完全脱离thingsboard的gateway独立设计运转自己的网关了。