当你迷茫的时候，请点击 物联网目录大纲 快速查看前面的技术文章，相信你总能找到前行的方向
前言
Internet of Things (IoT) 就是物联网，万物互联。
是不是很抽象？听名字就可以劝退很多人了。但我们是勤劳勇敢的技术人，是劝不退的打工人。
所以我想用一个故事，来聊聊物联网技术的实现过程，原来物联网可以这么有趣。
抛出问题
我是一个净化器（后面统称为设备），主人出门在外，在公司上班，留我独守空房。
突然有一天，主人想我了，想问我过的好不好。
世界上最遥远的距离不是天涯海角，而是她只有一部手机，可是我不能接打电话。
但是，没有我的日子，手机显得多么苍白无力。
聪明的朋友们，你们有什么方法能够让我与主人进行通信吗？
接下来让我们一起来讨论一下实现的方案吧。
现有条件
知己知彼，方能百战不殆。
- 手机可以上网，蓝牙，安装各种手机app（这不是废话嘛）
- 我（净化器）能连接 wifi，蓝牙
- 我不能接打电话，不能安装app，所以想给我装微信的朋友们可以退下了（我大概是个废物…）
- 我有 mcu，支持简单的程序运行，我还有很多的传感器，采集各种参数给mcu处理
- 我是个工作狂人，只要电给够，一天到晚不休息，活到老，干到老（妥妥的打工人）
- 还有其他无关紧要的，比如我的颜值…(闭嘴啦)
初步设想
想实现手机与设备的互相通信，那需要找到两者有什么共同点，就想两个人处对象，总得找点共同话题。
从上面的条件可以看出，设备和手机都有 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 数据）
注：
- 手机只能
http 请求bypass服务端，收到http响应数据并作页面更新 bypass服务端和 模拟设备 都是mqtt 客户端，都是通过mqtt 协议向 mqtt服务端发布和订阅消息
bypass 服务和mqtt服务部署在云服务器上，这就是我们常说的云。
后话
本文我们用故事的形式，讲解物联网的由来，设计思路和实现。
真实的场景也是大致如此，只是再加上更多业务处理逻辑，消息参数的具体封装等等细枝末节的实现。但是这些都不是今天要关注的，我们只要掌握了主体，有了主体思路，实现不过举手之劳而已，无非是些精细活。
阅读源代码也是如此，打蛇打七寸，读文章要抓主旨，看代码要抓主架构，这样才不会在茫茫的代码海里迷路。
下期我们会从代码的角度上再讲讲一些具体的实现，配网，MQTT相关的知识，内容会越来越硬核哦，尽请期待吧！