在此期间，基于RabbitMQ的消息总线已经实现，在实现过程中自己也必须不断思考、总结和修改。 从效率、性能、网络、吞吐量，到API的可用场景和模式，都需要考虑各种维度。 但是，有一件事可以做。 自己想做，走着，吃饭，坐公共汽车，想办法改善它。 而且，在实践过程中，思考和挖掘自己知识面上的空白也是一件快乐的事情。
由此，记录自己实现的过程和平时的想法。
这是第一篇文章。 首先，我们将讨论消息传递总线和消息队列之间的区别，以及在企业APP应用程序中将消息队列封装在消息传递总线中的必要性。
消息总线和消息队列有什么区别？ 如果有人问你这个问题，你的答案是什么？ 如果消息总线已经根据成熟的消息队列或消息系统进行了二次封装。 为什么需要用你的客户端而不是原始的？ (这是一个大家都相信权威的时代。 请注意，这里使用的是相信而不是迷信。 你确实应该相信权威。 至少比相信初学者更可靠。 当然，我在这里说的权威，是正面的意思。 ）
那么，从以下几个方面来考虑这个问题吧。
消息队列中的clientAPI权限太大，clientAPI信任级别太高
消息队列clientAPI面向技术，消息总线clientAPI面向技术业务
消息队列无法隐藏通信详细信息
消息队列无法实施实时限制
公交优势：统一入口，简化拦截成本
这里为了便于理解，首先请将RabbitMQ视为消息队列。 其实不仅仅是消息队列，其他基于JMS的消息队列也是为了回答这个问题而成立的。（1）消息队列clientAPI权限太大，信任级别太高这不仅实现了哪些服务端组件的客户端驱动程序，而且大多数情况下都是如此，客户端是服务端组件(或服务)协议其中许多服务都配备了命令行界面。 这几乎是标准装备。 事实上，CLI与程序中使用的每种语言的客户端库没有本质区别，它们都是服务器的客户端——，都是服务器实现的协议的翻译或转换，这些API是因此，存在“管理”格式的接口，例如create、delete或remove组件。 没错，你要去看所有带客户端的组件的实现。 它们包括这些API。 (这不是对错的问题。 没有这些客户端本身，也不应该假设你的使用场景。 例如，看看redis的client:jedis——。 甚至还具备闪存全部、闪存数据库的功能。 (清空所有redis数据。 除了可以关闭服务器之外，还有什么不能做的吗？ 另一方面，在RabbitMQ的情况下，该official native Java客户端能够创建/删除作为该通信的核心组件的exchange、queue。 是否可以在不阻止这些客户端的情况下直接分发到每个业务系统？ 当然，必须创建辅助软件包才能删除这些高危管理API。（2）消息队列clientAPI面向技术而消息总线clientAPI面向技术+业务消息队列中的clientAPI大多面向协议、通信实现、可用性和高性能，分类后面向技术，除通信场景外不模拟业务场景。 消息总线必须具有业务场景，实现需要支持的机制。
当可怕的世界搜索消息队列时，生产者和消费者可能会断开连接，如下所示：
对生产者和消费者模式来说，这无疑是消息队列的优势。 但是，这一优势也限制在某些使用场景中，如单业务消息队列处理。 因此，公共消息队列的场景适用于单个责任生产者和消费者模型。我们期望的消息总线是企业内部各系统中消息的通信，侧重点是通信。 由于消息队列仅提供消息通信的最佳实现机制(消息排序、消息缓存等)，所以消息收发总线将适合消息交换的业务场景封装在消息队列提供的技术支持中（3）消息队列无法隐藏通信细节
关于企业内的系统交流，我们希望尽可能确保数据的安全性。 由于数据通常临时存储在队列中，因此确保数据安全意味着确保对消息队列的访问安全。 请不要允许无权访问不应该访问的队列的客户端。 很遗憾，RabbitMQ官方客户端不能满足这个要求。 要访问队列，必须知道实际队列的名称和路由路径。 关于连接队列，我认为提供了很多信息，这是没有办法的。 exchange和queue的混合机制非常灵活，因此必须提供称为路由密钥的路由路径。 无论如何，向调用方开放并填写此信息几乎可以确保服务器端的exchange和queue路由机制和拓扑结构是公开的。 所以我们需要做什么？ 我们需要找到一种通信机制，只要知道它对外有代理节点，就不需要关注实际队列的名称； 然后，考虑如何将该路由密钥隐藏在消息总线内部。（4）消息队列无法实施实时管控在企业系统之间部署消息总线时，显然需要访问控制。 例如，对某个队列实施取消
息大小限制，激活/禁用某个队列等。之前我们提到过消息队列不是面向业务的，它自身没有过多得考虑数据的安全性以及对访问的安全控制机制。而且我们也几乎很难去改造一个消息队列的服务端实现，除非它是基于拦截器/插件模式的。即便RabbitMQ是支持插件的，但对于erlang这样一个受众不是特别广泛的语言，你去给它写插件一不小心就会走到坑里去，并且RabbitMQ官方也已经申明了它们十分不建议你自己去编写插件。考虑到诸多不便，我们只能在客户端上做文章。毫无疑问，我们的实时管控信息还是必须存储在服务端（只是它是一个独立的服务端），但原生的client很显然是不支持这种机制的，因此我们需要在原生client外部封装订阅实时管控信息以及实施访问控制的逻辑代码。
（5）总线的优势：统一入口，简化拦截成本 无论是消息总线还是服务总线，其实所谓的总线就是进行先收拢再发散的过程。先收拢，从统一的入口进去，完成必要的统一处理逻辑；再发散，按照路由规则，路由到各个组件去处理。事实上这就是代理的作用：屏蔽内部细节，对外统一入口。在基于代理的基础上，我们可以对消息总线上所有的消息做日志记录（因为所有消息的通信都必须经过代理），并且还是在不切断RabbitMQ自身Channel的基础上，而如果想在路由上实现一个Proxy，那基本上离不开一个树形拓扑结构。
写在最后
这篇主要谈了消息总线跟消息队列的区别。其实市面上已经有一些成熟的消息队列可以开箱即用，如果你针对消息队列来封装出一个消息总线，总有人会认为是否有这个必要性。如果没有这些开源的消息队列，那么完全有你自己来实现消息总线的话，你还是需要实现出一个跟市面上类似的MQ或者MessageBroker（见POSA卷4），因此消息队列只是实现消息总线的基础，或者是它的消息通信方式；而选择基于一些成熟的MessageBroker来进行开发，既能省去很多的工作量，又能享有它们提供的稳定性以及社区的贡献。
如果你现在就希望看到它的实现机制，可以移步到 github。