消息总线和消息队列有什么区别？

谈论消息总线和消息队列之间的区别，以及将消息队列封装到企业应用程序的消息总线中的必要性.

消息总线和消息队列之间有什么区别？如果有人问您这个问题，您的答案是什么？如果您的消息总线基于相当成熟的消息队列或消息系统，用于辅助打包. 为什么需要使用客户而不是原始客户（这是每个人都相信权威的时代，请注意，这里是要相信而不是迷信，您真的应该相信权威，至少要依靠新手来依靠Spectrum ，当然，我在这里指的权威是肯定的）？

然后，我将从以下几点谈谈我对这个问题的看法:

消息队列的clientAPI权限太大，并且clientAPI信任级别太高

消息队列clientAPI面向技术，消息总线clientAPI面向技术+业务

消息队列无法隐藏通信详细信息

消息队列的实时控制无法实现

公交车的优势: 统一入口，简化拦截成本

为便于理解，您首先将RabbitMQ视为消息队列. 实际上消息队列接口，它不只是消息队列. 还可以建立其他一些基于JMS的消息队列来回答这个问题.

（1）消息队列clientAPI权限太高，信任级别太高

这不仅是哪个服务器组件的客户端驱动程序的实现，它们中的大多数都是这样，它们的客户端实际上是服务器组件（或服务器）协议的翻译. 这些服务器大多数具有命令行界面（这几乎是标准的）. 实际上，CLI和程序中使用的各种语言的客户端库之间没有本质区别. 它们都是相对于服务器的客户端-它们是服务器实现的协议的转换或转换，这些API都是关于这些的. 调用打包协议. 因此，它们都具有某种“管理”形式的接口: 例如创建，删除，删除组件等. 没错，您可以查看所有具有客户端的组件的实现，它们都包含这些API（这不是对与错的问题，这些客户端本身没有并且不应假设您的使用情况）. 例如，如果您查看redis的客户端: jedis-它甚至具有flushAll和flushDB（清除所有redis数据）的功能，除了关闭服务器外，它还能做什么？就RabbitMQ而言，其官方Java客户端可以创建/删除其通信的核心组件: 交换，队列. 您能否将这些客户直接分发到各种业务系统而不会受到阻碍？您当然需要进行二次打包才能删除这些高风险管理API.

（2）消息队列clientAPI面向技术，消息总线clientAPI面向技术+业务

消息队列的大多数客户端API都是面向协议，面向通信，面向可用性和高性能的. 如果将它们分类为面向技术，则除了通讯方案外，它们不会模拟业务方案. 消息总线需要带来业务场景以实现需要支持的机制.

搜索任何消息队列时，它都有一个优点: 生产者和使用者是分离的，就像这样:

就生产者和消费者模型而言，这确实是消息队列的优势. 但是，此优点也仅限于某些特定的使用场景，例如: 单个服务消息的排队和处理. 因此，一般的消息队列方案更适合于单责任生产者和消费者模型. 但是我们期望的消息总线是企业中各个系统中消息的通信，重点是通信. 消息队列仅提供了一种非常适合消息通信的实现机制（消息排序，消息缓存等），因此消息总线是一种适合于消息队列提供的技术支持上的消息交互的业务场景.

（3）消息队列无法隐藏通信详细信息

对于企业内部的系统交互，我们希望它将尽可能确保数据的安全性. 数据通常是临时存储在队列中的，因此数据的安全性自然会发生变化消息队列接口，以确保消息队列访问的安全性: 您绝对不应允许未经授权的客户端访问不应访问的内容. 队列. 遗憾的是，RabbitMQ官方客户端无法满足此要求. 要访问队列，它需要知道真实队列的名称及其路由路径. 在连接队列方面，我们认为它提供了太多信息，但这是无法完成的，因为它的交换和队列mashup机制非常灵活，因此您必须提供一个称为rouTIngkey的路由路径. 无论如何，如果您向调用者打开此信息以进行填写，则几乎可以肯定地它将公开您服务器的交换和队列路由机制以及拓扑. 那么，我们需要做什么？我们需要找到一种通信机制，使其只需要知道有一个代理节点，而不必注意真实队列的名称；然后想办法在消息总线中隐藏其路由密钥.

（4）消息队列无法实时实现

如果在企业中的系统之间引入消息总线，则很明显必须提供访问控制. 例如，对队列执行消息大小限制，对队列进行激活/停用等.

我们在前面提到，消息队列不是面向业务的，并且它没有过多考虑数据的安全性和访问的安全控制机制. 除非消息队列基于/插件模型，否则我们几乎很难转换它的服务器实现. 尽管RabbitMQ支持插件，但对于erlang而言，它并不是一种特别广泛的语言. 如果您为它编写插件，那么如果您不小心遇到了麻烦，RabbitMQ官员已经宣布，不​​建议您自己使用它们. 编写插件. 考虑到许多不便之处，我们只能在客户上发表文章. 毫无疑问，我们的实时控制信息仍然必须存储在服务器上（但它是一台独立的服务器），但是本机客户端显然不支持此机制，因此我们需要将实时订阅封装在服务器之外. 用于管理信息和访问控制的本机客户端逻辑代码.

（5）公交车的优势: 统一入口，简化了拦截费用

无论是消息总线还是服务总线，所谓的总线都是先收集然后分散的过程. 首先聚集，从统一入口进入，完成必要的统一处理逻辑；然后发散，并根据路由规则路由到每个组件进行处理. 实际上，这就是代理的作用: 屏蔽内部细节并统一外部入口. 在代理的基础上，我们可以在消息总线上记录所有消息（因为所有消息通信都必须通过代理），并且仍然可以基于不切断RabbitMQ自己的Channel的情况，以及是否要实现路由A代理基本上与树形拓扑结构密不可分.

写在最后

本文主要讨论消息总线和消息队列之间的区别. 实际上，市场上已经有一些成熟的消息队列可以直接使用. 如果为消息队列封装消息总线，则某些人会认为这是必要的. 如果您没有这些开源消息队列，则必须自己实现消息总线，仍然需要实现类似于市场的MQ或MessageBroker（请参阅POSA第4卷），因此消息队列只是以下方面的基础实现消息总线. 或其消息通讯方式；并选择基于一些成熟的MessageBroker进行开发，不仅可以节省很多工作，还可以享受他们提供的稳定性和社区贡献.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-256467-1.html