0 背景
前面介绍过mqtt broker的一种开源解决方案-mosquitto[1]，本文将简单介绍一下商业化的解决方案-HiveMQ，目的是从商业化的视角看一下如何实现mqtt broker，有哪些可以借鉴和学习的思路，比如mqtt broker mesh组网是前面mosquitto中没有体现的，在商业应用中经常会遇到千万级的发布和订阅场景，此时就需要broker之间组网，进行负载均衡。还有一点值得学习的是，将这个看似简单的mqtt协议做到极致是一种怎样的体验。
1 HiveMQ关键特性
1）基础特性
HiveMQ本身主要是实现mqtt broker的角色，因此前面mosquitto有的特性在其中基本都已包含，同样支持3个版本的mqtt协议，如下图所示是HiveMQ的基础特性。在保证通信质量方面，除了协议中提出的三种qos机制，还对指令主题做了两种等级的保障。主题订阅方面，提供了共享订阅，通配符订阅等订阅方式，主题的订阅方式更加灵活和动态，支持批量的订阅方式，这对于实际的应用场景是非常有意义的，比如在物联网场景通常要控制大量的传感器，如果为每个传感器都设置一个订阅主题，这对broker来说会产生巨大的存储压力，通过批量的方式，就可以将存储压力降下来。
2）增值特性
HiveMQ broker为了应对千万级别的客户端接入云端的冲击，提出了boker的mesh组网方案，即通过类似云端服务器集群的方式，将broker集群到一起，如下图所示。当接入的客户端数量超负荷时，就可以启动过载保护，将原本在一个broker上的接入，搬移到其他的broker上，对客户端来说是不感知的，就像是访问一台broker一样。当监控到大量的订阅或者发布行为对某个broker的造成压力时，此时就可以将该处理消息搬移到其他的broker上，进行负载均衡。这种方式可以根据实际的接入和资源需求，对系统进行灵活的扩展或者裁剪，有效保障大容量场景的过载。
除了灵活扩展的优势外，通过broker组网，还可以冗余备份，增强系统的健壮性，当发生宕机时，可以快速切换到其他broker角色上，保障业务的连续性。为了保障安全性，还可以对客户事件进行历史记录，当有未经授权的访问或者攻击时，可以根据客户事件历史，寻找到攻击的源头，然后通过黑名单的方式杜绝。
为了使HiveMQ更好地支持商业化应用，该方案还对现有的云平台、商业级系统进行了兼容，比如云平台方面支持AWS、微软云等，商业级系统方面；支持经典的消息队列商业级产品-kafka系统，数据库方面支持sql等。所以一个协议要真正做到商业级应用的程度，需要考虑更多的因素，要针对具体的商业应用，在某个方面做的更深。
2 边缘计算场景实现mqtt broker
上述HiveMQ的解决方案是针对云计算+物联网终端设备的场景， 笔者根据上述的组网思路，针对边缘计算场景，提出了一种新的设计思路，如下图所示。此处将原本部署在云端的broker角色下沉到边缘网关设备上，这样从接入的视角上，就可以将原本千万级别的客户端接入，分散到各个边缘网关设备上，每个边缘网关设备接入的客户端数就可以大幅降低，有效地解决了大量接入的问题。
原本broker是部署在云端服务器上，通过下沉，broker来到了嵌入式设备上，针对嵌入式设备资源受限的问题，需要对broker做优化，支持可裁剪，做到更加轻量，这与在云端的部署的设计思路也截然不同，在云端广泛使用的消息队列如kafka，也要进行轻量级的卸载。边缘网关设备之间也不能是孤立的，需要组成类似的网络，即借鉴前面的broker mesh组网，在边缘网关设备之间也建立如此的网络，增强系统的健壮性，同样的需要监控大量接入和攻击，需要过载保护，负载均衡和备份恢复等功能。这也将是笔者后续的边缘计算项目实战中重要的一个特性和研究开发方向。
如下图所示，是mqtt broker在边缘计算场景应用的一个案例，该案例主要是实现遥测车联网场景下车载设备状态，进行预测性维护。此案例中mqtt承担着从车载设备传输数据到云端的角色，此处broker被下沉到边缘设备上，云端可以订阅想要得到的数据，客户端的车载设备可以定时发布数据到云端，为云端的大数据分析提供数据。通过mqtt协议可以保证在车辆高速移动，网络不稳定的场景下，持续不断地连接，部分数据可以就近在边缘设备上处理，降低时延，同时通过不同等级的qos保证可靠数据的传输，在安全性方面，发布订阅模式，可以是无地址的客户端通信，降低了攻击的风险。
3 小结
本文从商业化的HiveMQ出发，探讨了一些值得学习和借鉴的思路，并将其应用到笔者的边缘计算项目设计中。提出了在边缘计算设备上的组网方式和一个应用案例，希望对读者有所启发，在自己的项目实战中多去学习和借鉴优秀的项目，启发更多的创新点。
参考文献：
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
