开发者学堂课程【物联网平台实操入门：IoT设备接入基础（四）】学习笔记与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/1031/detail/15122
IoT设备接入基础（四）
四．设备接入协议&实践
接着来介绍一下设备的协议，IOT平台支持的设备接入协议，一个最基础的就是MQTT，这也是现在物联网上面用的最多的一个协议，它是一个基于TCP的发布订阅模式的异步通信协议。HTTP就是一个超文本协议，这就不介绍了，HTTP应该都熟悉。COAP是基于6LowPan的一些低功耗局域网的协议站设计的应用层协议，它基于rest，架构风格跟HTTP格式很像，都是Req/Rsp，区别就是COAP是基于udp的，HTTP是基于tcp的，在协议方面比较精简，在低功耗上会用的相对来说比较多一点。
在右边列了这三种协议在不同的场景下的一些情况。先来看一下协议层，对比MQTT和 COAP协议，比如MQTT协议这一层是TCP，COAP是UDP。MQTT COAP都是为了低功耗设计的，通信方式有差别，MQTT是pub /sub的模式，COAP是Req/Rsp的模式。这个pub /sub是消息队列MQTT的模式，Req/Rsp是RPC的模式。底层的TLS和DTLS都差不多，一个是在TCP下的TLS，一个是在UDP下的DTLS。它主要区别是在推送消息的实时性，比如针对MQTT协议，因为它走的是tcp的长连接，所以如果业务服务器要往设备推一条消息，那么实时性是非常高的，基本上业务服务器一推，设备马上能收到或者能直接反馈，实时性上这个推送时MQTT非常有优势。
COAP会有延迟，因为所有的数据一般都是设备主动去获取Req，服务端回复Rsp。COAP协议设计时目的更多的是用于，它为什么走COAP协议不能直接推送？因为它跟协议类型有关，它是走UDP的。现在网络一般都是在net后面，用的都是IPV4。因为现在这个IPV4全球都紧张，所以IPV4基本上都放在net后面，就会导致延迟问题。那么延迟之后COAP模式不能把消息推送走，UDP不能直接下退下去，所以导致COAP要推送数据都是通过历史，比如通过定时的来发Req获取一个消息，但是定时req对COAP协议能耗方面会有一些增加，所以一般COAP还是用的相对比较少。
但是如果把IPV6全部普及了，大家都是用IPV6了，那就没有net的问题了,也不会有ip数量的资源的问题了，所以走ipv6理论上来说这个UDP不会出现延迟问题，也可以快速既不走Req/Rsp服务端也能快速的将消息推到设备端。所以COAP协议设计上还是更相偏向于IPV6的，这就是MQTT和COAP的最大的一个区别。不管是MQTT还是COAP设计的都是非常经典，所以在网络开销上两个都差不多，它们的主要区别主要还是在实时业务服务器推送的实时问题。
HTTP的主要问题就是一个功耗问题，在嵌入式设备上HTTP用的不是太多。因为HTTP光是传文本协议就很耗资源，包括耗一些网络流量和解析。解析起来也是很麻烦，因为它是文本匹配，跟MQTT COAP比起来,这个解析起来相对来说会比较麻烦。它的实时推送性延期比较大，因为它主要还是Req/Rsp模式。但是HTTP走web socket，或者走H two，这个推送的实时性还是能解决的。但是一般现在用http，比如像平台还是更多的支持的是Req/Rsp模式，没有把HTTP做成长连接，一般做成短链接的tcp，只是用来解决Req/Rsp的问题。网络开销刚才讲解过，就是文本协议可能是对有些设备，比如对流量要求比较高，那如果它用HTTP就会对流量的损耗很大。
下面主要介绍接入协议，阿里云的MQTT协议的一些实现。比如MQTT 3.1/3.1.1特性，它支持的主要是Pub.Sub通信模式，一些服务质量，比如QS0，QS1，QS2，包括clean session，will和保留消息这种能力，它的特性总共有六个，阿里云MQTT特性就是针对协议，主要支持的是上面写的pub,Sub,PING,PONG,CONNECT,DISCONNECT和UNSUB这几种协议，支持clean session这种能力，但是对这些遗嘱和保留消息是不支持的，就比如这个遗嘱主要是用在断开连接时再发一条遗嘱消息出来，现在平台是通过离线消息在线消息来判断，用户没办法自定义，但是可以知道设备离线消息，设备是否离线是否上线，会将上线消息离线消息在控制台透出，跟will的实现比较像，跟遗嘱实现有点类似，但是缺少了自定义的一些能力。
保留消息主要用在保留最后一条消息，在设备订阅时获取到最近的，因为这个现在还没找到比较合适的场景，所以现在还没支持。第四表示支持QoS 0和Qos1,不支持QoS2。第五针对SUB QoS，按协议标准SUB QoS都是能够支持的，SUB消息也支持QoS0 QOS1，但是现在支持的比较简单，以PUB消息支持的QOS0，就不管叫什么，以PUB QoS 0为准来支持的。
还支持了另外一个特性，在业务服务器往设备调用时支持了一个RPC，其实就是RRPC模式类似于HTTP，在业务服务器，如果要获取设备的特性，就要通过一个类似HTTP调用就会整条链路同步的等到设备结果返回，就是req/rsp就的模式。现在阿里云还支持MQTT 5.0的一些特性，特性主要有以下几个。
第一个就是报文长度的设置，第二个是user properly，用户属性列表，主要是为了解决MQTT3.1，假如要在设备上面传一些特性或者一些东西上来，其实没办法传上来，只能在cland ID里做扩展，但是cland ID里面扩展起来不是很优雅，做起来会比较麻烦，所以5.0支持properly，由key和value的形式来填各种属性数据，包括新增了一个响应模式，响应主题就是让设备端支持的req/rsp，本来的MQTT都是通过来做一些PUB/SUB，假如要通过一个PUB消息，等服务器返回一个消息,那么要做req/rsp就请求相应的这种模式，只能通过业务保障PUB/SUB，才能做这种请求相应模式。
MQTT5.0点直接在协议上面支持这种请求响应的一种模式，就是设备的请求响应的一种通信方式。第四增加了一些错误码的返回，更多的一些返回，比如以前在设备MQTT 建连失败时，MQTT connect act是返回错误很少的，只有四五个。MQTT 5.0 针对错误码做的细分，基本上能包含现阶段所有功能的一些错误信息相对来说会更好一点。第五点主要是用来解决，因为topic像阿里云线的MQTT协议都是比较长的，它里面包含了PKDN这种东西，整个topic比较长，5.0可以把topic整成一个整形数，那么在传输的过程当中可以减少MQTT报文长度，主要就是为了解决网络的流量问题。这就是阿里云MQTT的能力的介绍。
下面来介绍一下怎么来用这些能力解决问题。提供的总共有六种接入模式。比如一机一密，一机一密是用来解决什么问题的？一机一密就是需要在每个设备都烧录一个设备身份，这样有什么好处？好处就是安全性会比较高。但是它在烧录时因为每个设备都要烧录不同的身份，那在烧录时你对厂商来说就相当于要有自己的一套程序去管理这个设备，不能把同一个设备，同一个身份烧到不同的设备里面，那可能到时候会引起一些安全性的问题。比如两个设备都是摄像头设备，那如果把同一个身份烧到两个设备里面，就会有一些隐私方面的问题，所以这个对烧录的要求会比较高，一机一密安全性会比较高一点，但是对厂商来说烧入的要求会比较高。
这个一型一密是解决什么问题？一型一密就是所有的设备都烧入同一个PK和同一个PS，那就相当于是所有的同一批产品，所有设备都用同一个产品型号，同一个密码，通过这种方式在烧录的时候很方便，在认证的时候通过一些动态注册的方式，在每次认证时通过在设备上自己生成一个DN。在认证时通过PK PS对这个通道加密，把这个DN注册到平台上，平台就会把设备对应的DS返回给你，相当于最终还是用了平台的身份，包括PK DN DS，但是就相当于在烧入时简化很多，只要烧入PK PS。但这种方式也会对安全性带来隐患，因为所有设备都是烧录的，是同一个PK PS，一旦一个设备被破解了，可能整一批设备都会被破解，在安全性上面还是有一定的隐患。这种更适用于对安全性要求不高的设备，一般可能会采用一型一密，因为毕竟在烧录的时候比较简单。
第三种直连就是用X509证书，在设备上面不烧录平台的身份，烧录的是一张X509证书，这个安全性会比较高，因为X509证书是通过双向认证，双向认证对整个安全来说就相当于是服务端要认证设备端，设备的也要认证服务端，整个TOS 对现有的安全保障来说是比较高的。现在X509可能会用在一些支付场景上，因为对安全性要求非常高，但是它的代价也比较大。在建连时可能传输的两份数据，就相当于证书要传输两份。对整个设备的内存ram rom，或者对CPU，都会有比较高的要求，X509只适用于在安全性要求非常高的一些场景。
另外一种直连ID2也是设备，它跟X509差不多，但是唯一的区别就是它可以在设备建立连接时可以不用传证书，不管是设备端还是服务端都不用传证书，在网络开销上会低一点，它的安全性跟X509是同一级。还有一种接入方式就是网关，左边的接入方主要是分直联和网关，直联加身份直连时怎么在设备上面预置一些身份，包括一机一密， 一型一米 ，X509，ID2，这些都是可以直连的。网关本身也是直连的，网关也是直接连到平台，但是网关做的更多的事情是代理设备的局网的一些子设备的上线。
现在子设备的上限是通过消息就相当于是通过MQTT connect，是通过MQTT的pub协议来支持子设备的上线，子设备的上线也支持一机一密和一型一密。网关是直连的，它支持上面四种所有的身份的一种方式，网关都是可以支持的。但是子设备只支持这两组一机一密和一型一密。因为像ID2 X509这两种模式都是在建通道时做的一个认证，子设备是是通道建完以后发pub消息时才能做子设备的上限，子设备的上限都是在消息里做的，所以它跟通道已经没有关系，子设备只支持这两种模式：一机一密和一型一密。
再说另一个接入方式是一种是云云对接，云云对接主要是为了解决，比如平台不支持协议，平台支持MQTT COAP HTTP，它在这种协议都不是的情况下，比如设备是什么Modbus JT808这种协议，那怎么上物联网平台，是通过这些设备先连接到用户自建的一个业务服务器里，再在业务服务器里通过泛化的SDK做转换，转换以后再由泛化SDK连接到阿里云的IOT平台上，这就是云云对接，主要是为了解决阿里云不支持的协议设备的接入。
下面介绍一下网关。这个网关是干什么的？前面提到网关是代理子设备上线，网关有两个痛点，比如这里介绍的主要是大型工业网关，在一些工业场景网关下，子设备可能挂了几千个或者挂了上万个网关，下面挂几千个几万个设备的情况下，网关怎么去代理这几万个设备或者一万个设备数据的快速上云的能力。因为现有的大型网关有两个痛点，一个就是大型数据上云是很难，之后讲解为什么会难上。第二个是怎么去解决快速登陆的问题，因为一旦子设备多了，刚才提到子设备是通过pub消息来上云的，比如一万个设备，就得发一万个pub消息才能上云，所以针对这种子设备的上云怎么来快速解决？
首先来看一下下面的架构，最左边是一个子设备可能要上万个，旁边是一个大型网关，比如每个网关只能建一条连接，那建一条连接会有什么问题？假如上万个子设备数据要同时发数据，一个T C P连接肯定会导致瓶颈，因为一条TCP连接肯定只能接入到一个接入网关里，那接入到一个接入网关会对这个接入网关形成瓶颈。比如下面一万个子设备同时发一条消息，对这个记录网关来说就是一万个KPS。接入网关里面光是一条连接就要支持一万KPS，肯定是比较难的，光是发一条消息就相当于接入网关后不能做其他事情。
接入网关也可以有多条连接，比如接入网关可以连100个大型网关，可以通过LinkSDK可以连100个接入网关，那就相当于把这个数据打散到100台机器上，主要策略是要将大数据打散，打散采用的是网关这边支持多个连接。一个网关可以同一个身份，可以在不同的接入服务器上，比如同一个网关接入到100台接入服务器上，这样就相当于将流量打散了100分之一，对接入层就不会有压力，对网关的单个通道，因为它有一百个通道来发数据，所以也不会有什么压力，本来只有一个通道，刚才提到单个TCP通道是有限流的，如果单个TCP通道流量在这种场景下肯定不能用，第一个策略就是通过一个多连接来解决这个问题。第二个就是会针对这些网关数据做一些批量的聚合，聚合以后再对数据做压缩，来减少带宽的压力，在上传过程当中的一些带宽。这是第一个问题，就是大数据上云的问题。
还有一个是快速登录的问题，比如这个网关支持1000个设备或者支持五十万个设备，五十万个设备同时掉线要同时上来，如果因为这条TCP连接，不管什么原因连接断开了，导致所有五十万设备要重新连一次，可能要耗很长的一段时间，包括对网关资源在连接过程当中，可能还不能发消息。对整个系统这个压力是非常大的。那怎么做呢？首先对设备做一些分离，支持一万个有状态的设备，百万个无状态的设备。一万个有状态的意思是，假如一万个有状态的子设备，在网关跟接入层之间连接断开以后，下次连接线上后是要马上感知到的，或者断开了后面数据库就要更新，要将一万个设备全部制成离线子设备。
在这种场景下子设备是有状态的，网关下如果挂一万个以下的设备，是可以支持有状态的，因为就相当于一万个设备下线，网关一下线就会把一万个设备全部制成离线，如果网关怕连上以后，就可以让一万个设备快速的上线。通过一些批量登录，比如在网关是50个50个一次的登录，可以让子设备快速的登录。一般网关登录的分为两个步骤，一般网关要加子设备的一个拓扑结构。网关要加拓扑，加完以后再来登录，在协议上面也做了优化。针对网关的拓扑添加和登录，这两个步骤可以合并成一条，相当于有服务端来将拓扑和登录两个事情一起做，设备只要发一条信息就可以了，这种是一万有状态。
百万无状态设备是什么？因为也会有一些场景在工业上，它其实对设备，比如这个大型网关下面挂了一百万的子设备，网关断开时不想要全部再重新登录一遍，可能网关只是因为自己断电，比如网络拔了一下电，下次希望的是网关能快速的连接，再上电连接建立后，将这个状态继续维持着，这也是一种业务场景。
针对下面的一些子设备，掉不掉线感知不是很强烈的一种场景，就可以用百万无状态。它的好处就是在网关建立连接时不需要再重新登陆设备，不需要再重新登陆设备就相当于网关是非常快，但是它也可能会有问题，这个状态不是很一致，因为子设备可能是某个子设备下线以后需要自己主动的告知，就是网关等下次登录以后，自己主动感知到后来告诉平台这个设备下线，再给这个设备下线，不然这个设备可能永远是在线状态，所以各个优势缺点还是比较明显的。至于优势，这个大型网关能力差不多是在9月份上线，主要的好处的就是解决两个，一个是大数据商业，还有一个是分钟级子设备的快速登录的问题，万级设备基本上只要分钟级别就能全部上线。这是关于网关的介绍。
最后介绍接入层的稳定性保障，接入层的稳定性保障是为了解决什么问题？虽然I O T平台有多个集群，比如这边有集群架构，有集群1，集群2，集群3，但是在有些情况下，如果这个集群因为别人的业务影响的情况下，可能期权会出现问题，那怎么来做一个稳定性保障？整个架构分成三块，比如买了实例，就会有一个实例域名，实例域名会转到中间的中间域名上去。这边有一个中心化的部署中心，可以认为是统一接入层，主要是做一些路由的，它把不同的实例路由到不同的集群里去，如果在集群一出问题的情况下，就可以有统一接入层，把实例全部调到集群2，这样保障快速的容灾能力，不需要等集群1恢复设备才能使用，就可以快速的切到集群2里去，这是一个能力。
假如是后面的IOT平台多集群挂掉，IOT平台的隔离集群一挂掉，假如是中心化的部骤统一接入层集群挂掉，应该怎么做？统一接入层集群有多个集群，这个集群一挂掉，就可以通过中间域名，本来这个实例是指到集群1的，可以通过中间域名把I P直接改成集群2，那就相当这个流量也能过来，但是这个调用跟刚才的内部调用区别是在，这个可能会因为改域名会有延期，时间上面会相对来说慢一点。这个中心化集群因为接入层基本上没什么业务，它类似于做了一个网络代理层，稳定性会可靠很多。比如平时平台的稳定性都是由变更导致的，而统一接入层变更非常少，所以首先它变更少，第二就是它的功能比较简单，所以这个中心化部署的统一接入层是稳定性非常高的。同时它又有多个集群，所以稳定性还好。
这边有稳定性的时候，又通过统一接入层的一些实例，用户维度的一些路由能力或者整个集群的调度能力，将集群实力直接调到另外一个集群上面去，通过这样来保证设备接入的稳定性。这就是最近推出的一个高可用实力。这个主要优势是什么？第一个百万设备分钟级别容灾切换，是指针对后面的集群，如果挂掉的情况下，可以在一分钟内把设备，比如有一百万在集群1里面，可以在一分钟内把设备全部调集群2里面去，而且在这个调度的过程当中，设备这一侧是不会感知掉线的，这就是在容灾切换时又利用session转移的能力，前面提到的接入层的设计转移，通过转移来把集群一的流量全部迁移到集群二或者集群三里去。这就是最近推出了最核心稳定性的保障能力。
问：这套东西是否在只能在阿里云上开发？
答：应该都是可以的，可以私有化部署，也有专门的私有化部署的一整套系统。
问：MQTT版本接入是手动选择的吗？
答：MQTT版本的接入，不清楚现在用的是零SDK还是用自己开源的MQTT来接入，这个选择的版本是自己手动指定的。比如你想用3.1或者是5.0，其实都是手动指定的。但是平台3.1或者是5.0都可以支持。
问：平台内部设备模拟器与RT studio生成的微博服务器，怎么接入的？
答：如果是web的服务器可以通过web socket的接入，如果是用浏览器接入到平台，可以用web socket的协议，比如TCP上面是MQTT，TCP上面是web socket，web socket里面再找MQTT协议是可以接入的。
问：设备接入到美国节点可以用国内的ECS吗？
答：如果业务服务器在国内，可能会导致一个问题，你的数据流转不出来，就相当于美国数据没法直接到中国，你的设备只能从美国接入到华东二，华东二的数据再流转到你，但这样在网络方面可能会有些差，因为从美国到华东二稳定性会差一点。
问：数据的备份是怎么备份的？
答：不清楚这个数据备份是指什么数据，这个数据备份后面是有存储的，比如设备数据上报以后，在I O T平台会做数据的存储，这个存储会有多备份。比如用O T S这种数据都是有多个备份数据的。
问：规则引擎和服务器订阅有什么区别？
答：服务器订阅指什么，比如你自己的业务服务器支持mqp协议或者是H two的协议，直接做就相当于你的业务服务器直接来订阅我们的服务器。规则引擎更多的可能是指数据，可能流转到一些云产品里去。
问：别人能查到吗？还是只限自己的账号？
答：肯定是只能自己账号能查到的，数据从用户维度，实例维度全部都做了隔离，自己的数据肯定是只能自己查到，其他人是查不到的。问：阿里官方能查到吗？
答：阿里官方也查不到，阿里官方就相当于数据存在数据库里，如果没有你的账号，也不知道怎么去查你的数据。你个人的数据要查，肯定要你的账号，自己的阿里账号，登录到你的控制台上去才能查。谁也没办法来查。
问：存量设备的协议太多了，这个都都需要按sdk接入太痛苦了。
答：现在设备的接入，包括用S D K接入，也可以用自定协议接入。存量设备可以通过，假如是你的协议不是阿里云sdk支持的，可以通过泛化的协议接入。
那今天就回答到这里。
