我们正在考虑使用面向服务的架构 (SOA) 来拆分我们的架构（并添加新组件）。第三方将使用许多外部 API，我们将使用 REST HTTP 接口进行制作，但是我想知道在内部使用什么是最好的，因为所有组件都在我们的控制范围内并且将在相同的网络，但可能有不同的技术（主要是 .net 和 ruby on rails）。
使用消息系统（redis、rabbitmq、EMS、我没听说过的其他值得注意的例外......）而不是 HTTP（REST、SOAP 等）会不会有很大的性能/功能增益。
我一直在努力寻找关于这个主题的好信息，而且（你可能会说）我对这个领域相当陌生，所以任何建议或好的资源都将不胜感激！
纳克斯
消息传递倾向于为您提供更松散耦合的架构。它也可能更健壮，因为单个组件可能会在不杀死整个基础架构的情况下发生故障。
缺点是复杂性、向异步模型的范式转变以及可能的性能（特别是如果您在每个地方都持久化消息）。
您还需要确保您的消息传递系统特别健壮。您的逻辑的一个方面可以在不影响所有内容的情况下关闭并重新启动，但是如果您丢失了核心消息库，那么您的所有逻辑都将关闭，等待消息备份。
幸运的是，消息总线可以长时间运行而无需人为摆弄和触摸，这是任何系统中最大的错误和不稳定来源。
除了@Will Hartung 提到的内容之外，我还要说这取决于您要对系统执行的操作。如果您主要拥有客户端-服务器类型的应用程序，而您的服务器/服务很少并且它们往往是完全独立的，那么通过 HTTP 上的 REST 实现服务合同可能会更容易。
另一方面，如果您的整个系统正在进行双向通信，或者如果有许多进程间调用（特别是如果系统中的每个参与者在某个时候既是客户端又是服务器），那么消息传递是你最好的选择。在消息传递选项中，我发现 AMQP/RabbitMQ 是所有这些选项中功能最丰富且易于使用的。它为您提供了一个真正的异步平台来编写代码。
使用消息传递的主要好处是您可以为每种类型的消息设置队列，因此当您的系统扩展和更改时，队列/消息可以相同，但处理它们的服务可以在下面发生变化。它促进层的分离。
最后，在我看来，这是一件大事，正确使用消息传递可以促进小的、独立的代码片段。这些都更具可测试性和可维护性，并且通常可以简化您的企业架构。如果您尝试处理来自 HTTP 端点的太多服务，您最终（在一两年的过程中）最终会遇到（1）太多端点无法跟踪或（2）无法维护的意大利面条代码.
我的公司开始使用基于消息的框架，它对我们来说效果很好。RabbitMQ 服务器很容易成为最可靠的组件。如果您对消息传递或 SOA 有任何其他问题，请随时询问。