IoT亿级设备接入层建设实践——实践类

72 阅读 0 评论 48 点赞

我是靠谱客的博主结实钻石，最近开发中收集的这篇文章主要介绍IoT亿级设备接入层建设实践——实践类，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

一、前言

不同的接入层

互联网的产品基本都需要解决终端的接入问题，每个接入层会因为终端数量、终端能力、网络环境等不同的因素有各自的设计特性，比如：淘宝网需要解决海量短连接问题、微信需要解决海量长连接问题，同时大家都要解决移动网络问题，那么阿里云IoT物联网接入层需要解决的是什么？在回答这个问题之前，先来看看物联网的特性

物的特性

既然要解决"物"的问题，那么首先需要了解"物"，先来看看这些"物"包括哪些，这些物有什么特性？

居家类：电视机、音箱、开关、灯泡，空调、洗衣机等
基础设施类：水表、电表、燃气表等
工业场景：产品信息、质量信息、设备能耗信息等
安防类：摄像头、门磁、烟感等
其他：汽车、手表、眼镜、单车、门锁、充电宝、起搏器等

"物"的种类非常多，应用场景、成本各不同，比如水表一般安装在户外，一般采用电池供电，这种设备对能耗的要求非常苛刻，比如基站铁塔的后备电源，一般安装在荒野，这种设备对网络的要求非常苛刻，比如开关，这种设备对存储、内存、cpu的要求非常苛刻，不同的"物"特性催生了不同的IoT接入层，下面来看看IoT接入层需要做什么？

二、IoT接入层需要解决什么问题？

2.1 接入层关键问题

通用接入层需要解决的问题

安全性：通道安全、身份安全、数据安全
连接方式：采用TCP、UDP，使用长连接还是短连接？
协议选择：http协议、protobuf协议、mqtt、coap、私有协议等
网络问题：就近接入/就快接入、系统及TCP/IP协议内核参数的调优等
海量连接问题：当海量连接在线时，怎么保障系统的可用性？

IoT接入层有什么不同

特性：多样性、碎片化

针对这些设备特性，IoT接入层需要怎么来解决？

2.3 相同的问题，不同的解法

安全性：各种设备都联网后，设备将在我们的生活中更加根深蒂固，给安全带来更大的挑战，比如：汽车、门锁、起搏器等收到安全攻击，那么用户的隐私、财产、生命都会带来严重的威胁。IoT场景下很多设备对存储、内存、cpu、网络都有要求，那么在设计安全时，就不能简单的通过加强加密的安全方法来解决这个问题，因为它们执行复杂加密和解密的速度不足以让它们实时安全地传输数据。IoT接入层既要考虑安全性，又要对受限设备做妥协，需要怎么去平衡两者的需求？

网络问题：IoT场景下的网络更加复杂，通信层面包括有广域网技术：GPRS/4G/5G/Lora/NB-IoT等，有局域网技术：Ble、ZigBee等，不同的通信模组会有不同的网络质量，怎么来保障网络稳定性，网络RT是非常关键的点。IoT场景下很多设备只能采用局域网通信技术，这类设备不能直接上网，需要边缘网关来代理上网，针对边缘网关的场景，接入层需要怎么设计？一个边缘网关下面可能挂了几万个设备，如果一个通道来处理的话，怎么解决单通道的拥塞问题以及单通道的热点问题？如果多通道来处理，这些通道之间怎么建立网络拓扑模型？

协议选择：一般的接入层只会选择一种协议(比如淘宝的http、钉钉的lwp、微信的私有协议)，但是IoT不同，它需要支持多种协议，支持这么多协议，就是为了解决不同的业务场景，比如业务场景会主动给设备推送消息(共享充电宝、共享自行车等)，那么需要使用tcp长连接来解决，这种情况下采用mqtt+tcp协议会比较合理。比如业务只需要设备上报消息(水表、电表等)，不需要发控制指令给设备，那么采用coap的udp短连接就比较合适，既能省能耗，又能省流量。比如业务需要在浏览器上使用，那么http的tcp短连接就比较合适，天然的适配。比如业务已经有大量存量设备，同时采用了私有协议，连接了自建的平台，但是现在又想要接入阿里云IoT平台，使用平台各种能力(数据分析、监控、生态等)，那么采用泛发接入是比较合理的做法，通过泛发协议把私有协议转成标准协议，设备不需要改动，只要在自建平台做个适配层就可以了。

