一、MQTT协议介绍

1.MQTT协议

MQTT（消息队列遥测传输）是基于TCP/IP协议栈而构建的支持在各方之间异步通信的消息协议。MQTT在空间和时间上将消息发送者与接收者分离，因此可以在不可靠的网络环境中进行扩展。虽然叫做消息队列遥测传输，但它与消息队列毫无关系，而是使用了发布和订阅(Pub/Sub)的模型。

MQTT是一种轻量级的、灵活的网络协议，致力于为IoT开发人员实现适当的平衡：

这个轻量级协议可在严重受限的设备硬件和高延迟/带宽有限的网络上实现。它的灵活性使得为IoT设备和服务的多样化应用场景提供支持成为可能。

2.MQTTClient库

MQTTClient库在很多语言中都有实现，包括EmbeddedC、C、Java、JavaScript、Python、C++、C#、Go、iOS、Android等。

3.MQTT报文

固定报头Fixedheader

控制报文类型:

控制报文类型标志位:

剩余长度:

可变报头Variableheader

某些MQTT控制报文包含一个可变报头部分。它在固定报头和负载之间。可变报头的内容根据报文类型的不同而不同。可变报头的报文标识符（PacketIdentifier）字段存在于在多个类型的报文里。

报文标识符字节PacketIdentifierbytes:

有效载荷Payload

以下MQTT控制报文在报文的最后部分包含一个有效载荷。对于PUBLISH来说有效载荷就是业务消息。

二、CoAP协议详解

CoAP是受限制的应用协议(ConstrainedApplicationProtocol)的缩写。在IoT物联网场景，为了让小设备可以接入互联网，CoAP协议被设计出来。CoAP是一种应用层协议，它运行于UDP协议之上而不是像HTTP那样运行于TCP之上。CoAP协议非常小巧，最小的数据包仅为4字节。

CoAP是一种面向网络的协议，采用了与HTTP类似的特征，核心内容为资源抽象、REST式交互以及可扩展的头选项等。为了克服HTTP对于受限环境的劣势，CoAP既考虑到数据报长度的最优化，又考虑到提供可靠通信。一方面，CoAP提供URI，REST式的方法如GET，POST，PUT和DELETE，以及可以独立定义的头选项提供的可扩展性。另一方面，CoAP基于轻量级的UDP协议，并且允许IP多播。为了弥补UDP传输的不可靠性，CoAP定义了带有重传机制的事务处理机制。并且提供资源发现机制，并带有资

源描述。

协议特点：

基于消息模型

请求/响应模型

双向通信

轻量、低功耗

支持可靠传输

支持IP多播

非长连接通信，支持受限设备

支持观察模式

支持异步通信

协议内容：

CoAP是一个完整的二进制应用层协议，消息格式紧凑，默认运行在UDP上。

CoAP报文：

【Ver】版本编号。

【T】报文类型，CoAP协议定了4种不同形式的报文，CON报文，NON报文，ACK报文和RST报文。

【TKL】CoAP标识符长度。CoAP协议中具有两种功能相似的标识符，一种MessageID(报文编号)，一种为Token(标识符)。其中每个报文均包含消息编号，但是标识符对于报文来说是非必须的。

【Code】功能码/响应码。Code在CoAP请求报文和响应报文中具有不同的表现形式，Code占一个字节，它被分成了两部分，前3位一部分，后5位一部分，为了方便描述它被写成了c.dd结构。其中0.XX表示CoAP请求的某种方法，而2.XX、4.XX或5.XX则表示CoAP响应的某种具体表现。

【MessageID】报文编号。

【Token】标识符具体内容，通过TKL指定Token长度。

【Option】报文选项，通过报文选项可设定CoAP主机，CoAPURI，CoAP请求参数和负载媒体类型等等。

【11111111B】CoAP报文和具体负载之间的分隔符。

请求方法：

0.01GET：获取资源

0.02POST：创建资源

0.03PUT：更新资源

0.04DELETE：删除资源

响应码：

Success2.xx

这一类型的状态码，代表请求已成功被服务器接收、理解、并接受。

