http - 面向服务的架构 - 传输层(http 与消息传递)

Question

我们正在考虑使用面向服务的架构 (SOA) 拆分我们的架构(并添加新组件)。第三方将使用许多外部 API，我们将使用 REST HTTP 接口(interface)，但是我想知道什么最好在内部使用，因为所有组件都在我们的控制之下，并且将在相同的网络，但技术可能不同(主要是 .net 和 ruby​​ on rails)。

使用消息传递系统(redis、rabbitmq、EMS，其他我没听说过的值得注意的异常...)而不是 HTTP(REST、SOAP 等)是否会有很大的性能/功能提升？

我一直在努力寻找有关此主题的有用信息，并且(正如您可能会说的那样)我对这个方面还很陌生，所以任何建议或好的资源都将不胜感激!

谢谢

Answer 1

消息传递往往会为您提供更松散耦合的架构。它也可能更健壮，因为单个组件可能会在不破坏整个基础架构的情况下发生故障。

缺点是复杂性、范式转变为异步模型，以及可能的性能(尤其是当您在任何地方都持久化消息时)。

您还需要确保您的消息传递系统特别健壮。您的逻辑的一个方面可以关闭并重新启动而不会影响所有内容，但如果您失去了核心消息库，那么您的所有逻辑都将关闭，等待消息备份。

幸运的是，消息总线可以长时间运行而无需人为摆弄和触摸它，这是任何系统中错误和不稳定的最大来源。