IoT挑战

• 规模

1、未来链接物联网的设备将要达到100亿级别
2、比如可穿戴式设备，家庭全屋智能，工业网关

• 存储

1、分布式的时序数据库，涉及关系型数据库和NoSQL，主要有MySQL和HBase、MongoDB、Redis、Cassandra等
2、分布式文件系统，传统的RDS

• 工具

1、大数据分析工具，实时流式处理
2、分析设备产生数据的机器学习平台，训练模型

• 环境

1、安全以及个人隐私，防止攻击、数据安全、数据加密
2、不同协议的融合（MQTT、CoAP、HTTP/HTTPS、XMPP）

整体架构

15172-20190105103154223-1134543838.png

• 物接入

物接入是全托管的云服务，可以在智能设备与云端之间建立安全的双向连接，并通过主流的物联网协议（如MQTT）通讯，实现从设备端到云端以及从云端到设备端的安全稳定的消息传输。

• 物接入（设备型）

主要用于对接入云端的设备进行管理和操作。物管理需要与云的物接入服务配合使用，对接入云端的设备进行一站式设备管理，可应用于设备的层级管理、监测、遥控、固件升级和维护保养等各个场景。

• 物解析

在云端为用户提供工业协议解析服务。当云端收到设备端返回的原始数据后，结合用户提供的设备通讯地址表，物解析服务可将数据解析成直接可用于存储和分析的数据。

• 规则引擎

作为物联网平台的重要组件，用于将信息根据预先设置好的规则转发至云其它服务。用户可通过规则引擎设定消息处理规则，对规则匹配的消息采取相应的转发操作，如推送给手机APP等；也可以将设备消息无缝转发到时序数据库、Kafka和对象存储中进行存储。

• 时序数据库

用于管理时间序列数据的专业化数据库。区别于传统的关系型数据库，时序数据库针对时间序列数据的存储、查询和展现进行了专门的优化，从而获得极高的数据压缩能力、极优的查询性能，特别适用于物联网应用场景。

• 大数据平台

提供了完备的大数据托管服务、智能API、众多业务场景模板以及人脸识别、文字识别、语音识别等服务，帮助用户实现智能业务。

平台架构

15172-20190105103155305-2078914335.png

通讯协议

15172-20190105103156306-230507899-2.png

MQTT

• 维持活跃消息

可以用来检测client和server之间的链接状态，同时可以维护NAT地址映射表

• 遗愿消息

当client和server断开链接后，server需要往指定的topic发送特定QoS级别的消息

• 保留消息

一个特定主题的消息会保留到服务器，当任何一个client订阅这个主题，都会首
先收到这个消息持久化订阅

• 持久化订阅

当client和server断开链接后，所有发往这个主题的消息都会保留，等client重新链接后，会重新发给client

MQTT 发布/订阅

15172-20190105103158373-545214813.png

开源的MQTT

• 单机版本

Mosquitto、Moquette、Apollo、RabbitMQ

• 分布式

EMQTT

MQTT Architecture

15172-20190105103159432-588559220.png

高可用

15172-20190105103200548-115260158.png

MQTT层堆栈

15172-20190105103201486-556224538.png

跨机器Router

15172-20190105103202423-304398493.png

Router性能优化（字典树）

15172-20190105103203372-1669603937.png

Router性能优化（Cache）

15172-20190105103204456-1722679751.png 15172-20190105103205652-1223282885.png
15172-20190105103206792-1408858305.png
15172-20190105103207820-786951922.png
15172-20190105103208931-1251370932.png

数据一致性

• 支持同一client发布消息顺序性
• 保证每个订阅者收到来自同一个broker上发送到同一 个topic消息的有序性
• 不同Broker发送消息顺序取决于他们发送到这个 broker的时间决定的
• 不支持各个client之间消息全局有序 这样就需要选择一个master来分配每个消息的ID
• 对于MQTT大部分场景来说，没必要全局有序

数据一致性范例

1、C1 发送消息到 M1, M2, M3 主题 T2
2、C2 发送消息到 M4, M5, M6 主题 T2
3、M1必须在M2，M3之前到达T2
4、M2必须在M3之前到达T2
5、M4必须在M5，M6之前到达T2
6、M5必须在M6之前到达T2
7、T2收到的消息可能是C1和C2发送消息交织的结果

大数据并发处理架构

15172-20190105103209874-1154056818.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、零售O2O、智慧物流、节能减排、智能硬件、车联网