在smart-mqtt 的架构设计中，我们推崇通过事件总线来驱动各类功能服务。这样的设计思想不仅能够以一种简单的方式，将 MQTT 规范协议中罗列的各项要求完美的融合起来，还为该产品预留了灵活的扩展空间。smart-mqtt 开发者和应用人士，都可以采用模块化、插件化的方式不断的丰富 Broker 的能力。

一、设计初衷

有着一定系统研发经验的开发人员应该都有感触：随着时间的推移，系统的功能持续迭代、累加，最终会导致系统复杂度急剧上升而难以维护（如下图）。

smart-mqtt 作为一款开源项目，在起初就尤其重视产品的可持续健康发展。我们期望 smart-mqtt 能一直保持简洁，这种“简洁”并不代表通过限制功能迭代而损害用户的产品体验。而是在不断满足场景需求、解决用户痛点的过程中，不因功能丰富度的提升带来复杂度的递增。事件总结，是经过反复推敲和验证，被我们认为可以实现这一目标的一把利刃。

二、事件总线

2.1 事件类型

2.2 事件服务

创建Topic：TOPIC_CREATE

事件描述：
当 MQTT Client 发送给 Broker 的订阅请求（非通配符订阅），或者推送过去的 Publish 消息所关联的 Topic，在Broker 端是第一次出现的 Topic，Broker 会在完成一系列初始化操作后触发 TOPIC_CREATE 事件通知。
应用场景

1. 更新客户端以通配符方式（客户端订阅的Topic中包含#或者+）的订阅关系。

例如：MQTT客户端A订阅的 Topic 为：/test/#，当 Broker 第一次收到 Topic 为: /test/1的 Publish 消息时，会经由事件总线通知客户端A建立与/test/1的订阅关系，并消费其消息。而如果后续 Broker 第一次收到 Topic 为/test_ABC的消息时，依旧通过事件总线通知客户端A检查自身的订阅规则是否需要消费/test_ABC的消息，而由于订阅关系不匹配，客户端A会忽略此 Topic 的 **TOPIC_CREATE **事件。