2.01Created

2.02Deleted

2.03Valid

2.04Changed

2.05Content

ClientError4.xx：

这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。

4.00BadRequest

4.01Unauthorized

4.02BadOption

4.03Forbidden

4.04NotFound

4.05MethodNotAllowed

4.06NotAcceptable

4.12PreconditionFailed

4.13RequestEntityTooLarge

4.15UnsupportedContent-Format

ServerError5.xx：

这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器的软硬件资源无法完成对请求的处理。

5.00InternalServerError

5.01NotImplemented

5.02BadGateway

5.03ServiceUnavailable

媒体类型：

工作模式：

CoAP参考了很多HTTP的设计思路，同时也根据受限资源限制设备的具体情况改良了诸多的设计细节，增加了很多实用的功能。

CON：需要被确认的请求，如果CON请求被发送，那么对方必须做出响应。

NON：不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应。

ACK：应答消息，接受到CON消息的响应。

RST：复位消息，当接收者接收到的消息包含一个错误，接收者解析消息或者不再关心发送者发送的内容，那么复位消息将会被发送。

请求/响应模型：

1.携带模式

2.分离模式

3.非确认模式

CoAP协议的URI：

在HTTP的世界中，正式RESTFul协议由于其简单性和适用性，在WEB应用中越来越受欢迎，这样的道理同样适用于CoAP。一个CoAP资源可以被一个URI所描述，例如一个设备可以测量温度，那么这个温度传感器的URI被描述为：CoAP://machine.add ress:5683/sensors/temperature。

CoAP的默认UDP端口号为5683

HTTP和CoAP对比：

HTTP代表超文本传输协议，CoAP代表约束应用协议；

HTTP协议的传输层采用了TCP，CoAP协议的传输层使用UDP；

CoAP协议是HTTP协议的简化版；

CoAP协议和HTTP协议一样使用请求/响应模型，拥有相同的方法；

CoAP开销更低，并支持多播；

CoAP专为资源构成应用而设计，如：IoT/WSN/M2M等...

CoAP和MQTT对比：

MQTT协议使用发布/订阅模型，CoAP协议使用请求/响应模型；

MQTT是长连接，CoAP协议是无连接；

MQTT通过中间代理传递消息的多对多协议，CoAP协议是Server和Client之间消息传递的单对单协议；

MQTT不支持带有类型或者其它帮助Clients理解的标签消息，CoAP内置内容协商和发现支持，允许设备彼此窥测以找到交换数据的方式。

三、IoT消息洪峰怎么扛

传统的消息队列(Kafka、RocketMQ等)经过多年打磨，在高性能、海量堆积、消息可靠性等诸多方面都已经做得非常极致，但在IoT物联网场景中，往往需要面临着海量的消息传递，传统的消息队列表现的“力不从心”。

IoT场景中，从应用服务器到嵌入式芯片，都需要传递事件消息，比如共享充电宝的开柜子、开灯指令从服务器发到设备、工业网关高频消息流等，在这些信息传递的过程中，队列最大意义在于让整个消息在不可控的环境中平稳运行，因为IoT设备时不时会由于故障或网络抖动会导致大量消息洪峰。

一、IoT队列和普通队列的差异点

1.上下行隔离拆分

在IoT场景中，我们把需要队列分为两个场景，一个是上行队列，一个是下行队列。拆分之后，可以隔离上下行链路，控制一个设备，比如支付成功要下发打开柜子等，上行出任何问题，千万不能影响到下行业务。另外，上下行两条链路的特点差异非常大。设备上行消息，并发量非常高，但很多场景下对于可靠性和时延要求低，而设备下行消息，并发量则比较低，但下行消息（一般是控制设备指令）要求到达成功率很高。

2.支持设备级的海量topic

传统队列的核心诉求是，不论堆积多少不影响它的性能。kafka的topic一多，原本消息顺序写文件优势就会导致一个broker要退化到随机写，失去优势，另外要zookeeper 来协调这么多topic也是有局限，所以这些队列本身有提供一个外挂代理桥接器对外入口是多个设备topic，再桥接映射到少量的实际kafkatopic，这方案有一定可行性，但做不到隔离效果，治标不治本。

