应用场景分析：

实现 终端设备 （Android）与 手机 App（Android、IOS）双向通讯的能力。同时有一个服务端可以对这些设备进行监控。

这时我们需要一个MQTT的消息Broker来实现，本文主要是对眼花缭乱的MQTT Broker进行选型，并选择最合适的方案，并对选型方案进行实战验证。

选型的原则：免费、开放、不耦合开发商、功能完备为优先考虑。

1、选型
1.1 个人优秀作品

 名称：jmqtt

地址：

一票否决：无知名成功案例

是否使用：否  

1.2 消息中间件兼职

 名称：RabbitMQ

地址：

一票否决：部分实现MQTT协议

是否使用：否  

 名称：Kafka MQTT Proxy	

地址：

一票否决：无双向通讯能力，仅能从MQTT向Kafka消费数据

是否使用：否  

 名称：ActiveMQ/ActiveMQ Artemis

地址：

一票否决：部分实现MQTT协议

是否使用：否  

1.3 专业型

1.3.1 常用

 名称：Mosquitto

地址：

一票否决：无REST管理API；无内置集群策略

是否使用：否  

1.3.2 企业级

 名称：EMQ X	

地址：

一票否决：收费软件

是否使用：否  

 名称：HiveMQ

地址：	

一票否决：收费软件，社区办不提供集群功能

是否使用：否  

 名称：VerneMQ

地址：	

一票否决：

是否使用：是  

 名称：JoramMQ

地址：	

一票否决：收费软件

是否使用：否	  

1.4 云IoT服务

 名称： 阿里云 物联网	

地址：	

一票否决：收费；使用阿里云的Link SDK，可能会导致云IoT服务商锁定。	

是否使用：否  

1.5 边缘计算

 名称：KubeEdge

地址：	

一票否决：我们当前的方案采用设备直连云端，无Edge边缘计算节点

是否使用：否  

 名称：K3S

地址：	

一票否决：我们当前的方案采用设备直连云端，无Edge边缘计算节点

是否使用：否  

1.6 结论

从上面选型过程中，可得出最终结论：选型为 VerneMQ 。

VerneMQ是一个高性能、分布式的MQTT broker。它可实现在普通硬件上的水平和垂直扩展，支持大量并发的发布者和消费者，并且能维持低延迟和容错的功能。VerneMQ可作为IOT平台和智能设备可靠的消息枢纽。

1.6.1 成功案例

1.6.2 VerneMQ的功能

• QoS 0, QoS 1, QoS 2 消息级别支持
• 基于文件的认证和授权
• 基于数据PostgreSQL, MySQL , Redis & MongoDB的认证和授权
• Bridge 支持
• $SYSTree用来监控和报告
• TLS (SSL) 加密
• Websockets 支持
• 集群支持
• 日志支持 (Console, Files, Syslog)
• 报告导出到Graphite
• 报告导出到Prometheus
• 扩展插件架构
• 共享订阅
• 单客户端多个会话支持
• 会话负载均衡
• 消息负载调整
• 消息负载切断 (为了保护系统)
• 离线消息存储 (基于LevelDB)
• 队列可处理 FIFO 或 LIFO 风格的消息.
• PROXY v2 协议
• Lua插件脚本支持
• Webhooks
• HTTP管理API

2、快速开始

2.1 快速部署

• 下载安装 Docker Machine
• 编写 single.yml 文件

 version: '3'

services:
  vmq:
    image: vernemq/vernemq
    environment:
      - DOCKER_VERNEMQ_ACCEPT_EULA=yes
      - DOCKER_VERNEMQ_ALLOW_ANONYMOUS=on
    ports:
    - 1883:1883
    - 8080:8080
    - 8888:8888
    - 8883:8883  

• 启动vernemq

 docker-compose -f single.yml up -d  

2.2 客户端测试

• 下载安装 MQTTBox
• 添加MQTT Client，名称为 device1 ，username也为 device1 ，代表一个唯一的智能设备，注意MQTT broker地址为 localhost:1883 ：

• 再添加一个MQTT Cliet，名称为 App1 ，Username也为 App1 ，代表标识一个唯一手机应用：

• 此时MQTTBox上显示有两个在线的客户端：

2.3 场景模拟

2.3.1 设备向手机发送信息，手机监听信息

• 设计 Topic 名称： App/call/App1 ，第一个 App 表示设备类型， call 表示动作， App1 作为手机App的唯一标识；
• 在 device1 客户端页面，向 Topic : App/call/App1 发布消息，先不要点击 Publish ：

• 在 App1 客户端监听 App/call/App1 ，可以将 call 换成通配符 + ，这样便可监听各种类型的动作，将 App1 也换成通配符 + ，可以监听不同手机的事件，填好Topic后点击 Subscribe 。

• 此时我们在 device1 客户端界面点击 Publish 按钮，发布的内容为 {‘caller’:’device1′}
• 此时查看 App1 的订阅界面接收到的信息：

2.3.2 手机向设备发送信息，设备监听信息

• 设计 Topic 名称： device/open/device1 ，第一个 device 表示设备类型， open 表示动作， device1 作为设备的唯一标识；
• 在 App1 客户端页面，向 Topic : device/open/device1 发布消息，先不要点击 Publish ：

• 在 device1 客户端界面，监听 device/open/device1 ，可将 open 改为通配符 + ，可监听多个动作，填好后点击 Subscribe ；

• 此时我们在 App1 客户端界面点击 Publish 按钮，发布的内容为 {‘caller’:’App1′}
• 此时查看 device1 的订阅界面接收到的信息：

2.4 集群状态监控

访问vernemq集群状态界面：

2.5 集群健康监控

访问vernemq集群健康接口：

2.6 HTTP API管理

2.6.1 创建管理API key

 $ docker exec docker_vmq_1 vmq-admin api-key create  

docker_vmq_1 为容器名称，此处生成的key为：

 gkhQzMgMsWqxEFJcd8HfwqbQ5fAbeCKb  

2.6.2 设备状态

使用Postman访问

2.6.3 设备掉线主动通知

MQTT协议支持Last Will功能，设备离线会像Will Topic( device/dead/device1 )里发送消息：

我们只需要监听Will Topic： device/dead/+ 就知道哪台设备离线了。

3、MQTT各端客户端

3.1 后台

（可不用了解底层API）

（可与Android通用API）

3.1 设备

3.2 手机

3.2.1 Android

3.2.2 IOS

（1.6k）

（star：1k）

（star：452）

（start：228）