物联网的架构

目录

物联网的整体结构

整体架构

网关

服务器结构

数据采集

网关的作用

接收数据

数据接收服务器的作用

HTTP协议

WebSocket

MQTT

数据格式

处理数据

处理服务器的作用

流处理

存储数据

数据库的作用

数据库的种类和特性

设备控制

发送服务器的作用

使用 HTTP 发送数据

使用 WebSocket 发送数据

使用 MQTT 发送数

物联网的整体结构

物联网服务大体上发挥着两个作用。

第一是把从设备收到的数据保存到数据库，并对采集的数据进行分析。

第二是向设备发送指令和信息。

整体架构

物联网大体上有 3 个构成要素。一个是设备，另一个是网关，再来就是服务器。

 

网关

网关指的是能连接多台设备，并具备直接连接到互联网的功能的机器和软件，网关主要作用是把不能直接连接到互联网的设备转发到互联网。多数情况下网关凭借 Linux 操作系统来运行。

接口：分为有线接口与无线接口，接口决定了能连接的设备。

有线连接方式包括串行通信和 USB 连接。串行通信中经常用的是一种叫作 D-SUB 9 针（pin）的连接器，而 USB 连接中用到的 USB 连接器则种类繁多。

无线连接中用的接口是蓝牙和 Wi-Fi（IEEE 802.11）。此外，还有采用 920 MHz 频段的 Zigbee 标准，以及各制造商们的专属协议。

网络接口：以太网或是 Wi-Fi、3G/LTE 来连接外部网络，影响到网关的设置场所。

以太网采用有线连接，通信环境稳定。然而正因为采用的是有线连接，所以必须把 LAN 电缆布线到网关的设置场所。

3G/LTE 连接设置场所就比较自由了，但通信的质量会受信号强弱影响，所以通信不如有线连接稳定。想使用 3G/LTE 时，需要和电信运营商签订协议并获取 SIM 卡，和使用手机一样。

硬件：需要确定让网关做哪些事情，也需要考虑到它的硬件性能。

软件：主要使用 Linux 操作系统来运行网关，网关上搭载的 Linux是面向嵌入式的。有一个叫作 BusyBox 的软件，它运行起来占用内存少，集成了标准的 Linux 命令工具。它用于在硬件资源匮乏的时候运行网关。除此之外，还要考虑是否有用于控制网关功能的程序库，以及与这种程序库对应的语言等。

电源：网关基本上都是使用 AC 适配器当电源的，因此需要事先在设置网关的场所准备好电源。如果网关本身搭载有电池，那么就不需要准备电源了，不过需要进行充电等维护工作。

服务器结构

物联网服务大体上可分为 3 个部分，可以分别称它们为前端部分、处理部分，以及数据库部分。

 

前端部分包括数据接收服务器和数据发送服务器。数据接收服务器接收设备和网关发来的数据，转交给后续的处理部分。数据发送服务器则刚好相反，它负责把从处理服务器接收到的内容发送给设备。

处理部分负责处理从前端部分接收到的数据。这里的“处理”指的是分解数据、存储数据、分析数据、生成发给设备的通知内容，等等。

数据库不只会用到关系数据库，还会用到 NoSQL 数据库。

数据采集

网关的作用

网关是一台用于把不能直接连接到互联网的设备转发连接到互联网的设备。再往细了说，网关是由 3 种功能构成的。

这 3 种功能分别是连接设备功能、数据处理功能和向服务器发送数据的功能。此外，实际使用网关执行应用时，还需要其他的管理应用功能。

 

连接设备：设备和网关是通过各种各样的接口连接的。当通过传感器终端连接时，多数情况下是传感器单方面持续向服务器发送数据。根据设备不同，也存在设备申请从外部获取数据时，服务器向设备发送数据的情况，这时就需要通过网关申请数据。

生成要发送的数据：把从设备接收到的数据转化成能发送给服务器的格式。

还存在下面这种情况：不把每台设备发来的数据直接发送给服务器，而是将大量数据整合在一起再发送给服务器。这么做有以下两个原因。第一，通过整合数据能减少数据的附加信息，减少数据量。第二，通过一并发送数据能减轻访问物联网服务时对服务器造成的负担。

 发送数据给服务器：向物联网服务发送数据。此时，需要根据服务器来决定发送数据的时间间隔和发送数据的协议。

