【发布时间】：2008-12-17 12:59:34
【问题描述】：
使用基于消息的系统的动机是什么？
我看到了很多关于 NServiceBus 和 Mass Transit 等服务总线的信息，我想知道底层方法的好处是什么。
【问题讨论】：
-
更简单的基于消息的应用程序？不太确定你到底在问什么。
-
我的措辞不好的问题，已经相应地改变了它
标签： language-agnostic messages servicebus
【发布时间】：2008-12-17 12:59:34
【问题描述】：
使用基于消息的系统有多种优势。
- 消息形成了应用程序之间定义明确的技术中立接口。
- 启用应用程序的松散耦合。
- 许多性能、调整和扩展选项：
- 在不同的硬件上部署请求者和服务进程
- 多个请求者共享一个服务器
- 多个请求者共享多个服务器
- 各种消息传递中间件独立于您的应用程序实现常见的消息传递模式。
- 请求/回复
- 一劳永逸的离线更新
- 发布/订阅
- 许多中间件产品处理消息转换（例如 SWIFT 到 SWIFTXML）。
- 许多中间件产品可以将一个大请求分解为几个较小的请求。
- 它们几乎都支持多个平台。
顺便说一下，该领域的两个市场领导者是 IBM 及其 Websphere MQ 和相关产品，以及 TIBCO 及其企业服务总线。
【讨论】：
基于消息的架构将消息的生产者和消费者在时间和空间上解耦。这有很多好处：
- 生产者和消费者可以在不同的机器上运行
- 生产者和消费者可以在不同的时间运行。
- 生产者和消费者可以在不同的硬件/软件平台上运行（他们只需要了解相同的消息协议）
- 协调多个生产者/消费者很容易（例如，对于需要多台机器的计算密集型作业，如 Dave Markle 所述）
- 服务暂时不可用时的稳定性更高（例如，在处理订单时，使用消息系统有助于避免“丢失”订单）
当您进行 RPC 式通信时（即在等待服务响应时阻塞），您将失去大部分这些好处
【讨论】：
一个用例是当您拥有一个可以处理给定项目的资源池以及需要以可扩展方式分发的工作列表时。
我曾经有一个项目，我必须将大型机与许多 3270 屏幕刮板（都很慢）进行集成。我一次最多可以在一个盒子上打开 10 个这样的进程。我有数千个帐户要进行屏幕抓取和更新，所以我将工作放在一个队列中，我的机器（我有大约 3 个）刚刚从消息队列 (MSMQ) 中提取工作项并进行屏幕抓取，就是这样。我可以轻松地启动一台新机器，或者在不中断工作流程的情况下停用旧机器，这很好。
【讨论】：
真正的好处在于解耦应用程序的各个部分。设置总线并添加应用程序后，您可以通过添加可以保证不会影响其他部分的新部分来轻松扩展您的应用程序。这是一种随着时间的推移不断向系统添加内容的好方法。
例如。我们有一个这样的系统，每个命令都是作为整个 GUI 的一部分实现的，如果我们想添加新功能或修改现有功能，我们只需编写一个新部分并将其添加到系统中。当它被调用时，它不依赖于其余部分。这意味着我们可以非常轻松地扩展我们的应用程序。此外，我们在网络上的节点之间传递了一条消息 - 当一台计算机中的某些内容发生更改时，会向所有其他计算机发送一条消息，以便他们可以更新自己。对于不同的事件，我们有一百条不同的消息，因此我们可以通过在其中添加一个对适当消息作出反应的新服务来扩展系统。
消息传递架构通常具有与 Web 服务相同的功能，您可以调用离散服务，可以轻松添加新服务。
不要认为消息传递架构需要花哨（而且昂贵！）的中间件产品，但 Windows 运行在消息传递架构上 - 每个传递到窗口的 WM_* 消息都是......嗯，一个消息，我认为展示了架构的最佳示例 - 系统的任何部分都不需要了解任何其他部分，您可以无限扩展它，因为您可以在任何对话框等上处理任意数量的控件等。
消息传递是一种极好的架构，虽然它可能比将应用程序紧密耦合在一起要慢，但这并不是现在不使用它的理由，尤其是如果您已经在使用脚本或 .net 应用程序。
【讨论】：
面向消息的系统通常适用于某些类型的集成问题。其他替代方案是使用共享数据存储（可能基于文件或数据库）供应用程序进行通信或通过 RPC 集成应用程序。
消息传递优于这些集成模式的优势在于，您不会将两个应用程序耦合到相同的数据存储架构，也不会将应用程序绑定到点对点 RPC 集成场景（应用程序越多，这种场景就越复杂）参与）。
还有异步通信（例如电子邮件与在线聊天）以及消息路由和转换可能性的好处。
【讨论】：
我帮助为使用 C# 和 Remoting 的系统开发了一个，客户端（服务或 GUI）可以发送包含一些自定义数据的完整消息，并且接收者会在下次连接时或立即接收它)。然后他们可以处理该消息（在负载平衡服务的情况下通过获取它的所有权）。它还用于在长时间运行的进程完成后更新 GUI。
消息传递系统本身具有处理每条消息的可配置管道，以下是我们开发的一些管道的一些示例：
- 存储（创建/保存消息到数据库）
- 路由（确定需要发送消息的位置）
- 安全性（如果允许客户端接收，则确定）
- 删除（确定是否需要从系统中删除消息，这意味着需要通知客户端并将消息从缓存中删除并在数据库中标记）。
- TakeOwnership（确保一次只有一个客户端可以修改消息的状态，因为只有拥有的消息可以更改）
因此，在回答您的问题时，消息系统是发送有关您何时不知道或不关心客户是谁的信息的绝妙方法。
【讨论】：
有一个主要问题，那就是可靠性。在分布式系统中，同步调用可能会失败，下游系统会过载。然后，所有下游系统都需要调整为来自上游的负载，这是不切实际的。消息系统可以处理峰值。更好的是除了消息系统之外还使用负载均衡器。虽然下游应用程序正在自动扩展（这可能需要几分钟），但消息传递系统可以负责可靠地存储峰值。此外，消息传递系统和可靠地执行 pub-sub。想象一下，如果有数以千计的交易即将发送给数百名交易者……使用 pub-sub 轻松完成。所以有效的词是可靠性。
【讨论】：
我建议看看这篇博文。它展示了端到端的工作流程，并解释了我们如何以编程方式集成消息传递平台。
【讨论】：
基于消息的系统可以为您业务的整个数字化方面奠定基础。如今，拥有无缝集成的数字解决方案对于收集、存储和分析数据至关重要，并且在涉及业务流程时，您的数据可以帮助您做出最明智的决策，这一点至关重要。本质上，基于消息的服务是一种 API（应用程序编程接口）形式，可以将请求以消息的形式从一个应用程序发送到另一个应用程序。使用基于消息的系统意味着您的所有数字解决方案都可以轻松连接，并且它们将相互可靠地通信。
请求可以发送到系统内的任何端点，一旦验证，它们可以同时通过多个路径发送。与一次只能使用一个路径的传统请求/响应模型相比，这大大加快了流程。借助 TIBCO 消息传递等服务，您可以跨多种 API 进行通信，支持移动和 IoT 设备，根据需要扩展消息传递服务，并简化应用程序开发和采用。当然，该平台还提供了一个安全的消息传递环境，因此您可以放心，您的数据只会在您自己的应用程序之间共享以用于您指定的目的。
【讨论】：