什么时候适合为系统实施“脊柱”？

Question

据我所知，某些软件系统实现了消息总线或“刺”。这种技术适用于哪些应用？为什么？

Answer 1

我从来没有听说过“脊柱”。但是，常见的架构是Enterprise Service Bus (ESB)。

通常，当您有许多不同的组件需要订阅从其他组件发送的消息时，您可以使用此方法。通常处于断开状态（火灾和忘记），但有时您需要回复。

ESB不是处理双向通信的高速方式。

Biztalk就是这样一个系统的一个例子。还有很多其他的，显然你可以编写自己的代码。

一个示例需求是订单管理和计费系统。假设客户下了订单。订单通知可以在公交车上发送。如果您有单独的计费和履行系统，那么总线可以将消息传播给每个人，而无需订购系统知道如何计费或甚至是谁将履行它。

Answer 2

这一切都取决于你的需要。

例如，如果您有一个客户端/服务器应用程序，并且您想要提供实时更新Pub / Sub语义。然后消息总线是理想的，因为您不想重新发明轮子。

如果您有需要排队等待运行的进程，您也可以使用消息总线进行此操作，因为您可以将所有项目转储到队列中，并且进程监听将选择它们并根据需要进行处理。

我们倾向于为交易系统使用消息总线，但它可以用于需要向多个客户端发送消息的任何事情。如果您只是一个客户端/服务器应用程序并且不需要所有客户端保持最新，那就有点矫枉过正了。

然而，这一切都取决于您的使用场景，所以很难说。查看消息总线提供的内容，并查看它是否在您的应用程序上下文中提供任何帮助。问你自己可以使用简单的服务提供相同的东西，你需要Pub / Sub模型，你需要保证消息传递，消息确认如何。您只是要求数据是为了只读还是完整的数据输入系统。是否涉及可以从消息总线等等受益的工作流程。

最重要的是研究这些系统提供的内容，看看它是否适合您。但也要考虑诸如数量，可用性，可维护性等问题。您可以找到基于简单场景的多种解决方案，这些解决方案可以部分地从这样的事情中受益，但对于小型项目可能会超级过度。