当你迷茫的时候，请点击 物联网目录大纲 快速查看前面的技术文章，相信你总能找到前行的方向

前言

Internet of Things (IoT) 就是物联网，万物互联。

是不是很抽象？听名字就可以劝退很多人了。但我们是勤劳勇敢的技术人，是劝不退的打工人。

所以我想用一个故事，来聊聊物联网技术的实现过程，原来物联网可以这么有趣。

抛出问题

我是一个净化器（后面统称为设备），主人出门在外，在公司上班，留我独守空房。

突然有一天，主人想我了，想问我过的好不好。

世界上最遥远的距离不是天涯海角，而是她只有一部手机，可是我不能接打电话。

但是，没有我的日子，手机显得多么苍白无力。

聪明的朋友们，你们有什么方法能够让我与主人进行通信吗？

接下来让我们一起来讨论一下实现的方案吧。

现有条件

知己知彼，方能百战不殆。

1. 手机可以上网，蓝牙，安装各种手机app（这不是废话嘛）
2. 我（净化器）能连接 wifi，蓝牙
3. 我不能接打电话，不能安装app，所以想给我装微信的朋友们可以退下了（我大概是个废物…）
4. 我有 mcu，支持简单的程序运行，我还有很多的传感器，采集各种参数给mcu处理
5. 我是个工作狂人，只要电给够，一天到晚不休息，活到老，干到老（妥妥的打工人）
6. 还有其他无关紧要的，比如我的颜值…(闭嘴啦)

初步设想

想实现手机与设备的互相通信，那需要找到两者有什么共同点，就想两个人处对象，总得找点共同话题。

从上面的条件可以看出，设备和手机都有 wifi/蓝牙的功能。蓝牙只能短距离传输，而 wifi 可以不限距离，天南海北都可以聊。

wifi 就像是一条高速公路，连接着家和远方。让手机与设备有了联通的可能。

光有道路是不够的，主人就算对公路狮吼一声，我这边都是听不到的。因此，我们还需要运输的工具来传递信息，诸如以前的邮差，今天的快递，都是如此。

那来一起认识一下物联网中的最常见的两个运输工具吧，HTTP协议 与 MQTT协议。

HTTP 与 MQTT

这就像是两辆车，一个大货车；另一个快递小车/小电驴，能跑而且实用。

想具体了解两者的区别，请自行转入百度。贴心的我会给你个链接：

HTTP 与 MQTT 区别：https://docs.emqx.com/zh/emqx/latest/faq/concept.html

MQTT 协议介绍：https://www.51cto.com/article/670429.html

换你会怎么选？

小孩子才做选择，成年人当然全都要，但是用的地方不一样。

下面来说一下我们的设计吧。

起点：手机
终点：设备
目标：传输消息（你好吗？）

中间的服务端

一般我们手机都会装各种app，例如，微信，支付宝，我们通过 UI 页面点点点，买买买。实际上是通过 UI 交互触发一个个 http请求，例如：登录，查询，下单…… 手机作为一个 客户端，发送的请求发给 服务端处理复杂的业务逻辑，这也是最常见和经典的 C/S(client/server) 模式，实现前后端分离。

好东西当然要借鉴一下啦。我们在 wifi 这条公路中间设置一个服务端吧，就像是以前的驿站，今天的物流公司。给服务端取个好听点的名字，就叫 bypass服务端吧。

于是主人去了公司的楼下的快递柜投入了一封 信件，信件（http请求）很快通过 http快递货车，送到达了 深圳物流公司（bypass服务端），bypass服务端会处理一些复杂的业务逻辑，就像物流公司要负责分区分拣，送货上门。

手机 --http–> bypass服务端 --?–> 设备

太好了，我们完成了这条链路的第一步。接下来是实现物流公司要运送快递到家了，即实现 bypass服务端到 设备的消息传递。

聪明的你肯定很快就完成了上面的填空。本着全都要的原则，MQTT这辆快递小车也被征用了。

手机 --http–> bypass服务端 --mqtt–> 设备

基本思想是对的，设备因为大脑简单，消息越简单越好，因此我们最后是用 mqtt 协议把消息送到设备上。

但要注意的是，这个链路有个地方是错误的。正确的链路为：

