基于MQTT协议实现微服务架构事件总线

一、场景描述

昨天在博客《客户端订阅服务端事件的实现方法》中提出了利用websocket、服务端EventEmitter和客户端mitt实现客户端订阅服务端事件，大大简化了客户端对服务端数据实时响应的逻辑。上述方案适用于单服务节点的情形。

对于由服务集群支撑的微服务架构，websocket提供的点对点通信已无法满足前端订阅后端集群事件的需求，升级方案是使用基于消息总线的通信方式。

二、几种消息总线适用性比较

常用的消息总线包括Kafka、Redis和基于MQTT协议实现的EMQX。

Kafka和MQTT都是从发布/订阅系统演化而来，但发展侧重点不同。Kafka通过分布式架构提供了海量数据流的存储，并保证数据流顺序，它的设计目标是支持数据发布、订阅和存储。而MQTT用于网络中传输小型数据包，其设计目的是实现简单、可靠的设备间通信。

而Redis是从内存数据库系统演化而来，发布/订阅功能是把消息保存在内存中。与Kafka相比，其只能提供半持久化；与MQTT相比，其通信效率较低。

由于应用场景没有对消息持久化的需求，且考虑到产业大脑平台未来会接入工业互联网，使用MQTT协议来搭建事件总线更利于平台在工业互联网环境下的扩展。

三、MQTT简介

几年前，本人曾写过MQTT简介。本文摘抄其中重要概念。

（一）MQTT协议

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议），是基于“订阅/发布”模式的轻量级通信协议，该协议基于TCP/IP，能以极低的带宽为海量（百万级）跨域设备提供可靠的消息服务，因此在物联网、小型移动终端、边缘计算方面有广泛应用。
所谓可靠的消息传输，体现为可配置消息的服务质量（QoS），有三种服务质量可选：

• 至多一次：
  消息发布完全依赖底层TCP/IP网络。会发生消息丢失或重复。应用场景如环境传感器的数据采集，丢失一次记录无所谓，因为不久后还会有第二次发送。
• 至少一次：
  确保消息送达订阅者，但消息可能重复，适用于幂等性操作。
• 只有一次：
  最严格的消息服务质量，确保消息到达且仅到达一次订阅者。应用场景如计费系统等。

MQTT协议中存在三种身份：消息总线（Broker）、发布者（Publish）和订阅者（Subscribe），其中消息总线属于服务器，后两者都属于客户端。发布者和订阅者可以是各种物联网设备和小型终端，消息发布者可以同时也是消息订阅者，如下图所示。

MQTT传输的消息分为：主题（Topic）和负载（payload）两部分：

• Topic，可以理解为消息的类型，订阅者订阅（Subscribe）后，就会收到该主题的消息内容（payload）；
• payload，可以理解为消息的内容，是指订阅者具体要使用的内容。

订阅消息时，可以在订阅表达式中使用通配符筛选器对主题进行筛选，可同时订阅所匹配的多个主题。
MQTT协议中主要有以下5个方法：

• connect：客户端建立与服务器的连接
• disconnect：等待客户端完成工作后，端口与总线的会话
• subscribe：客户端向消息总线注册订阅主题
• unsubscribe：客户端等待消息总线取消所注册的订阅
• publish：客户端向消息总线发送某主题的消息

（二）开源消息总线EMQX

EMQX（Erlang/Enterprise/Elastic MQTT Broker），是基于Erlang语言开发的开源物联网MQTT消息总线。其是一款由前华为员工开发的开源软件，软件主页为https://www.emqx.io/。可根据操作系统类别选择不同版本下载安装，或通过docker部署。

软件安装后，通过 emqx start以后台方式启动。启动后将会开放两个端口：

• 18083端口为控制台端口，可通过浏览器访问该端口，首次登录的用户名和密码为admin和public。控制台提供了总线监控、用户权限管理、在线客户端订阅/发布等功能。
• 8083端口为通信端口，MQTT客户端可通过该端口与EMQX消息总线通信。

（三）MQTT.js客户端

MQTT.js是MQTT客户端Nodejs SDK，可在浏览器（ES模块）和Node.js环境（CommonJS模块）下使用，前者可通过MQTT over WebSocket使用，后者既可以通过MQTT over WebSocket使用，也可以直接使用MQTT。区别仅仅是连接参数的协议头不同。

1. 安装和帮助文件

$ pnpm i mqtt