通过，图1和图2对比较明显，一个队列拥塞尽量减少对其它设备影响。我们需要的是“海量topic尽量相互隔离，并且不影响整体性能”，尽量做到设备A的消息堆积topic，不影响设备B。

3.实时生成消息优先发送

先举一个例子，一个快递柜业务的队列堆积，然后“此时此刻”在柜子旁边的用户死命的在旁边用手机点开柜子怎么也打不开（此时后端系统都恢复了），问题就是队列里面还有几十万条的消息，新来的消息需要排队,等着之前的那些消息消费完，甭管这些消息还有没有用。因此，实时生成消息优先发送，堆积的消息进入降级模式。

二、IoT消息队列诞生

1.IoT队列的设计思路

设计目标是为了打造一个支持上下行隔离、实时优先、及海量topic的队列网关，设计

原则如下：

完全follow开源生态、和传统队列互补兼容。

保序降级，实时优先，堆积退化；仅实时消息相对有序。

海量topic，多租户隔离。

连接、计算、存储分离。

2.消息模式

图片只是个片段，从这个模式可以看出来机制差别，大家都没有错，只是出发点不同。

3.连接、计算、存储分离

broker不做连接，连接网关代理，broker只做流转分发，无状态+水平扩展；存储交给nosqlDB，高吞吐写。

4.消息策略-推拉结合

这个应该是队列的核心难点之一，和传统队列区分在于，我们考虑为平台化模式，独享资源过于昂贵。但带来问题是消费端不可控，所以使用结合模式，只有在消费者在线时会拉取堆积消息，而拉取是由AMQP队列网关来做，给到用户接口始终是推送过去的onMessage回调。

broker不是直接让consumer来连接，而是把队列网关剥离出来，这样会更灵活，

甚至对于部分用户我们的queue可以切换到ons、kafka等实现。kafka、rocketmq 做法是在连接时会分配给客户端一个broker接入地址。broker实时消息优先推送给consumer，失败才会落到queue；这是一个完整事件，如果没有完成则不给producercommit。异步ACK。

5.线性扩展-离线消息部分

实时部分消息采用推方式，基本上不会成为瓶颈，消费不过来消息进入堆积模式。由于底层依赖存储已经帮我们解决核心存储的扩展，剩下主要问题点在于如何消除写入热点和消费热点，这样broker可以完全做到无状态。

三、一个思考一一如何解决海量topic问题？

首先面对“大量”的问题一般都是考虑分区，单元化，分组等隔离和拆分，这里海量topic我们讨论针对一个单实例模式下如何尽可能做到更多topic，完全任意数量都能100%没问题肯定是不现实的。

由于broker和存储已经隔离，broker和topic已经没有什么关系，或者说任何topic 数据生成，broker做的事情就是写入和分发。

海量topic，每个topic有限数量订阅：topic和订阅者关系使用redis缓存或本地缓存，针对mqtttopic匹配有个topictree的树算法，hivemq有实现版本。单个topic海量订阅：这个场景其实是组播和广播，我们不会考虑在队列本身上面去做这个事情，而是在上层封装广播组件来协调任务和批量发送。

四、亿级IoT设备连接底层逻辑

物模型技术对于物联网企业来说是一项非常重要的技术，因为要实现万物互联，必须要有物模型体系沉淀，才能够让各种硬件实现智能化连接。

一、物模型三个关键问题：

1.为什么需要物模型？

海量的物联网数据、设备、业务，异构的设备和数据描述方式，难以理解，互通困难，首先，产业链内部自成体系，模组、芯片、平台、方案商角色多样，跨角色协作时，数据标准各异，协作困难；其次，采集数据解析困难，难以结构化，数据利用效率低，数据价值难挖掘；最后，随着行业应用和设备量增长，新增应用需要针对不同的设备协议重复开发，难以规模化。

2.物模型能解决那些行业问题？

