![](https://i-blog.csdnimg.cn/blog_migrate/bac292044748dffe42c566bc619bb0e0.png)
整体架构
![](https://i-blog.csdnimg.cn/blog_migrate/768b4cbf9bc78ef9353b75c30983281b.png)
物接入:物接入是全托管的云服务,可以在智能设备与云端之间建立安全的双向连接,并通过主流的物联网协议(如MQTT)通讯,实现从设备端到云端以及从云端到设备端的安全稳定的消息传输。
物接入(设备型):主要用于对接入云端的设备进行管理和操作。物管理需要与云的物接入服务配合使用,对接入云端的设备进行一站式设备管理,可应用于设备的层级管理、监测、遥控、固件升级和维护保养等各个场景。
物解析:在云端为用户提供工业协议解析服务。当云端收到设备端返回的原始数据后,结合用户提供的设备通讯地址表,物解析服务可将数据解析成直接可用于存储和分析的数据。
规则引擎:作为物联网平台的重要组件,用于将信息根据预先设置好的规则转发至云其它服务。用户可通过规则引擎设定消息处理规则,对规则匹配的消息采取相应的转发操作,如推送给手机APP等;也可以将设备消息无缝转发到时序数据库、Kafka和对象存储中进行存储。
时序数据库:用于管理时间序列数据的专业化数据库。区别于传统的关系型数据库,时序数据库针对时间序列数据的存储、查询和展现进行了专门的优化,从而获得极高的数据压缩能力、极优的查询性能,特别适用于物联网应用场景。
大数据平台:提供了完备的大数据托管服务、智能API、众多业务场景模板以及人脸识别、文字识别、语音识别等服务,帮助用户实现智能业务。
平台架构
![](https://i-blog.csdnimg.cn/blog_migrate/4cfb98793924133d54bd2529e0225cb8.png)
通讯协议
![](https://i-blog.csdnimg.cn/blog_migrate/6446c9194fc4c614e241177069446f8f.png)
MQTT
![](https://i-blog.csdnimg.cn/blog_migrate/c9d7b41a0ae82797772ca1820ccba104.png)
MQTT PUB/SUB
![](https://i-blog.csdnimg.cn/blog_migrate/d9ba16967c1cb56c5ca2d0e02a9d1d5c.png)
MQTT开源
单机版本
• Mosquitto
• Moquette
• Apollo
• RabbitMQ
分布式
• EMQTT
MQTT architecture
![](https://i-blog.csdnimg.cn/blog_migrate/028aa29c46b8c39e50d67326d94705cf.png)
高可用
MQTT层堆栈
![](https://i-blog.csdnimg.cn/blog_migrate/738d11bcb0bbefb8424b54fb65435f4e.png)
跨机器Router模型
![](https://i-blog.csdnimg.cn/blog_migrate/d6f96977eeefe8691f3ede3bb6f739c8.png)
Router性能优化(字典树)
![](https://i-blog.csdnimg.cn/blog_migrate/66191dd4cbb4d170a589b6b39e717f34.png)
Router性能优化(Cache)
![](https://i-blog.csdnimg.cn/blog_migrate/b02287451b036b04eb4d4e7f61ddc3e4.png)
![](https://i-blog.csdnimg.cn/blog_migrate/d031808c1dc0c8cfc39566d2f9804442.png)
![](https://i-blog.csdnimg.cn/blog_migrate/290f6aa99918727af9195528ce00eeb2.png)
![](https://i-blog.csdnimg.cn/blog_migrate/8512993ba34c747a19ffc5c3318bcae6.png)
![](https://i-blog.csdnimg.cn/blog_migrate/801ffda7201ab1a98046408069b39221.png)
数据一致性
• 支持同一client发布消息顺序性
• 保证每个订阅者收到来自同一个broker上发送到同一 个topic消息的有序性
• 不同Broker发送消息顺序取决于他们发送到这个 broker的时间决定的
• 不支持各个client之间消息全局有序 这样就需要选择一个master来分配每个消息的ID
• 对于MQTT大部分场景来说,没必要全局有序
数据一致范例
• C1 发送消息到 M1, M2, M3 主题 T2
• C2 发送消息到 M4, M5, M6 主题 T2
• M1必须在M2,M3之前到达T2
• M2必须在M3之前到达T2
• M4必须在M5,M6之前到达T2
• M5必须在M6之前到达T2
• T2收到的消息可能是C1和C2发送消息交织的结果
大数据并发处理架构
![](https://i-blog.csdnimg.cn/blog_migrate/d709739964121255134c60b6bf24bf6a.png)
开发中可能出现的问题
1.采用REST API方式做authentication & Authorization
• 由于是短链接导致大量TIME_WAIT状态的TCP连接,消耗太多端口资源
• 采用RPC连接池极大降低短链接导致端口资源消耗,采用cache机制
2. 跨机器消息传递瓶颈问题
建议大规模数据订阅采用从kafka消费数据
• Broker直接将消息写入到Kafka,从kafka订阅数据
3.避免使用Zookeeper管理大量metadata以及watch
• 会导致zookeeper系统达到资源极限,比如最大watch的节点数太多会 导致session重建出现失败
应用场景
• 工业4.0
• 零售020
• 智慧物流
• 节能减排
• 智能硬件
• 车联网
------------------------------------------------------------------
今天先到这儿,希望对您技术领导力, 企业管理,物联网, 系统架构设计与评估,团队管理, 项目管理, 产品管理,团队建设 有参考作用 , 您可能感兴趣的文章: