一、loT历史背景概述和系统分层介绍

（一）loT发展历史

其实物联网IoT的发展，从概念的出现至今历史时间并不长，大概可以划分为三个阶段：

阶段一：80年代末到2005年，属于IoT发展的萌芽期。此时具备物联网概念雏形的设备开始在市场上涌现，标志性的事件是2005年国际电信联盟组织在一次国际性峰会上，首次明确了物联网概念。

阶段二：2005-2014年，属于IoT初步发展期，在这期间更多消费市场的设备开始涌现，比如在2013年Google Glass眼镜推出，2014年苹果公司推出了自己健康类家居产品Homekit。2014年MQTT协议正式被推荐成为物联网传输的标准协议。

阶段三：自2014年有了协议标准后，从2015年开始各大云厂商相继推出自己的IoT平台。借助于平台的能力，大大降低了硬件接入物联网的门槛，物联网应用也如雨后春笋般涌现出来。

什么是物联网？2005年ITO组织（国际电信联盟）对物联网的标准定义：物联网就是各种信息传感设备，按照约定的协议将任何物品与互联网连接起来，从而实现对设备的管理、定位、跟踪、监控过程。

（二）loT系统分层

物联网涵盖的范围非常广泛，比如说5G、边缘、蓝牙、蜂窝。涵盖了整个产业链，简单对它进行系统分层，大概可以划分几个层次：

设备感知层：主要和硬件相关，包括各种传感器、定位系统等等，参与者是各大硬件厂商。

传输层：负责网络信息的传递，分为无线/有线传输，也可以按照速率，高速的3G、4G、5G、WI-FI，低速的像LoRa、ZGB等等。

平台层：是目前各大云厂商主要立足的层面，负责设备管理、设备接入、应用管理。

应用层：和实际生活最相关，各大方案解决商依托硬件和平台能力，提供各种贴近生活场景的应用。

二、腾讯IoT产品能力和服务架构

腾讯的IoT发展历史如何？最早腾讯IoT发展历史最早可追溯到2013、2014年左右，当时QQ基于QQ的账号体系和关系链，发布了一款“QQ物联”产品，实现在QQ上的账号管理，但当时是基于私有协议。2014年MQTT协议被推进为标准后，腾讯IoT得到重点关注，2015-2016年腾讯内部已经孵化出多个相当出色的IoT产品，2016年对产品能力进行整合，形成了现在的基础物联网通信平台。

2016、2017年基于物联网通信平台产品能力和性能进行产品打磨，基本具有高可靠、高可用的服务特性，目前技术通信平台能支持数亿级别的设备接入，上千万的上下行QPS，提供多种交互方式，比如说公有云、专有云、私有化产品。2017-2019年在基础平台之上完成一站式平台建设，例如腾讯自有能力，AI、大数据提供各种场景应用能力，同时建设了宽带设备的宽带通信Hub平台。从2019年到现在，大概有数亿级别的设备接入，每天光上下行消息就超过百T的级别，专区大概有100多个大客户专区，交付方面有数百个成功的交付案例，整体服务提供99999的可用性承诺。

腾讯IOT有哪些产品能力？腾讯云产品能力主要可以划分为五大块，最底层是三个通信平台，负责窄带设备的基础物联通信平台，负责宽带设备的音视频通信平台，负责边缘节点管理的IECP。基于这些通信平台能力，开发者平台主要是提供各种开发能力，结合各种场景，提供各种应用能力的平台。同时还包括一些管理服务平台，比如说低速网络管理平台LPWA、安全方案平台TID、物联网平台、互联网市场平台。

截止到目前，腾讯云平台服务已经在全球部署了数十个数据节点，协助合作伙伴业务出海。腾讯积极利用开发者平台，推出了腾讯连连平台，整合了开发者的能力。顾名思义，开发者平台主要是给开发者使用的，包括硬件开发者和上层SaaS软件开发者，向下包容了TencentOS对蓝牙协议标准化的识别，上层提供各种应用级别的SDK，比如说小的APP和对外开放的API。还提供大量的数据处理能力，基于AI、基于大数据计算提供报表分析、AI场景能力。

接下来我简单介绍几个比较突出的平台能力，地理位置服务支持多种设备上报信息，基于GPS信息上报信息，基于WI-FI说报信息在平台内部进行数据处理，处理之后进行设备定位，设备定位用来绘制轨迹图、设备分布状态。首先是地理位置围栏服务，可以在地图上简单地通过经纬度输入画出一个围栏，关联某一个设备，当设备进出围栏的时候触发场景联动、告警信息。

其次是提供的可视化数据开发能力，用户在控制台上通过简单的拖拉拽就可以实现数据的开发。最后是应用托管的能力，用户可以将自己的SaaS应用服务托管，直接在开发者平台里进行服务托管，实现一站式的产品体验。

接下来再介绍基础通信平台，也是最核心的通信平台，基本承载了目前超过90%的设备接入能力。其主要的服务架构图，包括用户的各种设备、各种协议，比如LoRa、网关设备、第三方平台等。

此外主要可划分为四个系统，在这之上是用户的各个数据出口，用户个可以用各种PaaS，比如Kafka提供API接口。比如以设备数据上行为例，首先从设备开始发起，到Conn服务、接入服务、消息路由服务，根据消息的类型进行转发，大部分消息通过规则引擎服务，用户可以在规则引擎上配置消息目的地，根据规则进行转发，比如说要将A类设备的消息转发到Kafka，B类设备的消息转发到实际数据库，这是上行该有的链路。

下行链路通过资料关系，辅助系统层面对外提供云API能力，用户调用云API找到消息推送服务，首先查找设备的状态，找到设备当前的连接节点，直接调用节点里的Conn服务再通过连接链路将消息推送下去。

整体服务都是基于异步协程的高性能框架设计，以业务服务为例，整个服务由两个进程组成，一边是协议处理Conn-proxy进程，另一边是逻辑处理Conn-logic进程，两个进程中通过基于内存的消息队列，两组消息队列，一组是上行消息，一组是下行消息。

数据链路设备首先收到消息，Proxy进程本身是多线程的进程，主线程监听到连接后，把连接分发给工作线程，工作线程组里的某一个线程处理后面的连接，进行收包协议处理，收到完整的包之后会扔到上行消息队列里去，同时通过管道FD唤醒逻辑进程，逻辑进程的主线程被唤醒之后。通过上行消息队列里取到消息，根据一样的路由策略路由到自己的工作线程里，工作线程里进行逻辑的处理，比如说调用后端的服务、频率效率等等。如果需要回包，通过同样的链路扔到下行消息队列里，同样唤醒，主线程被唤醒之后，消息路由到工作现成，工作现成找到连接回复给设备。

上述设计最大好处是大部分业务能力变更主要在逻辑处理上，比如会增加频率限制或者某个功能，增加特殊的连接方式。逻辑服务变更比较频繁，这样处理可以导致在逻辑服务变更的时候不会影响接入层和设备连接。同时，这种设计模式形成过载保护，如果上行消息队列获取到消息以后，发现消息已经超过了比较长的时间，比如说超过了3秒代表着服务负载较高，通过内部的机制减轻负载，保证服务的可靠性。

三、腾讯IoT在行业场景中的应用和探索

接下来结合实际中的案例探讨物联网技术在场景应用中面临的问题如何探索。

（一）消费类产品音箱产品

消费类产品大部分的特点首先是数据量级特别大，分布地域非常广泛，因为都是销往地域的，不像行业企业的设备非常集中，就集中在几个城市。其次产品从高端到低端，产品设备资源差距比较大，主要使用蜂窝技术，蜂窝技术主要是产品可以随身携带，路上摆摊随便一放就可以，网络环境2G到4G都有，受限于成本，低端产品可能就几十块钱，设备资源差异较大，最低端产品业务可用内存不到1兆。

其业务诉求有：信息稳定下发；成本低消耗流量少；链路安全。

这个设备主要是两条链路，一条链路是定时上报设备的状态、设备的电量、设备的地理位置信息、设备的网络信号。第二条链路是业务链路，用户发生支付行为后，支付后调用API接口，用户付了多少钱指令下发下去，音箱收到指令就会进行播报，有一定的延时性要求，如果时间过了太久播报就没啥意义了。对这些特点和诉求进行了抽象，简单概括就是在满足硬件资源的条件下实现服务可靠、服务安全。

接下来，我们来看看消费类产品音箱产品中做了哪些探索？

连接可靠

服务可靠首先就是连接的可靠，用户有很多弱网设备，分布地域非常广泛，要解决弱网环境下地理位置带来的连接延时性。给用户推荐的部署方式是大专区多地域的部署方式，在全国建了三个大逻辑专区，加上7个接入前置节点，加起来有十几个接入节点，将移动网络转化为机房内部的高速网络。部署节点以后，怎么保证设备就近连接到接入节点？移动网络里根据DNS群体的方式是很不可靠的，经过多跳的网络先到基站，再到核心机房，再到公共网络，DNS寻址出口非常不可靠。

在SDK里引入了Http-DNS服务，虽然DNS寻址不可靠，但是出口IP一般都比较准确，调用服务获取某个域名的接入点IP，根据出口IP、IP库对比获取就近的节点，从而实现就近的设备接入。发生故障的时候也做了容灾处理，增加了主备域名，当Http-DNS出现故障的时候，就切到传统的local DNS寻址方式，当这两个服务同时异常的时候，比如说Http-DNS服务发生故障了，同时DNS解析也完全被劫持了，或者DNS发生了解析故障，还有容灾兜底的IP，保证它能连接到某一个地区。

通过这一系列的手段，最终保证设备连接到最近的就近节点就近接入，经过测试2G网络情况下大概有84%的设备能完成1秒内的消息触达，4G网络下有98%的设备完成1秒内消息触达。

服务可靠

客户对服务可靠及其可用性要求非常高，当服务机器数增多，比如提供99999的可用性，当我们有一万台机器的时候，几乎每天都有各把机器会发生故障。怎么样保证服务的高可靠性？又会存在哪些问题：机器故障、机房故障、地域故障？

例如，2019年广州有一个机房，市政施工的时候电缆被挖断。怎么解决这些问题？我们是多地域部署的方式，把设备就近接入加上容灾处理，保证地域的容灾可靠。地域的容灾可靠是某一个地域故障了进行切换，切换到就近的另外一个地域，地域内根据机房的分布，至少会选择在两个机房，每个机房set进行部署，每个set由20-30台机器组成，完成服务闭环。如果下一个节点失败了，根据调度系统找到最近的其他set节点重试，全部失败了会写到自己的文件里，通过异步的机制回溯。

DB里选型的是腾讯云的TDSQL，具备高容灾可靠性机制，在主DB里实现了跨机房的1主2备，进行同步更新的机制，保证在机房故障的时候业务毫无感知，可以做好无缝切换。在异地提供了3个RO容灾实例，平时主要负责数据的读取，故障的时候可以手动切换，分钟级别内完成故障处理。对于KV缓存类，通过全局性MQ同步到各个地域，保证每个地域的数据一致性，保证地域之内能够完成业务的完整性。

消息可靠

用户需要下达一条指令，怎么保证指令最终能够到达设备？设备的状态本身是不确定的，可能在线可能离线，可能2G网络下非常差，发一条消息可能要过十几秒才能收到，怎么保证呢？这也是QS1的设计思路，一边是服务，另一边是8K SDK的设计完成消息的可信保障。从服务可以看到业务后台通过API接口调用下发的push服务，push服务收到消息以后首先会查找设备状态，如果设备离线就会将消息存储到离线消息队列里，如果发现设备在线，找到刚才提到的接收层的节点，同时消息会存在区域共享内存的数据结构里。

数据结构主要两部分组成：第一，定时器，记录了下次触发的时间及哈希表的位置。第二，哈希表，存储完整数据。说到push消息，尝试通过Conn下发消息到设备，这时候会出现多种情况：

第一种消息会很快地到达设备，设备很快地顺利处理，回复业务的SDK，业务SDK通过原来的链路原路返回，回到push服务，push会认为设备收到了数据，会在设备结构里消除两部分数据。

第二种如果网络结构特别差的时候，过一段时间定时器会触发APP的指数算法，比如说第一次超过1秒没有收到SDK，第二次超过2秒，第三次超过4秒定时器就会重新触发，重新获取消息，重试逻辑。有时候网络实在是连不通，也不能无限重试，就设定了次数上限，当它达到上限的时候消息不会丢掉，会扔到离线消息队列里。当设备在再次上线激活的时候，会唤醒右上角的状态服务，从离线消息队列里获取到离线消息，一条一条逐条尝试进行下发。

SDK设计前面也引入了消息队列，消息队列主要有两个作用：第一，业务非常繁忙的时候防止下发过快，比如说1秒钟下发了语音播报指令，语音播报是需要时间的，有可能处理的速度跟不上，因此消息队列起到消峰填谷的作用。第二，弱网环境上下发一条消息，迟迟没有收到SDK，过一段时间重复下发消息，消息队列根据消息的唯一标识等性处理，保证不会重复播报一个消息，不然一个用户付完款可能报了两次。

安全保障

给用户提供了全链路的安全保证，首先在前面接入层全部都接入了自研的大禹高防系统，进行流量攻击保护。设备级别还提供了一机一密、软加固、安全平台检测的安全保护。可靠连接方面，提供了Http DNS+主备域名+容灾IP的保护方式。链路通道保护上提供了多个安全保护级别，包括TLS、DTLS、PSK、自研TID安全解决方案。提供了多维度监控体系。用户可以自定义产品的关键属性，比如分钟内设备连接的次数，同向对比超过一定的波动范围会进行告警，右下角是实时监控状态。

接下来我们详细讲解一下怎么做到设备保护和链路保护。设备保护TID安全平台提供了多种解决方案，从SE安全芯片、TEE可信执行环境、软加固等多种信任根方案。相对而言SE和TEE更加安全，软加固的安全级别会低一点，但消费类设备受限于成本限制，最终还是选择软加固的方式。软加固主要是通过指令乱序、数据混淆的方式增加硬件被破解的成本。

链路保护一开始推荐的是标准的TLS加密链路，TLS本身是安全的，但后来在实验过程中发现设备资源非常有限，TLS库本身也比较大，有些设备已经跑不起来了，所以提供了自研的TID安全链路，链路的大概原理首先是基于事实，TID协议里有4次握手，前2次握手是客户端向服务端请求证书，拿到证书之后验证证书链，验证服务端的合法。比如说HTTVS访问就是这种，客户首先请求百度的地址，怎么样保证地址是正确的呢？浏览器里内置的TLS校验返回来的证书链。

物联网场景中有所不同，设备和服务端预先都知道对方的公钥，完全把公钥信息植入到不一样的两边，可以省去交付的过程，同时也可以省去TLS认证证书链的过程，对材料进行裁剪，四次握手变成两次握手，完成身份认证和密钥加密的过程，提供同等的安全防护。经过裁剪，TLS库大概减少了80%。

（二）通用接入能力

随着业务的发展，越来越多传统硬件行业的厂家、中长尾厂家逐渐向我们咨询，尝试接入我们的平台，我们发现他们有一些业务痛点，硬件开发周期长，一个硬件3-6个月落地还算比较快的，和传统互联网节奏相当不同。

其次各种网络连接方式多样，比如说蓝牙、WI-FI等，通信协议每个厂家都要重新再开发一遍。技术资源有限，尤其硬件厂家很少做SaaS类应用，无法保证SaaS类成果，无法保证底层有很好的平台、很好的硬件。最终给用户展示的APP、小程序不美观也是很遗憾的事情。根据业务痛点进行能力抽象，抽象出三部分能力：SDK接入能力、协议适配接入能力、SaaS应用接入能力，主要是为了解决传统硬件厂商中长尾客户如何更加快捷、更加方便地接入平台。

它做了哪些工作呢？对SDK进行了架构上的优化、硬件抽象、跨平台解耦，主要分为四层，最底层的Health层，和硬件相关的，已经适配了主流的平台。再上面是网络层，根据各种网络连接方式，比如说蓝牙、WI-FI全部都设定好了。再上面是IoT业务层，怎么连接，怎么收发消息，怎么OTA升级。最上面是用户业务层，主要是设备收到某条消息的时候该怎么去做，或者设备感知到某个条件变化的时候，比如说温度温感，感知到温度变化的时候怎么通过接口上行消息。

通过硬件抽象以后，对主流硬件平台用户接入时主动关心上层的用户代码，简单进行开发，大大缩短硬件开发的周期。统一了测试标准，提供完整的测试用例，保证测试的一致性和硬件本身的接入质量。对协议适配能力也做了一定的优化，开发量比较大的蓝牙设备基于蓝牙协议数据格式，设备端实现一遍，小程序APP端实现一遍，抽样出来一套Lthink（音）的协议，根据对象的模型和蓝牙协议之间进行行为预设，对设备的管理状态进行标准化，用户如果要接入蓝牙协议的时候，只需要简单地配置模板，使用SDK调整一下编译选项，小程序和APP也是一样的，集成DSK基本做到代码的开发协议接入。

对于WI-FI类场景，现在WI-FI配网形式非常多样，常见的SoftAP，设备充当AP，手机连接将账号密码发送给他，还有蓝牙辅助、蓝牙热点，连接到热点将账号密码发送给它。现在比较新兴比较热门的一键配网，和具有一键配网功能的路由网关将编码的格式，将WI-FI的账号密码通过类似于ASK（音）编码发一个包，这个包多少长度，连接设备。

常见的WI-FI配网方式全部进行抽样化，终端SDK、SaaSSDK全部都进行支持，用户WI-FI配网的设备基本可以做到零代码的开发。第三点是SaaS能力的接入，基于连连品牌的小程序、APP，提供了非常强大的SaaS开发能力，提供了强大的OS能力，用来集成各种第三方平台，开发一款设备，希望同时集成百度平台上的设备，都可以通过这种方式进行集成。还提供服务托管、关系链托管的服务，如果用户不想开发SaaS应用，完全可以将账户托管在服务平台，开发自己的应用、小程序，通过拖拽API的方式调用后台，绑定设备，进行操作管理。

提供的小程序开发能力和免代码开发的面板，用户基于常见的设备完全可以满足，用户也可以自定义一些图标，集成到小程序里来。同时用户基于开发能力自己开发的应用场景，比如基于蓝牙连接的智能跳绳、智能插座等等。

（三）音视频场景下的应用

为什么会有音视频场景的应用？物联网本身是在高速发展的，随着5G时代、物联网提速，越来越多的传统设备不再满足于简单的信令交互，落地的场景，比如说智能家居、智能家电，像空调、冰箱，空调可以进行家庭监控，集成小米摄像头家庭消费摄像头的功能，冰箱也是一样，可能需要监控、音视频通话的功能，以及智能门铃、消费类摄像头、智能穿戴设备需要多人通话的功能诉求。

随着需求越来越大，2019年内部成立了团队，团队主要整合腾讯云内部的音视频能力，提供技术解决方案。TRTC、XP2P、CSS是腾讯内部基于不同场景抽象出来的，TRTC是常用的腾讯会议的能力抽象，原理是实现双人/多人通话，通话的时候会把客户端拉到会议室里多路推流，进行高质量的音视频协议交互。它没有P2P能力，全部通过云中转，具有高联动性。

同样它的技术结构决定了它的成本较高，音视频主要使用成本有两方面：一是带宽；二是存储，存储是需要录制时进行存储。因为它的技术比较复杂，技术成本相对而言门槛比较高。XP2P是腾讯内部P2P能力的提炼，主要是基于标准的STOM以及自研的TERUN（音）服务，它这个方案是完全基于P2P的，技术方案决定了它的使用成本最低，因为它只要打洞成功了就可以使用用户的流量。云直播CSS技术方案是传统的直播类领域，比如说斗鱼、虎牙这种直播平台。

基于这三种方案都形成了落地的场景。P2P场景主要用IoT可靠信道作为信令传输。摄像头和播放端时不时通过MQTT信令将自己探测到的信息传输到MT服务端，需要进行交互通信的时候，通过MQTT或者MT服务端获取到对端的信息进行打洞，如果打洞失败通过IOT协议端协商最近的中继节点进行交互通信。微信团队深度合作，首次实现了小程序上对P2P直播流的播放。目前打洞成功率可以达到80%，延时在200-300毫秒左右，接近实时音视频技术。

再分享一下传统的枪机类摄像头，大部分可以分为两类，一部分是支持国标GB28181协议的，一部分是自有协议的。怎么接入云直播的能力？开发了一款自研的芯片服务，对于支持国标协议的摄像头，直接接入到芯片服务上去。对于完全自有协议的摄像头，结合边缘网关的形式适配协议，边缘网关进行抽象变成国标协议的节点，或者直接通过标准流推到让音视频媒体服务。用户观看的时候通过控制台、接口调用、信令服务器下发指令到IPTP设备，设备将流推到音视频服务器里，推流大部分是基于国标的RTP推流。音视频服务对流进行了兼容处理，对接上云直播服务，能够提出标准化的出流，RTSP、RTMP、小程序、H5播放、FLC等等。

同时，基于云上的资源快速存储，能够大大降低存储使用费用。以前用户要么使用边缘的硬件存储，硬件本身都是非常昂贵的。

通过这种方式可以使得传统行业的监控类摄像头有大量的应用场景，如AI算法枪一般使用RTSP进行数据音视频的AI算法，并且可以在小程序、APP上进行观看。如前段时间武汉方舱的直播观看，最多时达几十万甚至上百万人观看直播，使用的就是类似的基础方案。控制界面提供了丰富控制应用能力，电视墙大屏管理、云端录制，小程序则是播放的能力。

综上所述，结合不同场景分享腾讯云在服务的可靠性、安全性方面怎么样保证基础服务的质量，怎么样在边界接入、可用性方面降低开发者使用的接入门槛，最后再结合音视频的场景向大家分享IoT和音视频的场景落地。