手机 --http–> bypass服务端 --mqtt–> mqtt服务端 --mqtt–> 设备

bypass服务端 和 设备 都是 mqtt客户端，它们都能连接上 mqtt服务端（一般叫 broker），来发布/订阅消息。bypass服务端和设备都是客户端，不能mqtt直接通信的。

啊，又引入了一个 mqtt服务端，又是万恶的 C/S(client/server) 模式。

不过 mqtt服务端 功能比较单一，管理消息用的。类似菜鸟驿站，给到达的快递（消息）分类，存放，进出库。消息根据主题 topic 分类，例如：信件上写着陈红 收，陈绿 收，陈兰 收。那么 陈红，陈绿，陈兰就是topic，菜鸟驿站会把信件归类放置。

mqtt服务端 接受的请求有 发布，订阅。

我们给它来个角色扮演：

角色	饰演者	备注
http 协议	大货车	体积大，臃肿
bypass 服务	深圳物流公司	服务端
mqtt 协议	小车	体积小，轻量
mqtt 服务	菜鸟驿站	服务端

于是就成了这样子：

上面说到，bypass服务端 接收到了 http请求，处理相应业务逻辑，把原来的 请求再包装一下成 mqtt消息，发布给 mqtt服务端，设备 就会从 mqtt服务端 去订阅，最终收到了主人的消息，执行对应的操作。

说点人话就是：深圳物流公司把 信件用 小车运到了 菜鸟驿站，我关注了 菜鸟驿站，得到通知去取件，最后终于拿到了主人的 信件。

啊，原来是问我在家过得怎么样。

主人对我真的太好了，上班都在关心我，我真想给她生猴子……

完整的链路

别光顾着感动，还没有完呢，主人问你好不好，你还没回答啊。

你不回答你是算怎么回事？

你生气了吗？你挂了吗？还是你睡着了？

那现在链路要反过来了

起点：设备
终点：手机
目标：传输消息（我很好！生猴子）

那还不简单，喏，反过来吧：

手机 <–http response-- bypass服务端 <–mqtt-- mqtt服务端 <–mqtt-- 设备

我们来解读一下，

发布mqtt消息：设备写了一封 信件（mqtt消息），报告了当前的状态参数，骑上我心爱的小摩托(mqtt)，把信件用送到附近的菜鸟驿站（mqtt服务端），

订阅mqtt消息： 深圳物流站（bypass服务端）也关注了菜鸟驿站的动态，派出 快递小车(mqtt)拿到 信件（mqtt消息），封装成http响应返回到手机端，手机页面就刷新为设备最新的状态信息。

这样，从手机端发出请求，到接收到设备的状态信息，就完成了手机与设备的一次互动。

测试的虚拟设备实现

在测试过程中，有台虚拟设备是很有必要的，因为测试过程中不可避免地要进行各种场景的测试，如果用真实设备来测，一则需要成本，另外不一定能得到特定或极端的参数，因为会有现实条件的限制和影响。

而虚拟设备只是一个程序跑着，里面模拟出各种场景的mock参数显示即可，在处理不同的方法时同样实时改变mock参数，与真实的操作无异。

链路为：

手机 --http–> bypass服务端 --mqtt–> mqtt服务端 --mqtt–> 模拟设备（python 程序 + mock 数据）

注：

1. 手机只能 http 请求 bypass服务端，收到http响应数据并作页面更新
2. bypass服务端 和 模拟设备 都是mqtt 客户端，都是通过 mqtt 协议向 mqtt服务端发布和订阅消息

bypass 服务和mqtt服务部署在云服务器上，这就是我们常说的云。

后话

本文我们用故事的形式，讲解物联网的由来，设计思路和实现。

真实的场景也是大致如此，只是再加上更多业务处理逻辑，消息参数的具体封装等等细枝末节的实现。但是这些都不是今天要关注的，我们只要掌握了主体，有了主体思路，实现不过举手之劳而已，无非是些精细活。

阅读源代码也是如此，打蛇打七寸，读文章要抓主旨，看代码要抓主架构，这样才不会在茫茫的代码海里迷路。

下期我们会从代码的角度上再讲讲一些具体的实现，配网，MQTT相关的知识，内容会越来越硬核哦，尽请期待吧！