接收数据

数据接收服务器的作用

数据接收服务器负责接收从设备发送来的数据。它在设备和系统之间起着桥梁作用。其中具有代表性的包括以下两种方法。

准备一个使用了 HTTP 协议的 Web API 来访问设备（如通常的 Web 系统）

执行语音和视频的实时通信（如 WebSocket 和 WebRTC）

除此之外，还有一种名为 MQTT 的、专门针对物联网的新型通信协议。

HTTP协议

HTTP 协议提供的是最大众化且最简易的方法。使用一般的 Web 框架就可以制作数据接收服务器。设备用HTTP 的 GET 方法和 POST 方法访问服务器，把数据存入请求参数和 BODY 并发送。

 

在 Web 服务的世界里，有一种思路叫作 RESTful。REST 是一种接口，它为特定的 URL 指定参数并执行访问，作为其响应来获取结果。它通过用多个 HTTP 方法访问一个 URL，来对一个 URL 执行获取和注册数据。

WebSocket

WebSocket 是一种通信协议，用于在互联网上实现套接字通信。它实现了 Web 浏览器和 Web 服务器间的数据双向连续传输。

就 HTTP 协议而言，每次发送数据都必须生成发送数据用的通信路径及连接。此外，一般情况下，客户端没有发出申请就不能进行通信。

WebSocket 就不同了。只要一开始根据客户端发出的连接申请确立了连接，就能持续用同一个连接传输数据。另外，只要确立了连接，就算客户端没有发出申请，服务器也能给客户端发送数据。

 

这样一来，在发送语音数据等连续的数据，以及发生与服务器的相互交换时，就能使用 WebSocket 了。WebSocket 自身只提供服务器与客户端的数据交换，因此需要使用者另外决定在应用层上使用的协议。

MQTT

MQTT（MQ Telemetry Transport，消息队列遥测传输）是一种能实现一对多通信（人们称之为发布或订阅型）的协议。它由 3 种功能构成，分别是中介（broker）、发布者（publisher）和订阅者（subscriber）

 

中介承担着转发 MQTT 通信的服务器的作用。相对而言，发布者和订阅者则起着客户端的作用。发布者是负责发送消息的客户端，而订阅者是负责接收消息的客户端。MQTT 交换的消息都附带“主题”地址，各个客户端把这个“主题”视为收信地址，对其执行传输消息的操作。形象地比喻一下，中介就是接收邮件的邮箱。

MQTT 通信的机制：首先，中介在等待各个客户端对其进行连接。订阅者连接中介，把自己想订阅的主题名称告诉中介。这就叫作订阅。然后发布者连接中介，以主题为收信地址发送消息。这就是发布。发布者一发布主题，中介就会把消息传递给订阅了该主题的订阅者。

订阅者和中介总是处于连接状态，而发布者则只需在发布时建立连接，不过要在短期内数次发布时，就需要保持连接状态了。因为中介起着转发消息的作用，所以各个客户端彼此之间没有必要知道对方的 IP 地址等网络上的收信地址。又因为多个客户端可以订阅同一个主题，所以发布者和订阅者是一对多的关系。在设备和服务器的通信

中，设备相当于发布者，服务器则相当于订阅者。

主题采用的是分层结构。用“#”和“+”这样的符号能指定多个主题。

借助于中介的发布 / 订阅型通信，MQTT 就能实现物联网服务与多台设备之间的通信。另外，MQTT还实现了轻量型协议。因此它还能在网络带宽低、可靠性低的环境下运行；又因为消息小、协议机制简单，所以在硬件资源（设备、CPU 和内存等）受限的条件下也能运行，可以说是为物联网量身定做的协议。

QoS

QoS 是 Quality of Service（服务质量）的简称。这个词在网络领域表示的是通信线路的品质保证。MQTT里存在 3 个等级的 QoS。“发布者和中介之间”以及“中介和订阅者之间”都分别定义了不同的 QoS 等级，以异步的方式运行。此外，当“中介与订阅者之间”指定的 QoS 小于“发布者和中介之间”交换的 QoS 时，“中介与订阅者之间”的 QoS 会被降级到指定的 QoS。QoS 0 指的是最多发送一次消息（at most once），发送要遵循 TCP/IP 通信的“尽力服务” 。消息分两种情况，即到达了一次中介处，或没有到达中介处。

 

