开发者学堂课程【物联网平台实战课程：设备接入技术交流】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/836/detail/13993
设备接入技术交流
主要内容
一、LoT 协议
二、Lot 接入能力
三、LoT 接入架构
四、平台的设备身份体系
五、平台安全架构
六、设备接入—全球就近接入
七、设备接入—协议介绍
八、设备接入—MQTT 介绍
九、设备接入—接入模式
十、设备接入—大型工业网关
十一、接入层稳定性保障
十二、问题集锦
一、LoT 协议
首先需要连接到边缘网关，然后通过边缘网关来代理上云，根据通讯类型是有两种类型，还有就是根据协议来分，分为标准协议介入和非标准协议介入，标准协议有很多，比如物联网平台比较通用的是 MQTT，COAP 和 Http，行业的非标准协议指的是一些私有协议、各个设备厂商或者是一些企业自定义的协议，物联网平台支持的有 MQTT、COAP和 Http 这种标准协议下行业的一些标准协议或者一些私有协议，一般要介入物联网平台，是通过自建服务器，在自建服务器上面集成泛化协议。通过在私有服务器，把私有协议通过泛化协议 SDK 转换成标准的 MQTT 或者 Http 这 种协议，再通过这种方式连接到接入平台，物联网平台一个是接入处理，一个是消息的处理，互联网平台包括支持一些基础的能力包括设备管理、设备认证以及针对于设备的一些数据的一些物的描述。包括一些其它的性能包括监控运维、数据分析等等一些基本的能力，大致就是以上流程，从左边的传感器上面采集数据，然后到接入层互联网平台对接入层做一些处理，然后通过规则运行流转出去，最终流转到用户的业务服务器上面，可以流转作为两种方式，一种是MQTT 协议，另一种是通过云产品中转，再流转到业务服务器上面，这就是 IoT 基础架构-全链路的架构。
然后是接入服务器的一些能力，即接入服务器做了哪些事情，左边就是接入服务器的一些基础能力，它主要包括五块，第一部分就是安全保障，不管对于哪个平台来说安全都是第一位的，包括稳定性的保障，稳定性的保障就是企业业务都在平台上，如果平台稳定性不能得到保障，会对企业业务造成影响，会形成不可用的状态。尤其是对于接入路程来说，如果接入路程出现问题，那么所有的设备都会出现无法接入的问题。相当于所有的业务都会停滞，所以对用户的影响会非常大，因此，稳定性的保障是非常重要的。
第三部分是海量设备的接入，从系统架构方面怎么来保证一些海量设备的接入问题。
第四部分讲的是全球接入，设备是各个国家都有，如果要让国外的设备接入到国内来，那么网络的稳定性以及发消息的延迟，都可能变得会非常差，所以它还支持一个全球接入的能力。
第五部分是支持多种标准协议，因为设备的碎片化非常严重，有些设备是电磁的，有些设备摄像头能力可能情况稍微好一些，如果让电磁的设备去使用 http，对能耗和流量使用比较大的协议，对用户的设备来说是很大的挑战，所以针对不同的设备提供了不同的协议，可以让设备根据自身的资源情况，来选择不同的标准协议来接入。
二、Lot 接入能力
1.接入基础能力
l 安全保障
l 稳定性保障
l 海量设备接入
l 全球就近接入
l 多种标准协议
2.稳定性保障
（1）限流、降级能力
l 系统资源限流
l 租户维度限流
l 实例维度限流
l 产品维度限流
（2）连接隔离
l 连接资源独享
l 连接资源逻辑隔离
（3）数据隔离
l 集群隔离
l UID/实例隔离
3.协议种类
（1）标准化协议
l Mqtt
l Coap
l Http
l Websocket
l AMQP
l HTTP2
（2）私有协议
l 自定义协议
l 云云对接
4.安全通道+负载群体
l 高防系统
l 负载均衡集群
l 安全通道：TLS、DTLS
5.就近接入
美东、美西、德国、日本、新加坡、华东、华北、华南
l BGP 网络
l 智能 DNS
l 加速通道
l 全球设备分发中心
向稳定性保障协议种类和安全通道加负载集群以及就近接入这四个方面，都是针对于接入基础能力的实现。例如，就近接入就相当于提供了一些基础的能力，region+智能路由+BGP 网络+加速通道+全球设备分发中心这些能力来支持全球就近接入，后面会有专业一页讲解全球就近接入。
再上一层是安全，包括一些高防系统，高防系统适用于防止一些 DDOS 的攻击，比如说负载均衡集群就是用来解决海量设备的一些接入，可以动态的随便扩展，然后这些通道安全是指为了解决通道层面在数据上传的过程中的数据安全问题。上一层就是支持的一些协议的种类。
再上一层就是稳定性保障，稳定性保障分为几部分，首先是合理的技术来保证稳定性，通过一些限流降级，包括一些能力来保障系统的稳定性包括，所有应用无单点这种问题来解决稳定性保障。稳定性保障有很多，这里只列举的几项，一个是隔离，一个是降级和限流，后面再看一下接路程的架构设计。接路程的架构设计分为几部分，最左边是各种协议和各种设备都有可能。中间的部分包括设备接入，包括一些负载均衡的集群，包括跌倒式的防御，这是第一层，然后后面是设备接入层，稍后针对设备接入层的三个能力进行讲解。
再后面就是标准协议层，设备接入层会把一些流量或者数据，通过一些规则路由到标准协议层，由不同的协议层来解析不同的协议，就近接入的知识会单独讲。首先看一下接入层，有三块核心的能力，包括稳定性保障。稳定性保障对于接入层来说做的是比较薄的，核心的能力包括并发件连，主要也是来做一些限流措施，防止很多设备都打到同一台Ecs 上面去，把某台设备的 ecs 的 cpu 打到所以做了一些件连的限流。
第二部分是连接的数量，连接的数量更多是有目的性的，就例如单机，比如说四核八机，撑起了二十万三十万的 TCP长连接，这就防止因为不做限连，单机连接数会非常多，导致机器的内存 CP 消耗光这种情况。
三、LoT 接入架构
Ø 限流策略
l TCP 并发限流
l TCP 连接数限流
l TCP 流量限流
Ø 技术核心
l 每个设备独享 TCP 连接
l Session 转移
l 二进制热更新
l 连接负载均衡
l 智能路由
l 接近接入
连接流量的限流，比如说现在物联网平台最多连接的就是 MQTT 的连接，通过 MQTT 连接接入进来，MQTT 是一个TCP 长连接，每个 TCP 长连接管道里面，每秒能够发送数据的流量，像平台限制的是256k，主要是为了防止某一个单个设备流量太大，比方说某个设备不受限制，它可能发了100M，单机 ecs 也就是100M 的处理能力，会导致其它连接的公平性有所损失，导致其它数据不能处理。所以针对于每一个连接都做了流量的限制，防止某个设备流量太大导致一台机器上的其它连接受影响，这是最基础的稳定性保障。接入层最基本的能力包括证书的卸载以及证书的管理和智能路由，智能路由就是比方说一个设备接入，通过实地 ID 帮助其达到某一个集群，比方说后面标准协议层可以分成很多集群，通过智能路由的能力，把设备或者实例或者是根据住户 ID分 发到不同的集群里面去，这样可以保证各个集群的隔离即不同的用户在不同的集群里面。
第三部分是关于高阶能力，在说 session 转移之前先说一下连接是如何设计的。比方说设备通过 MQTT 集群上来，建立一个 TCP 长连接到设备接入层，然后会在设备接入层再次建立一个 TCP 长连接到协议层，就是说整条设备的 TCP链路是独享的，不会出现TCP链路上有多个设备的情况，每个设备都是独享 TCP 连接的，Session 转移的意思是平时协议层都会发布，在平时发布的时候，假设说 MQTT 集群有1000台机器，其中一台机器要发布，那么在发布之前会把这一台机器上面的所有设备通过 session 转移的能力转移到另外一台 MQTT 上面去，通过这种转移可以做到在标准协议这一层发布的时候，不会出现 TCP 长连接断开的这种现象，通过 session 转移来解决 Season 发布的时候一些设备断开连接的问题，这就是 session 转移的含义。
第二部分是应用热更新，应用热更新说的是统一接入层，在应用更新的时候，它自己本身也有可能更新，有时候比方说能力升级的时候也会进行更新。TCP 长连接是直接都连在统一接入层的，如果是在正常的情况下，在发布的时候把应用程序关掉，那就相当于所有设备都会断开连接，应用热更新的意思就是在发布的时候，不会直接把老连接的一些设备连接全部断开，而是相当于两个进程同时存在，老进程不再接受新设备的建联，所有设备的建联都会连入新的设备里面去，老的进程再过一段时间以后，比如设备根据自己的情况都慢慢下线以后，在设备数量比较少了以后，统一接入层会把老的进程慢慢的连接关掉，可能用户都没有感知到，有很长的时间让设备自己慢慢的下线，以上就是热更新的能力。就相当于用来解决统一接入层发布时候导致的设备断开连接的问题，这两个能力结合起来的时候，Session转移和应用层热更新，基本上说设备的接入在发布时不会导致设备的连接断开，或者出现设备在发布的过程中设备发不了消息的情况，这些情况都不会出现。
第三是负载均衡能力，统一接入层怎么把连接分配给后面的 MQTT 里面，在 MQTT 的协议层里面和统一接入层之间，它有一个流量感知的功能，会根据 MQTT 集群里面每台机器的负载的情况，来选择下次比如说收到链接以后，通过负载均衡机制，应该往 MQTT 负载小的一台机器上去打。这就是 IoT 接入层的整体架构，包括统一接入层的基本能力，还有就是协议的能力。
四、平台的设备身份体系
平台支持三种身份，可以通过输入这三种身份，直接登录到平台来。第一个身份是平台身份，平台身份指的是平台上的 PK+DN+DS 这三种，每个设备在平台上面是唯一的。超永久既是一种双向通道，也是一种身份。超永久证书就是在设备上面，不用刷入平台身份，只需要刷入超永久证书，然后在平台上面把超永久证书和平台的身份在控制台上面做一个绑定，保证以后就可以通过超永久证书模式登录到平台，然后平台会做身份的转换，平台内部还是通过平台身份来做一些数据的流转。
第三个身份是 ID2，它是阿里 云 IoT 安全团队自己推出的，它和超永久一样都是双向认证，它的好处是在双向认证的过程中的一个证书，因为在双向认证的时候要两边包括设备向服务端传证书，是服务端向设备传证书，它相当于直接把证书的流程优化掉，既可以保障设备的安全性，又可以减少在设备建联的时候的一个证书参数流量的消耗的问题。
设备身份体系
Ø IoT 平台身份获取
l 单个创建设备:在控制台创建，复制设备信息
l 批量创建设备:在控制台创建，然后批量下载
l 云端 API 创建︰通过云端提供的 API 创建设备
Ø X509身份获取
l loT 颁发的X509证书︰在控制台创建，认证方式选择 X509，创建 loT 设备后，自动生产 X509证书，X509证书自动跟 loT 身份绑定
l 用户颁发的X509证书︰在控制台创建，认证方式选择 X509的私有 CA，在设备管理-CA 注册上注册私有的CA证书
Ø ID2身份获取
l 动态创建设备︰购买实例时开启 ID2，创建 ID2的产品，然后购买 License 数量，设备 DN 可动态创建
这三种身份在平台上基本都可以获取，可以在控制台上面或者直接创建单个设备。一般厂商设备会量产，所以推出了批量超链设备。在控制台上面可以直接创建，也可以通过第三种方式即有开发能力好的企业可以直接通过云端提供API，通过 API 快速创建设备，这些是平台身份的获取。
X509参份获取有两种方式，第一种是阿里云 Iot 平台直接颁发 X509证书，拿到证书以后直接去设备上输入就可以，X509证书会在平台上面自动跟平台身份做一个绑定，绑定之后就可以使用X509证书进行通信。还有一种方式是用户自己颁发的 X509证书，这种就相当于在平台上面，注册一下自己颁发的 X509证书。
还有一种设备身份体系是 ID2身份获取，它会在专门的 ID2控制台，在这控制台上面开启 ID2能力以后直接购买，通过设备 DN 可动态创建设备。这些就是平台的身份体系。
五、平台安全架构
1.平台安全
Ø 数据安全
租户隔离、实例隔离、物理隔离
Ø 身份安全
平台身份、X509、ID2
Ø 通道安全
TLS、X509、ID2
Ø 安全防御
DDoS、高防、准实时拦截、离线分析
2.数据分析
Ø 安全分析
l 认证暴力破解
l 身份信息泄露
l 连接未加密
l 低 TLS 版本
l 设备验证失败
Ø 实时处理
l 禁用设备登录
l 通知用户
3.安全策略
l 4层安全机制
l 实时拦截
l 大数据预警
在平台测针对安全做了四层的防护。第一层主要是用来防止黑客通过 DOS 做一些流量攻击，通过高防可以清洗几百g的流量，一般来说，如果用户自建平台，清洗几百 g 的流量，可能性比较小，最底层是安全防御的能力。
再上一层是一些通道安全，一种是单向的 TLS 认证和 X509，它既是一个身份又是一个通道，ID2也是一样，它只是一个身份，也是一个通道，通过这三种加密方式，保障数据在互联网上传输的过程中数据的安全。
再上一层是身份安全，指的是前面提到的平台身份、X509和 ID2，每一个设备都有一个身份，建立安全通道以后，下一步要做的就是身份认证，每一个设备在平台上面都有唯一的身份，通过身份认证以后，才能真正的上传数据，上传数据的时候对数据进行安全测定，比方说会针对每个用户的数据做逻辑上面的一些隔离，包括一些实例也会做逻辑上的隔离，比方说接入层有连接型实例，它支持物理隔离，物理隔离的意思是如果购买了连接型实例，设备上来以后有物理接入层的一个机群，就可以把设备区分开来。在接入层的物理方面就已经隔离开完成，这就是平台的四层安全保护机制。包括后面的一些大数据分析，包括会对设备的认证行为或者包括通道的 TLS 版本或者身份做一些安全分析。防止用户做一些暴力破解，如果用户没有加密，通过大数据分析以后做一些预警，通知用户设备没有进行加密、版本比较低等等，TLS1.0会有很多安全漏洞，同时还会有一些实时的处理，针对平台发现有一些数据，正在做一些暴力认证或者做一些攻击行为，会有一个实时处理程序，可以快速的把设备拦截掉，这就是整个的安全平台。简单来说，一是平台支持四层安全架构，再加上一些大数据分析，根据大数据分析的结果再来做一些拦截，通过这样的机制来保障设备上平台的安全性。
六、设备接入—全球就近接入
设备卖到其他国家会有设备接入平台，会影响平台的网络的稳定性并且可能出现消息延迟的问题，为了解决以上问题，阿里云 IoT 支持8个 region，国内有三个大的 region，国外有五个，可以选择任意一个 region 接入，但是 region 与 region 之间的数据是隔离的，可以说一个设备不能同时到两个 region。八大 region 作为底座，如果有一个全球分发能力，此能力是来解决设备归属到哪里的问题，用户可以直接在控制台上面把设备，比如说设备卖出去之前，厂商在生产的时候不知道这些设备会卖去哪里，如果这一批设备都卖到欧洲，那就把在控制台上面把这些设备分发到其他国家，就相当于把设备的源数据写入到其他国家，就相当于把设备分发到某一个 region，再发完以后再设备接入的时候，它的第一部就不是直接接入了，它会首先获取一下设备到底属于哪里，发出去已经把问题处理掉了，它就会通过就近接入，通过智能 DNS 在国内进行就比较简单，基本上不会有什么网络问题。国内直接通过 BGP 网络直接到达上海分发中心，确定设备的位置是在上海、北京还是深圳。然后全球分发中心会把设备所占的接入点的地址发送给设备，设备会把地址存起来，下次再使用，就可以直接连到对应的最近的接入点上面去。针对于国外的设备，设备先通过 DNS，解析出来设备的归属地，因为全球分发中心在上海，全球分发中心知道数据源，因为设备在国外想要连接国内，那肯定会出现网络问题，所以在中间支持了一个全球加速通道，通过一个专线，比如如果在其他国家，那就直接在相应国家的全球加速流的接入点，通过接入点接入以后，通过内部走专线，直接走到国内，这样国外设备获取，就近接入点方面可以快速稳定的进行获取，主要就是做全球加速专线。通过 region 分发，再加上加速来解决，所有设备的全球就近接入的能力。
七、设备接入—协议介绍
Ø MQTT 协议
介绍:MQTT是基于 TCP/IP 协议栈构建的异步通信消息协议，是一种轻量级的发布、订阅信息传输协议。
Ø HTTP 协议：
介绍：超文本传输协议。
Ø COAP 协议：
介绍:CoAP 是6LowPAN协议栈中的应用层协议，基于REST(表述性状态传递)架构风格，支持与 REST 进行交互。
一个最基础的就是MQTT，它也是现在物联网上面用的最多的一个协议，它基于 TCP 发布订阅模式的一个异步通信协议，类似于 http 是超文本协议。COAP 是低功耗局域网的协议设计的一个应用层协议，它基于 rest 架构风格和 http协议格式很相似，区别就是 COAP 基于 UDP，HTTP 是基于 TCP 的，在协议方面比较精简，在低功耗方面用的比较多一些。
先来对比一下 MQTT 和 COAP 协议，MQTT的协议层是TCP，COAP的协议层是UDP，MQTT 和 coap 都是为了低功耗而设计的，通信方式有差别，MQTT是Pub/Sub模式，COAP 是 Peq/Rsp 模式，一种是消息队列的 MQ 模式，一种是 RPC 模式。底层方面来看，tls 和 dtls 相差不大，一个是在 TCP 下面的 tls，一个是在 udp 上 dtls。主要的区别是在推送消息的实时性，比方说针对 MQTT 协议，因为 MQTT 协议走的是 TCP 的长连接，如果业务服务器要往设备上推送一条消息设备是马上可以收到的。在推送实时性层面，MQTT 非常有优势，Coap 会有延迟，所有数据一般情况下都是通过设备主动去获取发送一个 inquest，服务端回应一个 response。
CoAP 协议在设计的时候，不能够直接推是因为与它的协议类型有关，它走的是 UDP，现在的网络一般都是在 net后面，用登录的 IPV4放在那个后面就导致打动的问题，net 打动就会导致 COAP 这种模式不能把消息走的 UDP 直接下退，所以使用 COAP 传输数据都是通过定时的发给 Quest 来获取消息，如果定时发送给 Quest 会对 COAP 能耗方面有一定的增加，所以一般现在 coap 使用量比较小，IPV6如果全部普及，就没有 net 问题，也不会有 IP 资源的问题。所以如果走 IPV6方式，COAP 也不会出现延迟问题，不走 response 模式服务端也能快速的把消息传到服务端去，所以在设计方面 Coap 还是偏向于 IPV6的，以上就是 MQTT 和 Coap 的区别。其实它们两个的网络开销、设置的都是非常精简，在网络开销方面其实都差别不大，它们两个主要区别还是在推送实时性方面。
Http 最主要的问题就是功耗问题，在嵌入式设备上面 Http 还使用的不是太多，因为 HTC 的文本协议比较消耗资源，包括一些网络流量解析起来也是比较麻烦，它是文本匹配，和 MQTT、COAP 比较起来解析比较麻烦一些，它的推送实时性也会延期比较大，主要还是因为 Request/Response 模式，没有把 http 做成一种长连接的 TCP，一般是做成短连接的TCP 用来解决 request response 问题，它的网络开销对流量的消耗要求比较高，如果使用 http 最流量的损耗还是比较大的。
八、设备接入—MQTT 介绍
Ø MQTT 协议介绍
介绍:MQTT 是基于 TCP/IP 协议栈构建的步通信消息协议，是一种轻量级的发布、订阅信息传输协议。
Ø MQTT 特征
l Pub、Sub 的通信模式
l 消息服务质量
l clean session
l will , retain msg
l 协议简单、易实现
l 低开销、低带宽
Ø 阿里云 MQTT3.1/3.1.1特性
l 支持 MQTT 的 PUB、SUB、PING、PONG、CONNECT、DISCONNECT 和 UNSUB 等报文。
l 支持 clean session。
l 不支持 will、retain msg。
l 支 持 Qos0、QoS1，不支持 QoS 2。
l 不支持 SUB QoS，消息 QoS 以发送方(PUB)指定为准
l 基于原生的 MQTT Topic 上支持 RRPC 同步模式，服务器可以同步调用设备并获取设备回执结果。
Ø 阿里云 MQTT5.0特性
l 支持设置客户端和服务端发送报文的最大长度，直接过滤冗长的消息
l 支持设置 UserProperty 属性列表，每个属性由 Key 和 Value 组成，用于传输额外的属性数据。
l 新增了响应主题(ResponseTopic)和相关数据(CorrelationData)，类似 HTTP 请求响应的模式，实现双方通信。
l 增加了更多返回码，便于设备快速定位请求状态及问题。
l 支持将消息通信 Topic 缩小为整型数值，来减小 MQTT 报文，节约网络带宽资源。
MQTT3.1/3.1.1主要支持的是 Pub、sub，一些服务质量比如说 QoS0、QoS1、QoS2，包括 clean session，包括遗嘱、保留消息的能力，阿里云 MQTT 主要支持的是 PUB、SUB 等协议，支持 clean、session 这些能力，但是对于遗嘱和保留消息是不支持的，比如说遗嘱是指在断开连接的时候，再发送一条遗嘱消息出来，平台是通过离线消息在线休息，用户没有办法进行自定义，但是用户可以知道设备是否处于离线状态以及是否上线来控制台把离线消息、在线消息透出，和V2的实现比较像，遗嘱消息有点类似，但是缺少了自定义的一些能力。
保留消息主要就是保留最后一条消息，在设备订阅的时候获取，由于现在还没找到比较合适的产品，所以还没有支持。它支持 QoS0、QoS1，不支持 QoS2，如果是找协议标准那么 SUB 和 QoS 都是能够支持的，但是现在支持就是支持的比较简单，消息 QoS 以 pub 指定的为准。还支持了另外一个特性，在业务服务器往设备调用的时候，支持了rpc（也是 RRPC）模式，类似于 http 在业务服务器要获取设备的特性，通过 http 调用就会整条链路同步等到设备结果返回，其实也是 request response 模式。
现在阿里云还支持 MQTT5.0特性，一个是报文长度的设置，还有就是 User property 就是用户属性，它是为了解决比如像 MQTT3.1，假如说设备上面要传一些特性是没有办法传上来的，只能在 Cland ID 里面做扩展，但是扩展起来会比较麻烦，所以5.0之时 user property 可以传输额外的属性数据。新增了响应模式比如说响应主题，让设备端支持Inquest response，本来 MQTT 是通过 pub 消息等服务器返回一个消息，如果想要使用 Inquest response 这种请求响应模式，通过业务上传去保障 pub sub 在同一个里面，才能够做这种请求响应模式，MQTT5.0就直接协议上面原生支持做请求响应模式，是设备的请求响应的一种通信方式。意思就是增加了一些返回码，比方说之前在 MQTT 建联失败的时候，MQTT connect at 返回的错误码是很少的，可能只有四五个。MQTT5.0针对错误码做了细分，包括现阶段所有公文的错误信息。其次像阿里云的 topic 都是比较长的，里面包括了 pk、DN 等，就导致整个 topic 比较长。5.0就把topic 缩小为整型数值，这样在传输过程当中可以减少 MQTT 报文长度，主要就是解决网络流量问题，以上就是阿里云 MQTT 的介绍。
九、设备接入—接入模式
1.直连：一机一密
简介:预先为每个设备烧录其唯一的设备身份，安全性高。
2.直连:一型一密
简介:同一产品下所有设备可以烧录相同的设备标志信息，烧录方
便，支持设备身份预注册和免预注册。
3.直连: X.509
简介:设备烧录不依赖阿里云 loT 的设备身份，安全性高。
4.直连: ID2
简介:类似 X.509的安全性，网络开销低。
5.网关
简介:代理局域网子设备上线，支持一机一密、一型一密。
6.云云对接
简介:解决非 MQTT、CoAP 和 HTTP 协议的接入，比如 GB/T26875.3 -2011、Modbus、JT808等协议
共有六种核心的接入模式，机机密就是每个设备都需要烧录平台身份，这样安全性会比较高，因为每个设备都需要烧录不同的身份。对于厂商就需要有一套程序去管理设备，不能把同一个身份烧录到不同的设备里面，这样可能会引起一些安全性问题，比方说两个设备都是摄像头设备，把同一个身份烧录到两个设备里面去会出现问题，所以对厂商烧录的要求会非常高。但是一机一密安全性会比较高。所有的设备都烧录到同一个 PK 和同一个 PS，这样同一批产品下面的设备都使用同一个产品型号、同一个密码，通过这种方式在烧录的时候会很方便，在认证的时候相当于通过一些动态注册的方式，在每次认证的时候，在设备上面自己生成一个 DN，在认证的时候通过PK PS，对 DN 通道进行加密，然后把 DN 注册到平台上面来，平台会把设备对应的 ds 返回，这样最终还是使用了平台的身份包括 Pk、DN、DS，在烧录的时候会简化很多，这样会对安全性带来一些隐患，所有设备上烧录的都是同一个 TCP，一旦一个设备被破解，整批设备都会被破解，在安全性上面，还是有一定的隐患，这种更适合对安全性要求不高的设备，在烧录的时候比较简单。
第三种是直连 X509，这种就是设备上面不烧录平台的身份，烧录的是 X509的证书，其安全性会比较高，X509证书是通过双向认证。服务端使用设备同时设备端也要进行认证，TLS 对现有的安全保障来说是比较高的。现在 X509主要是用在支付方面，对安全性要求非常高，但是它的代价也比较大，在建联的时候可能需要传输两份数据，证书需要传输两份，对设备的内存、CPU 都有很高的要求。所以 X509比较适用于对安全性要求非常高的场景。
直连 ID2类似于 X509，唯一的区别就是它在设备建立连接的时候，可以不用传证书，在网络开销方面比较低，安全性和 X509是同一级的。
方式主要分为直连和网关，本身其实网关也是直连的，网关也是直接连到平台，但是网关做的更多的是代理局域网址子设备的上线，现在子设备的上线是通过消息，通过 MQTT 的 pub 协议，来支持子设备的上线，子设备上线也支持一机一密和一型一密，网关也支持以上四种接入方式。子设备只支持一机一密和一型一密，像 id2和 X509这两种模式都是在建通道的时候做的一个认证，但是子设备不是建通道，是通道建立完以后发 pub 消息的时候，才能子设备的上线。子设备的上线都是在 pub 里面做的，所以说跟通道已经没有关系了。
最后一种接入方式是云云对接，它是为了解决一些状况，比方说平台不支持 Mqtt、COAP 和 http 协议的接入，它在这种协议都不是的情况下设备是其它的协议，那么在物联网平台是通过这些设备，是先连接到用户自建的服务器里，然后再在业务服务器里面，通过泛化的 SDK 做转换，做完转换以后，由泛化 SDK 连接到阿里云的 LOT 平台上面去，主要是为了解决那些阿里云不支持的协议的设备的接入。
网关是代理子设备上线，网关有两个重点，这里讲的主要是大型网关，一个网关下面可能挂了几千个甚至上万个设备，在这种情况下网关怎么去代理这几万个设备数据快速上云的能力，大型数据上云是很难上的。
第二个是快速解决登录的问题，一旦子设备多了，子设备是通过 pub 消息上云的。比如说一万个设备就需要通过一万个 pub 消息上云，如何快速解决子设备上云问题，子设备可能上万个，每个网关是只能建立一条连接，如果上万个仔设备同时发送数据，一个 TCP 连接只能接入到一个网关里面，一个接入网话会对接入网关形成凭借。一万个字设备同时发送一条消息，对接入网关来说也是一万个。接入网关里面每一条连接就要支持，一万个 qps，肯定是比较难的，可以说只是接入网关就不能再做其它事情了。
十、设备接入—大型工业网关
➢痛点
l 大数据上云:支持单设备的大数据上云能力,解决工业场景等大点位问题
l 快速登录:支持百万子设备分钟级登录的能力
➢关键技术点
l 多连接
l 批量上报、数据压缩
l 设备状态分离
l 批量登录
l 添加拓扑+登录合并
➢优势
l 单网关海量数据快速上云
l 1w 子设备分钟级上线能力
现在就相当于把它改成了接入网关也可以有多条连接，大型工业网关可以通过 LinkSDK 可以连100个网关，相当于把数据打散到100台机器上面去，主要策略相当于把数据打散，打散是通过网关这边支持多个连接同一个身份可以，不同的接入器上面，比如说同一网关接入到100台接入服务器上面去，相当于把流量打散为1/100，对接入程序就不会有什么压力了。
对网关的单个通道，因为是一百个通道发送数据，相当于也不会有什么压力了，当个 TCP 通道是有限流的，当个 TCP通道在这种产品下面是不可以用的，第一个策略是通过一个多连接来解决问题。第二个是针对于网关数据做一些批量的聚合，聚合以后对数据做一些压缩，减少在上传过程中对带宽的影响。主要是大数据上传的问题和快速登录问题，例如五十万个设备同时掉线，如果同时上来，那就需要考虑什么导致这条 TCP 断开，TCP 断开就会导致50万设备重新连一次，可能会耗费很长的一段时间，包括对网端资源在连接过程当中可能还不能发消息，对整个系统来说压力是非常大的。正确做法是先对设备做一些分离，支持一万个有状态的设备，一万个有状态的意思是在网关和接入层之间，连接断开以后下次连接上之后，需要马上感知到。断开以后数据库要进行更新，在这种场景下面，子设备是有状态的，但是只支持网关挂一万个以下的设备，这种是可以支持有状态的，网关下线就把一万个设备制成一线。
如果网关连上以后，那就可以让一万个设备快速上线，通过一些批量登录，比如说是50个一次，可以让子设备快速登录，一般网关登录分为两个步骤，一般网关要加子设备的 top 结构，top 加完以后然后进行登录，然后在协议上面做了优化，网关的 top 添加和登录可以进行合并。相当于服务端把 top 和登录两个事情同时做，设备只需要发一条信息就可以，以上是一万有状态设备的含义。
针对百万无状态设备是也会有一些工业上的场景，比方说大型网关上面挂了100万子设备，网关断开的时候不想要全部再重新登录一遍，希望状态继续维持，针对于下面的子设备，感知不是很强烈的一种产品就可以使用百万无状态。它的好处就是在网关建立连接的时候，不需要再重新登设备，这就相当于网关非常快，它有可能会有问题，可能状态不是很一致，可能某个子设备下线以后需要自己感知后主动告诉平台设备下线，不然设备很有可能就一直是在线状态，优势和缺点都是比较明显。
大型网络会在九月份上线，主要的好处就是，解决大数据上云以及几百万子设备分钟级登录的能力，分钟级就能全部上线。
十一、接入层稳定性保障
➢解决什么问题？
l 容灾能力:支持分钟级别的调度能力,解决容灾.容量、灰度等稳定性问题
➢关键技术点
l 实例调度
l 用户调度
➢优势
l 百万设备分钟级容灾切换
l 容灾切换时设备无断连接
接入层稳定性保障有时候虽然 IOT 平台有多个集群，在某些情况下，如果集群因为别人的业务影响的情况下可能集群会出现问题，稳定性保障需要进行考虑。现在先把整个架构分成三块，买的实例会有一个实例域名，实例域名会转到中间域名，有一个中心化的部署统一接入层做一些路由的工作把不同的实例路由到不同的集群里面去，在集群一出问题的情况下，统一接入层把实例全部掉入集群二里面，这样可以不用等到集群一恢复设备才能进行使用。
如果统一接入层集群化掉该如何去做，统一接入层集群有多个集群，假如集群一失败，就可以通过中间运营，本来这些实例是指到集群一的，可以通过中间运营把IP直接改成到集群二，这样也能流量过来。修改运营会有运营期相对来说会比较慢一点。但是中心化集群接入路由层，因为它没有什么业务，相当于做了一个网络代理层，稳定性会可靠很多，平时平台的稳定性都是由于变更导致的，统一接入层相对来说变更比较少，而且它的功能也比较简单，所以中心化部署的统一接入层稳定性是非常高的。同时，它又有多个集群。通过统一接入层的实力以及路由能力或者整个集群的调动能力，把一个集群调到另一个集群里面去，这样来保证设备接入的稳定性。这就是最近推出的高可用实例。
这样主要优势就是可以百万设备分钟级登录，它的意思是如果后面的集群挂掉，那么可以在一分钟内比如说有100万设备在集群一里面，一分钟内把设备，全部调到集群二里面，而且在调度的过程当中，设备这一测试不会感知掉线的，在切换的时候运用了 session 转移的能力，通过 session 转移，把集群一的流量全部迁入到集群二或者集群三里面去，这就是最近推出的最稳定的保障性能力。
十二、问题集锦
1.是否只能在阿里云上进行开发？
是的，阿里云有整套的私有化开发系统
2.MQTT 版本接入是手动选择的吗？
是手动指定的，比如说想用3.1或者5.0，都是手动去进行指定的，平台是3.0和5.1都能支持。
3.平台内部设备模拟器和 IoT studio 生成 web 服务器是怎么接入的？
web 服务器可以通过 web studio 接入，如果是用浏览器接入到平台，可以使用 web 上的协议，TCP 上面是 MQTT，TCP上面是 websites，Web 再走 MQTT 协议也是可以接入的。
4.设备接入到美国节点可以国内的 ECS 吗？
业务服务器在国内可能会导致数据流转不出来，美国的数据无法直接到中国，只能让设备从美国接入到华东，让华东的数据流转到 ecs 上面，但是可能稳定性会比较差。
5.数据如何进行备份？
数据后面是有存储的，比如说设备的数据量，设备数据上报上来以后，在 lot 平台，会做一些，数据的存储会有多个备份数据的。
6.服务订阅量与规则引擎的区别
服务器订阅指的是，自己的业务服务器，支持 MQTT 协议，或者是 h2的协议，相当于业务服务器直接订阅阿里云的服务器，规则引擎，数据流转到云产品里面去。
7.设备的状态其它用户可以查找到吗？
只能自己的账号查到，数据从用户维度和实例维度全部是做了隔离的，数据肯定是只能自己查到，其它人是查不到的。想要查找只有自己的阿里账号登录到控制台才能查到。
8.存量设备的协议太多，都使用 SDK 接入比较麻烦怎么办？
设备的接入包括，SDK 接入也可以自定义协议接入，存量设备可以，通过如果协议不是阿里云 SDK 支持的，那么可以通过泛化 SDK 接入。