三、怎么解决IoT的接入问题，阿里云的优势在哪里？

3.1 安全设计

对于系统设计来说，安全是基础，但又不能因为安全问题影响用户体验，需要在安全性和体验上找到平衡点，同时对于低功耗设备需要有不同的安全考量，那么阿里云IoT接入层是怎么来做的呢？

核心思想：通过三层安全防护机制 + 云端的安全风控模型来保证设备的安全性

三层防护机制

第一层：DDos 防护系统

基于阿里云强大、专业的DDos安全防护体系，防止IoT业务出现重大经济损失、数据泄露等问题，详细参考DDos防护

第二层：通道安全

通过支持TLS、DTLS、X509、ID2 四种方式来解决通道的安全问题，同时针对低功耗设备，做了多个维度的优化

不同传输协议上的TLS：mqtt协议跑在TCP之上，而coap协议跑在UDP之上，针对不同的传输协议，IoT接入层分别实现了TLS、DTLS，用来解决不同协议的通道安全问题
流量维度：TLS认证流程中，需要把服务端证书传给设备端，大概消耗4K左右流量，同时要求设备支持非对称加密算法，对于某些低功耗设备来说，能耗、流量、加密能力都是有要求的，IoT接入层通过PSK技术，解决证书传输带来的流量消耗问题，同时解决非对称加密算法对cpu的性能损耗问题
RTT减少1次：TLS的握手需要2次RTT，正常公网的RT 50毫秒，两次RTT需要消耗100毫秒时间，为了减少网络交互次数，IoT接入层实现了sessionTicket技术，利用sessionTicket的复用能力来减少通道建立过程中的RTT次数，同时也去掉了证书传输和非对称加密

注：ID2是阿里云安全团队实现的类TLS协议，能力跟X509的双向TLS对等，同时在双向认证的基础上，减少了设备证书的传输，适用于对安全等级要求较高、同时对设备流量有要求的场景。

第三层：设备身份授权及验证

阿里云IoT的设备身份叫三元组，由平台授权颁发的设备身份信息，每个设备全球唯一，在设备建立连接时，设备通过DeviceSecret加签设备信息，然后有平台对加签信息进行验证，用来完成设备登陆IoT平台，保障设备的安全性。

三元组指的是ProductKey、DeviceName、DeviceSecret的组合。

ProductKey：是物联网平台为产品颁发的全局唯一标识。
DeviceName：在注册设备时，自定义的或系统生成的设备名称，具备产品维度内的唯一性。
DeviceSecret：物联网平台为设备颁发的设备密钥，和DeviceName成对出现。

云端一体的安全风控体系

为了进一步提升设备的安全等级，阿里云IoT建立安全风控模型，针对设备暴力认证、设备恶意连接等行为，采取主动预警，快速阻断等措施，为设备安全保驾护航。比如某个设备不停的来认证，但是每次认证都是因为签名验证而失败，同时设备每次上传的签名又不同，根据这三个条件基本可以判定该设备存在暴力认证的行为。

3.2 网络优化

直连网络

不同的通信模组(GRPS/3G/4G/5G、Ble/ZigBee)，不同的部署环境(电梯、地下车库、荒野)，会导致各种不同的网络差异，给设备的连接稳定性带来风险，阿里云IoT针对这些问题，是怎么来解决的？核心思路：让设备就近接入，同时提供稳定、高速的网络环境。阿里云IoT接入层通过部署多region(如下图)的方式来为用户提供就近接入的能力，通过BGP网络为设备提供稳定、高速的网络环境。

BGP网络有什么优势？

消除南北访问障碍。由于BGP可以将联通、电信、移动等运营商的线路“合并”，使得中国南北无障碍通讯成为可能。对接入层来说，可使“联通、电信”这类区别消失，更能使一个网站资源无限制的在全国范围内无障碍访问，而不需要在异地部署VPN或者异地加速站来实现异地无障碍访问。
高速互联互通。原来一条线路访问另一线路往往要经过很多层路由，但实现BGP以后就像进入了高速公路。
质量最好的网络：从运营商网络质量来看，BGP带宽是中国内地地域目前最昂贵的、线路质量也是最好的线路。对于延迟要求比较苛刻的业务可以使用BGP线路来解决。

就近接入

先来看看用户怎么就近接入？分两种情况：

设备使用的区域确定：设备厂商在生产设备时，已经知道设备需要卖到哪些地方，对于这类情况，设备直接写死就近的region接入地址就可以了。
设备使用的区域未定：设备在生产时，并不清楚设备在哪个区域使用？这种情况肯定不能直接写死一个接入地址了，这种情况下，首先需要解决的是设备的区域归属问题，解决这个问题有两种方式：一种方式是让用户指定设备的归属地，这种方式比较普遍，比如买苹果产品时，不管iphone，ipad都会在设备初始化时要求设定一个归属地，还有一种是根据设备IP地址来判定，可以做到无人工干预，完全自动化，但因为IP库存在一定的误差，这种自动化同时也会带来归属地判定的错误。

那么阿里云IoT针对这两种归属地判定场景做了什么优化？

用户指定归属地：用户可以在配网的时候设置归属地到设备里，也可以在阿里云IoT平台提前预置设备的归属地，设备只需要在接入IoT平台之前去设备引导服务获取就近接入点地址就可以了。这里有个问题：去哪里获取设备接入点地址？阿里云IoT只部署一个中心，然后通过全球设备引导服务中心+加速通道+智能域名来解决这个问题。
自动判定设备归属地：为了减少IP判定带来的误差，阿里云IoT支持产品的多区域指定能力，比如可以指定设备可能会在新加坡，上海、美东等地使用，然后动态的根据IP+设定区域来判定设备归属地，这样的精度就会有明显的提升。

region覆盖不到的区域的网络优化方案

阿里云IoT通过多region部署来满足设备的就近接入，但是region数量有限(部署region的代价较大)，不能解决一些偏远地区的网络问题，IoT接入将通过部署前置节点 + 智能动态路由能力来解决这个问题。比如把IoT前置接入点(不需要部署整个region)部署在离偏远地区最近的机房，然后通过该前置接入点代理设备登陆到指定的region中，然后在前置接入点跟指定region部署加速通道，这样就能解决这些偏远地区设备的网络问题。

边缘网关

针对网关设备，如果子设备较多的情况下，会带来哪些问题？

网关下有10w个子设备，同时每个子设备定时数据上报，需要怎么设计？
网关下的10w个子设备，因为网关下线，全部需要断线重连，需要怎么保障子设备快速上线？

大数据的上报的解决方案

阿里云IoT的网关技术方案核心技术点：

多通道：一个网关有多条物理TCP连接，每个物理连接等价，网关可以往任意一个物理连接发送或者接受数据
子设备虚拟连接：网关代理子设备上线，每个子设备对应一个虚拟连接的session
子设备&自连设备打平：服务器对子设备跟直连设备等同处理，唯一差别就是直连设备有独立channel，子设备是共享物理channel，这样设计便于设备的各种运维操作

通过多通道解决了网关的海量数据上报问题、通道的热点问题，同时解决了通道容灾问题。

通过虚拟连接解决了子设备通道复用的问题，不需要为每个子设备建立一个TCP连接。

通过子设备和直连设备打平解决了各种运维的复杂性，子设备相当于一个直连设备。

子设备的登陆慢的解决方案

核心思想：优化登陆速度、减少离线次数、延迟离线时间+增量同步策略。

业务场景：针对不同的子设备数量，可以采取不同的策略，比如子设备在1000以内，可以只提升登陆速度就可以了，如果子设备在10w以上，建议多种策略配合，同时根据业务对设备的状态敏感度来定义这些策略，比如子设备全部下线了，业务都无所谓，那么建议网关按简单的来处理，串行/并行批量登陆都是可以的。

优化策略：

提升登陆速度：通过并发批量登陆来解决。
减少离线次数：首先需要定义网关离线，只有网关的全部通道都断开了，才认为网关断开，这样可以通过多通道的模式来减少网关的离线次数。
延迟离线时间+增量同步策略：服务端只有在网关离线一段时间后，才会把所有子设备下线，如果网关在这个时间段内重新登陆，那么网关只需要登陆/离线在这个时间内有变动的子设备。

其他优化点

阿里云IoT接入层不尽对应用层做了很多积极的优化，同时对系统内核、CPU、网卡、TCP内存参数都做了优化，连针对防火墙、路由器等中间网络设备都专门做了优化

TCP/IP内核参数优化

TCP三次握手的优化：半连接队列、全连接断链、syn重试策略、syn+ack重试策略、fastopen等
TCP传输的优化：初始窗口大小优化、tcp内存优化、支持缓冲区的动态调整、快速重传策略等
TCP四次挥手的优化：主要是针对time_wait状态的优化、孤儿连接优化

系统优化

网卡队列大小优化
利用reuseport来提升TCP建连性能

针对防火墙的优化

对于mqtt的1883端口，有些防火墙可能会阻断连接，阿里云IoT通过支持443端口来绕过这个问题

针对路由器的优化

对于一些非标的路由器，可能不支持分片，因为MSS报文太大而被这些中间路由器丢弃，导致设备连接不上或发送数据异常，阿里云IoT通过优化MTU大小来解决这个问题

3.3 架构设计

对于协议的选择，阿里云IoT采取的是标准化策略，通过标准化来解决设备之间的互通问题，通过标准化来解决设备接入平台的理解成本，标准的好处很多，不一一列举。这里主要讲讲多种标准协议和接入层怎么适配？怎么在系统发布时，设备做到无感？怎么让每个设备在连接层、协议层都做到连接高可用？

协议层和接入层适配

核心思想：接入层、协议层分离，让接入层更纯粹、让协议层支持更多的能力。接入层更纯粹指的是什么、协议层支持更多的能力是什么意思？

接入层更纯粹：让接入层只做接入的事情，包括：基础网络优化、智能路由、TLS卸载、证书管理、限流等，这样做的好处很明显，接入层只有基础能力，不支持任何业务特性，没有业务特性也意味着减少系统变更，减少了系统变更意味着更加稳定(据统计80%以上的故障都是变更引起的)，同时为了解决接入层发布带来的设备批量断连问题，阿里云IoT接入层支持二进制热更新能力，在接入层发布过程中，可以不断开设备连接，同时为了让设备更快的体验新能力，可控的触发设备重连(比如针对连接一直稳定的设备，在发布新功能后，让设备在低峰期慢慢的重连)，通过不同的组合策略，让设备连接更稳定。

标准协议层支持更多的能力：这里的能力指的是在协议层上做的各种业务特性，同时也包括协议本身的扩充能力。业务特性包括实例逻辑隔离、实例规格能力限制等，协议的扩充：比如mqtt 3.1通过pub、sub来模拟通用的RPC能力(解决用户控制设备的能力，比如用户通过手机借用共享充电宝的业务)，通过clientId字段打标来支持payload的解压缩能力，通过压缩能力减少设备的流量，通过智能心跳机制减少心跳报的发送。

通过两层分离机制，让接入更稳定，同时让业务更快的迭代发展。

3.4 连接高可用

通用的高可用策略：副本、隔离、failover机制。副本是最常用的做法，对于连接来说，副本就是每个设备建立多通道，如果同一个设备有多个通信模组(比如：4G+wifi)，还可以根据不同的模组建通道，这个成本对于设备端和服务端来说都会比较高，想做成通用比较麻烦，但是对于边缘网关设备确实可能会有这种业务场景，后续我们会支持起来，那么阿里云IoT现在的策略是什么？隔离 + failover

连接型实例的物理隔离(隔离)：提供连接型实例，让设备可以独占物理资源，在物理上做到实例的连接完全隔离。
设备端重试(failover)：提供SDK支持设备快速重连能力，同时支持重连的指数退避策略，防止因为服务本身问题而不停的重连，导致设备资源的消耗。
每个设备独享一条通道(隔离+failover)：设备<-->接入层<-->协议层，这三者之间一一对应，这样做的目的是每个设备的连接不会相互影响，在该连接通道上的消息上下行全部隔离。接入层<-->协议层之间也支持了failover能力，比如当协议层应用发布时，接入层会自动把该通道1-1恢复到另一台协议层上，做到了设备无感知。