QoS 1 是至少发送一次消息（at least once）

 

中介一接收到消息就会向发布者发送一个叫作“PUBACK 消息”的响应，除此之外还会根据订阅者指定的QoS 发送消息。当发生故障，或经过一定时间后仍没能确认 PUBACK 消息时，发布者会重新发送消息。如果中介接收了发布者发来的消息却没有返回 PUBACK，那么中介会重复收到消息。

QoS 2，它指的是准确发送一次消息（exactly once）。把它跟 QoS 1 合在一起使用，就能避免接收到重复的消息。用 QoS 2 发送的消息里面含有消息 ID。中介收到消息后会将消息保存，然后给发布者发送 PUBREC 消息。发布者再给中介发送 PUBREL 消息，然后中介会给发布者发送 PUBCOMP 消息。接下来中介才会依据订阅者指定的 QoS，向订阅者传递接收到的消息。

就 QoS 2 而言，有时使用的中介会影响消息的传递时间。人们通常使用的是 QoS 0，只有要确保信息发送成功时才使用 QoS 1 和 QoS 2，这样一来可以减少网络的负担。

Retain

订阅者只能接收在订阅之后发布的消息，但如果发布者事先发布了带有 Retain 标志的消息，那么订阅者就能在订阅后马上收到消息。

当发布者发布了带有 Retain 标志的消息时，中介会把消息传递给订阅了主题的订阅者，同时保存带有Retain 标志的最新的消息。此时，若别的订阅者订阅了主题，就能马上收到带有 Retain 标志的新消息。

 

Will

Will 有“遗言”的意思。由于中介的 I/O 错误或网络故障等情况，发布者可能会突然从中介断开，Will 就是专门针对于这种情况的一个机构，它用于定义中介向订阅者发送的消息。

发布者在连接中介时会用到 CONNECT（连接）消息，连接时对其指定 Will 标志、要发送的消息以及QoS。这样一来，如果连接意外断开，Will 消息就会被传递给订阅者。另外，还有一个标志叫作 Will

Retain。通过指定这个标志，就能跟前面说的 Retain 达到同样的效果，即在中介处保存消息。

当发布者使用 DISCONNECT（断开连接）消息明确表明连接已断开时，Will 消息就不会被发送给订阅者。

 Clean session

Clean session 用于指定中介是否保留了订阅者的已订阅状态。用 CONNECT 消息连接时，订阅者把 Clean session 标志设定为 0 或 1。0 是保留 session，1 是不保留 session。

若指定 Clean session 为 0 且中介已经连接上了订阅者，则中介需要在订阅者断开连接后保留订阅的消息。另外，如果订阅者的连接已经断开，且发布者已经发布了 QoS 1、QoS 2 的消息给已订阅的主题时，中介则会把消息保存，等订阅者再次连接时发送给订阅者。

 

若指定 Clean session 为 1 并连接，中介就会废弃以往保留的客户端信息，将其当成一次“干净”的连接来看待。此外，订阅者断开连接时，中介也会废弃所有的信息。

数据格式

数据要经过协议进行交换，而数据的格式也很重要。通过 Web 协议来使用的数据格式中，具有代表性的包括 XML 和 JSON。

 

XML 的格式比 JSON 更容易理解。然而 XML 的字符数较多，数据量较大。相对而言，JSON 比 XML 字符数少，数据量也小。JSON 数据量小，更适合使用移动线路等低速线路通信的情况。

基于物联网服务处理这些格式时，要把文本数据转换成数值数据和二进制数据。因此需要进行两项工作，即解析 XML 和 JSON 格式，以及把解析结果从文本格式转换到二进制形式。

如果能直接以二进制形式接收数据，是不是就能更迅速地处理数据了呢？由此，一种数据格式应运而生，它就是 MessagePack。

 

