我开始研究面向服务的架构，想知道如何最好地构建进程之间的消息传递。服务和/或 pubsub 总线之间的直接 HTTP 调用似乎是两种常见的方法。在什么样的情况下，一种比另一种更有利？我可以看到 pubsub 如何导致更多的解耦服务，但我也得到这样的印象，即通过系统跟踪消息的路径变得更加困难。
有哪些资源可用于了解更多相关信息？在非常小的“手动”服务（即 Ruby/Sinatra、Node/Express、Redis pubsub 等）而不是任何规定的 SOA 堆栈/套件的上下文中，我对此特别好奇。 ..虽然我确信同样的原则也适用。
谢谢！
我给你两分钱。
but I also get the impression that it becomes much harder to track a message's path though the system.
你说得对，pubsub SOA 架构 AKA (SOA 2.0) 提供了大量的解耦，但你也付出了代价，因为这正是发生的事情，尽管像 splunk 这样的工具可以提供很多帮助。
seems that direct HTTP calls between services and/or a pubsub bus are two common approaches
实际上，如果您查看最常用的 .net 事件 soa 框架（NServiceBus、Mule 和 MassTransit），它们不使用 http 调用，但是您可以实现微服务架构并使用 http 作为通信协议。
我知道你想开始应用一些最好的企业架构概念，但我想说你最好从更简单但更强大的基础开始。在不知道您是否真的需要它的情况下跳到事件 soa 是没有意义的。如果我正在启动一个新系统并想确保我正确地适应 DDD 和 SOA 原则，我会首先确定我的域的服务。假设你有 3 个服务，你可以从为每个服务声明公共合同开始，你不需要任何特殊的东西，你可以从带有同步 REST API 的 WCF/ASP.NET Web API 开始。然后，您将确保每个服务都有自己的数据库，因为您的目标是低耦合，然后您可以使用 WCF/ASP.NET Web API 再次创建一个 API 层（对外界可见的层），因为你的微服务不应该直接暴露给外界。因此，此时您将拥有类似 SOA，但设计和架构简单，但是由于您将拥有明确定义的合约，您可以通过向它们添加异步功能来很好地扩展您的服务，为此您将首先添加一个消息队列到每个服务。你知道，你不需要从一个复杂的系统开始，从一些基本的、定义明确的东西开始，它允许你在必要时进行扩展。您可以通过向它们添加异步功能来扩展您的服务，为此您可以从向每个服务添加一个消息队列开始。你知道，你不需要从一个复杂的系统开始，从一些基本的、定义明确的东西开始，它允许你在必要时进行扩展。您可以通过向它们添加异步功能来扩展您的服务，为此您可以从向每个服务添加一个消息队列开始。你知道，你不需要从一个复杂的系统开始，从一些基本的、定义明确的东西开始，它允许你在必要时进行扩展。
如果您愿意，我描述的系统可以轻松扩展以支持事件，并且此时您已经同步消息这一事实也不会阻止您将异步消息添加到系统中。
但这些只是我的两分钱。