M2M
Topic
上行：
raw/dev/{productKey}/{sn}下行：
raw/server/{productKey}/{sn}QoS：
1
method | 说明 |
|---|---|
消息通讯 |
功能说明
云服务器架设MQTT云服务，客户购买的设备通过MQTT协议接入该服务器，设备的SN必须保证唯一，否则会出现A客户订阅到B客户的设备数据。
应用平台和采集/中台部署在客户服务器上，连接MQTT云服务，动态订阅其所属设备的Topic，并可发送消息给设备。
由于多个客户都通过同一个MQTT服务进行接入和数据交换，为了保证每个客户只看到自己购买的网关/仪表数据，采集/中台需要实现2方面主要功能：
采集/中台启动时，根据系统中已有的设备序列号SN清单，进行消息订阅，例如：
禁止通过通配符订阅： raw/dev/+/+ ，这样会订阅到其他客户的数据。
当平台新增设备/删除设备/修改设备SN时，采集/中台需要动态添加/取消/变更订阅的Topic。
采集/中台接受到消息后，根据其中的protocol属性，判断协议类型，然后将其流转到相应的协议解析代码中进行处理。 此方案无法实现设备的自动注册。因为MQTT云平台上没有集中管理设备和项目的对应关系，只能由部署在客户服务器上的采集/中台来判断需要订阅那些设备的数据
消息加密压缩
由于所有的消息订阅都来源于已经在平台中登记过的设备SN，所以在登记设备信息时，只需要登记其是否启用了压缩、加密，以及相关算法，即可在收到消息后根据设备信息，判断是否要进行解压、解密。
消息处理
在中台/采集订阅数据时，通常是初始化一个（或固定的有限数量个）订阅者连接到MQTT broker，所有报文都会通过该订阅者进入中台/采集进行处理，如果出现大量消息同时上传，就会出现消息排队，如果其中某个消息处理时间较长，就会出现后续报文无法及时处理，导致设备端认为业务超时的问题，所以，需要将报文分为同步处理和异步处理这两类。
同步处理报文指的是设备发出报文，中台/采集需要处理完成后，根据处理结果回复设备，或者数据量比较小、实时性要求高，不允许排队的业务场景，例如：通知报警、对时、设备请求OTA、下发指令的回复。
异步处理报文指的是数量比较大，并且可能出现同时收到大量报文，使其他业务报文同时排队，出现超时问题。例如：实时数据在收到后，需要存储原始报文、存储电参量报表、计算能耗+极值+需量，单条报文耗时较长，如果出现大量设备同时上报实时数据，会导致报警等数据一起排队，从而出现无法及时处理报警消息的问题。对于这类报文，通常就是先将其收下来放入缓存队列，然后通过一个定时任务分批次进行处理。同时，为了避免其中某一条数据超时，导致后续所有报文都出现较高延迟，可以使用线程池将报文按照批次进行隔离处理。
其中比较特殊的是登录报文，登录可以根据实际情况，选择采用同步或异步的处理方式，主要是考虑是否需要对大量设备的并发接入进行限流。因为设备登录后会继续发送对时、拓扑、实时数据，如果大量设备同时登录成功，短期内会出现大量数据涌入，可能会造成数据库或缓存的负载提高，所以通常建议用同步的方式进行处理。
通讯报文
1.设备端使用Topic raw/dev/{productKey}/{sn}， method为raw ，消息格式如下：
参数 | 说明 |
|---|---|
| 必填，String或Integer或Long，消息id。 |
| 协议类型，全部大写。 |
| 必填，String，表示消息的业务类型。固定为"raw"。 |
| 必填，String，设备sn编号。 |
| 必填，Integer或Long，消息生成的unix时间戳。 |
| 必填，String，消息内容，如果是透传报文，则使用字符串表达；如果是中台/海外协议，则是一个JSON字符串。 |
2.响应报文
参数 | 说明 |
|---|---|
| 必填，成功为1，失败为0。 |
| 错误编码。 |