我开始研究面向服务的体系结构，并想知道如何最好地构建进程之间的消息传递。似乎服务和/或pubsub总线之间的直接HTTP调用是两种常见的方法。在哪种情况下比另一种更有利？我可以看到pubsub如何导致更多的解耦服务，但我也觉得跟踪消息通过系统的路径变得更加困难。
有哪些资源可以了解更多相关信息？在非常小的“手动”服务（即Ruby / Sinatra，Node / Express，Redis pubsub等）的背景下，我对此非常好奇，而不是任何规定的SOA堆栈/套件。虽然我确信同样的原则适用。
谢谢！
答案 0 :(得分：15)
我会给你两分钱。
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架构，但是因为你有很好的合同，你可以通过向它们添加异步功能来扩展你的服务，为此你首先要添加一个消息队列每项服务。你知道，你不需要从一个复杂的系统开始，从一个基本的，定义良好的东西开始，这允许你在必要时进行扩展。
如果您愿意，我所描述的系统可以扩展为轻松支持事件，并且您此时已经同步消息的事实也不会阻止您将asyn消息添加到系统中。
但这些只是我的两分钱。