面向服务的架构 - 传输层（HTTP vs 消息传递）

Question

我们正在考虑使用面向服务的架构（SOA）来拆分我们的架构（并添加新组件）。将有许多外部API将由第三方使用，我们将使用REST HTTP接口进行制作，但我想知道在内部使用什么是最好的，因为所有组件都在我们的控制下，并且将在同一网络上，但可能使用不同的技术（主要是.NET和Ruby on Rails）。

使用消息系统（如Redis、RabbitMQ、EMS等）而不是HTTP（REST、SOAP等）是否会带来大的性能/功能提升？

我很难找到关于这个话题的好信息（正如你可能已经注意到的），所以任何建议或好资源将不胜感激！

谢谢。

- Ben

Answer 1

消息传递一般会提供更加松散的架构。它可能更为稳健，因为个别组件可以失败而不会破坏整个基础设施。

缺点是复杂性、向异步模型的范式转变，以及可能的性能问题（特别是如果你在每个地方都持久化消息）。

你还需要确保你的消息系统特别稳健。你的逻辑的一个单一方面可能会崩溃并重启，而不影响其他东西，但如果你失去了核心消息库，那么你所有的逻辑都将等待消息恢复。

幸运的是，消息总线可以长时间运行而无需人为干预和操作，这是任何系统中错误和不稳定性的最大来源。

- Will Hartung

Answer 2

除了@Will Hartung提到的内容，我还要说，这取决于您将如何使用系统。如果您主要使用客户端-服务器类型的应用程序，其中有少量服务器/服务并且它们往往是完全独立的，则通过REST over HTTP实现服务合同可能更容易。

另一方面，如果整个系统都在进行双向通信，或者存在许多进程间调用（特别是如果系统中的每个参与者在某些时候都将成为客户端和服务器），那么消息传递是最好的选择。在消息传递选项中，我发现AMQP / RabbitMQ是所有选项中功能最丰富且易于使用的。它为您提供了一个真正的异步平台来编码。

使用消息传递的关键好处是，您可以为每种类型的消息设置队列，因此随着系统的扩展和更改，队列/消息可以保持不变，但处理它们的服务可以在下面更改。它促进了分层。

最后，并且在我看来，正确使用消息传递会促进小而独立的代码片段。它们更易于测试和维护，并且总体上简化了企业架构。如果您尝试从HTTP端点处理过多的服务，您最终（在一两年的时间内）将拥有太多的端点需要跟踪，或者是难以维护的混乱代码。

我们公司开始使用基于消息的框架，并且对我们非常有效。 RabbitMQ服务器很容易成为最可靠的组件。如果您对消息传递或SOA有任何更多问题，请随时问我。

- theMayer