目前物联网行业普遍存在着设备孤岛、软硬开发强耦合的问题，需要构建模型统一描述语言、面向物理实体的统一建模，物模型作为物的抽象层屏蔽了底层终端差异，标准化了设备的能力表达和交互方式，极大降低了物联网应用开发和快速复制的成本。

3.物模型带来什么价值？

低门槛接入：提供设备建模和交互协议基础能力。这是最基础的价值，所有设备上云都需要建模和交互协议。物模型和协议设计是否足够专业，这其实是绝大多数中小企业的门槛，他们刚开始意识不到，随意设计，随着规模和业务变化弊端就会体现出来。

标准化：物模型作为物联网的抽象层，类似操作系统屏蔽硬件、JVM屏蔽OS的差异性一样，通过标准化设备的能力表达和交互方式，解决了物联网严重碎片化情况下协议差异、软硬开发耦合、全链路验证流程长、设备孤岛、数据孤岛等问题。

生态化：软、硬件一旦基于物模型标准化开发和交互，围绕物联网的多角色，包括ISV，SI，IHV等在设备开发、生产、运维、售卖、集成、运行等环节相互之间能够解耦，提升了设备的流通性，促进生态化。

二、物模型面临哪些技术挑战？

以一个灯泡为例：

我们先来看一看一盏普通的智能灯会有哪些能力或特性，比如开关、色调、亮度、过温告警、恢复出厂设置等能力，其中包含有传感器采集的状态、有危险告警、也有控制器可执行的指令。那么不同行业场景设备复杂度、差异性都不一样，简单到消费类设备"灯"、复杂到工业类设备"锅炉"都需要可表达，定义一套足够抽象通用面向万物的物模型还是非常有挑战的，因此需要遵循一定的设计原则，比如简单、普适、可扩展、模块化、易用性。

延展开来说，物模型的技术挑战具体有这几项：

物模型由于描述所有异构设备完整能力，而且在设备全生命周期都发挥着作用，因此物模型设计过程中存在以下需要解决的难题：

普适性：物模型的定义和设计能够适应所有设备，需要可覆盖工业、生活、农业、交通多个不同行业。因此在设计上需要找到设备最本质的共性、抽象出一套模型。

超大点位和超复杂结构：尤其工业场景，通常需要对包含大量传感器（万级别）的传统自动化系统进行数字化，对物模型提出了非常大的挑战，物模型复杂度变成了和物理实体和环境复杂度成正相关，我们需要从中找到最本质的破解方法，避免物模型复杂度变得不可控。

国际化：设备可以在任何阶段售往全球各地，物模型能够让设备在各地具备多语言的能力。

可插拔：工业文明发展快很重要的一点在于标准化，大量复杂设备都可以标准化组装而成，比如汽车、轮船、家居等，模块可以根据产品特性进行动态插拔，因此物模型同样需要能够适应物理设备模块可插拔特性。

安全开发：物模型在设备开发阶段定义，在设备运行阶段被引用，需要保障开发阶段定

义或调试的物模型不影响生产阶段正在运行的设备。

快速调试：传统硬件开发和软件开发需要全链路一起配合调试，周期长成本高。有了物

模型，调试阶段需要确保软硬解耦，不相互依赖。

高可靠：线下化是物联网与互联网很大的差异点，大量线下的物理设备，地理位置和应

用场景及其广泛，设备出现问题现场运维成本非常高，而且对社会影响大，因此物模型

在设备运行阶段的可靠性要求非常高。

可回滚：为了保障高可靠，物模型在开发到运行过程中，一旦出现异常需要确保可快速

回滚。

可适配：由于行业里面已经有不少设备模型和交互协议，比如工业场景的Modbus，

opc等，生活场景的ble，zigbee等，当然还有大量三方平台私有协议，为了帮助这

些存量设备能够使用物模型，物模型需要具备模型和协议适配能力。

统一交互协议：设备除了需要可表达之外，还需要可访问，物模型不仅需要定义设备

能力描述规范，还需要定义设备被访问方式，所有设备都能够使用同一套交互协议进行

访问，设计上也存在着不小挑战，比如资源受限设备、弱网环境设备、工业边缘设备对