MessagePack 的数据格式虽然跟 JSON 相似，其数据却保留了二进制的形式。因此，虽然这种数据格式不方便人们直接阅读，但计算机却能很容易地处理。又因为 MessagePack 发送的是二进制数据，所以比起以文本形式发送数据的 JSON，数据更加紧凑。MessagePack 跟 XML 和 JSON 一样，都提供了面向多种编程语言的库。

处理数据

处理服务器的作用

处理服务器就是处理接收到的数据的地方。“处理”是一个抽象的词语，例如保存数据，以及转换数据以使其看上去更易懂，还有从多台传感器的数据中发现新的数据，这些都是处理。使用者的目的不

同，处理服务器的内容也各异。不过说到数据的处理方法，它可以归纳成以下 4 种：数据分析、数据加工、数据保存以及向设备发出指令。

 

批处理 

批处理的方法是隔一段时间就分批处理一次积攒的数据。一般情况下是先把数据存入数据库里，隔一段时间就从数据库获取数据，执行处理。批处理的重点在于要在规定时间内处理所有数据。因此，数据的数量越多，执行处理的机器性能就得越好。

流处理

流处理是不保存数据，按照到达处理服务器的顺序对数据依次进行处理。

存储数据

数据库的作用

数据库的作用是保存并灵活运用数据。除此之外，其作用还包括从保存的数据中找出与所指定条件相符的数据。另外，数据库还能把多条数据连在一起，把它们作为一个数据取出。

 

数据库的种类和特性

关系数据库

关系数据库具备一种叫作表格的表格型数据结构，其用途在于存储数据库，使用者用 SQL 语言来对其执行数据的提取、插入以及删除。

键值存储

键值存储属于 NoSQL 数据库的一种。NoSQL 是一种不使用 SQL 的数据库的统称。键值存储，就是把一种叫作“值”（value）的数据值，和能够一对一特定“值”的“键”（key）的集合保存在一起。

文档型数据库

文档型数据库和键值存储一样，都属于 NoSQL 数据库的一种。文档型数据库能以 XML 和 JSON 这种结构化文档的格式保存数据。特别是近年来，有一种叫作 MongoDB 的文档型数据库很受欢迎，它以 JSON 的格式保存数据。

设备控制

发送服务器的作用

发送服务器的目的在于向设备发送数据并控制设备。运行方式有两种：一种是通过设备申请来发送数据的同步传输；另一种是由发送服务器在任意时间发送数据的异步传输。

使用 HTTP 发送数据

要实现数据发送，HTTP 是最简单的方法。在这个方法里，发送服务器是等待接收 HTTP 请求的 Web 服务器。设备向这台服务器申请发送数据，作为响应，服务器把数据发给设备。 

使用者需要定期从设备执行轮询连接。采用此方法的原因主要有以下两个。

 

原因一：无法确定唯一地址，例如无法给设备设定全局 IP 地址等。这种情况下，发送服务器就不知道应该把数据发送给哪台设备了。

原因二：考虑到设备频繁断电和移动线路的传输费用。此时，设备没有持续连接网络。即使设备已经连接过网络，但只要没有持续连接，那么，即使发送服务器执行了发送数据的操作，也发不到设备那里去。

使用 WebSocket 发送数据

使用 WebSocket 时，需要用设备连接发送服务器，并确立 WebSocket 连接。只要建立了一次 WebSocket 连接，就能实现从发送服务器和客户端发送数据。

使用 MQTT 发送数据

前文介绍了 HTTP 和 WebSocket，它们采用的方法都是由设备访问发送服务器。就这些方法而言，只要客户端没有发出申请，数据就不会被发送。当然使用者也可以在设备上建立 HTTP 和 WebSocket 协议，由服务器来连接设备。不过，一旦增加了设备，服务器想管理所有设备就相当困难了。针对这点，我们来试着看一下这种服务器：它灵活运用 MQTT，并且发挥了发布 / 订阅模型的优点。使用MQTT 时的发送服务器。

 

首先设备作为订阅者，向 MQTT 中介进行订阅。然后，发送服务器则是发布者，同样向中介进行发布。这样一来，发送服务器只需要把确定的数据加在主题上发送就行了，发送服务器和设备都不需要知道彼此的地址。只要知道中介的地址，就能够实现通信。一旦订阅者断开，中介就会负责在断开时发送通知，并在重新连接时再次发送数据。