协议要求都会不一样，有些追求低功耗、有些追求少带宽、有些追求大点位高频、也有

追求网络多级级联等等。

孪生代理：物模型核心价值在于物理实体数字化，物理实体在云上数字化后会构建数字孪生体，数字孪生体的数据模型、访问方式均基于物模型，数字孪生体代理物理设备与行业应用进行交互，从而达到软件与硬件的解耦。然而孪生代理应该具备哪些特性以确保硬件能力都可以高效可靠地访问是非常有挑战的，比如设备断网或异常情况孪生代理如何与应用交互，是确保指令必达还是快速失败，可能不同场景诉求不一样。当然具备海量数据的孪生体如何基于数据智能化，反向指导物理设备生产运维，达到和物理设备共智的目标这是更大的挑战。

我们应该如何设计物模型呢？

早期大多数物联网平台比如Azure、AWS都只做连接和基础管理能力，并没有围绕数字化的设备建模和数字孪生能力，不过这两年几乎所有物联网平台都开始重视物模型和数字孪生的建设。

大多数对于设备建模都采用的是面向对象语言的思路，比如WoT、OPC、OMA、OCF、CWMP、AllJoin等，面向对象语言的抽象能力在计算机编程发展的几十年已经被证明，我们物模型定义也充分借鉴，却又因物联网而有所不同。

我们以面向对象语言java里面的class做类比，class用属性和方法描述对象的状态和行为；物模型也可以用属性和方法来描述物的状态和行为。同时结合设备特性，我们将物模型schema进行了一定的扩展，定义为属性、服务(方法)和事件三要素，事件是一类特殊的属性，比如空调的故障告警，这类属性严重性高，实时性强，一般需要监控并及时响应。为了对设备更精确的描述，物模型针对每种数据类型还定义了非常严谨的数据规范，比如在数据类型之外，还需要定义数据范围、精度、步长等规范。

【图为物模型基础schema（没有包括模块化、多语言、多版本等一系列高阶特性）】

解决了这些挑战后，物模型的技术架构就呈现出来了。

阿里云AIoT物模型除了通过属性、事件、服务三要素描述了物理实体能力之外，物模型还支持千级大点位、多语言、多版本、多模块、多级级联、协议适配、云边端一体化等能力，达到可以应对生活、城市、工业等不同场景定义诉求。当然为了应对上文提到的一系列技术挑战，我们还通过构建Alink协议、数字孪生搭建了一整套面向物理实体的数字化能力。

还有一点要注意，物模型和数据标准是不一样的。

物模型能够以同一套schema描述设备的能力，但由于物联网碎片化，大家对于设备能力的定义差异性非常大，同样一款空调，不同厂商定义的能力会不一样。相当于面向对象语言里面接口标准化了，但实现没有标准化。数据标准核心在于降低差异化。

数据标准是一批可用于组装物模型的标准化素材，物模型构建过程可以方便地从数据标准库中选择素材进行积木式搭建。

在传统领域碎片化严重的情况下，定义数据标准非常有挑战，通常只有深耕传统行业才能定义出来，因此我们更多的是引入这些行业领先者贡献数据标准，而不是自己制定。阿里云IoT数据标准的沉淀主要来自ICA标准联盟，ICA标准库包括基本资源、功能模块、物

模板三类素材：

资源:标准库中最原子的能力，有属性、事件、服务三种类型（三要素）；

功能模块:一组资源的集合。集合中的资源可以是标准库中已有资源的组装，也可以是在当前功能模块新增的资源；

物模板:一组功能模块和一组资源的集合。集合中的模块和资源可以是标准库中已有模块和资源的组装，也可以是在当前物模板新增的资源；

下图描述了物模型、数据标准之间的关系：

最终我们看下灯泡物模型示意图：

参考：
《物联网开发实战（上）》电子书免费下载_在线阅读_藏经阁-阿里云开发者社区 (aliyun.com)https://developer.aliyun.com/ebook/431?spm=a2c6h.20345107.ebook-index.22.4ca3afe6bN8UO7