web-services - 微服务架构中的消息传递

Question

关闭。这个问题需要更多 focused .它目前不接受答案。












想改进这个问题？更新问题，使其仅关注一个问题 editing this post .

6年前关闭。




Improve this question




我开始研究面向服务的架构，想知道如何最好地构建进程之间的消息传递。服务和/或 pubsub 总线之间的直接 HTTP 调用似乎是两种常见的方法。在什么样的情况下，一种比另一种更有利？我可以看到 pubsub 如何导致更多的解耦服务，但我也得到这样的印象，即通过系统跟踪消息的路径变得更加困难。

有哪些资源可用于了解更多相关信息？在非常小的“手动”服务(即 Ruby/Sinatra、Node/Express、Redis pubsub 等)的上下文中，我对此特别好奇，而不是任何规定的 SOA 堆栈/套件。 ..虽然我确信同样的原则也适用。

谢谢!

Answer 1

我给你两分钱。
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 作为通信协议(protocol)。

我知道你想开始应用一些最好的企业架构概念，但我想说你最好从更简单但更强大的基础开始。在不知道您是否真的需要它的情况下跳到事件 soa 是没有意义的。如果我正在启动一个新系统并想确保我正确地适应了 DDD 和 SOA 原则，我将从确定我的领域的服务开始。所以假设你有 3 个服务，你可以从为每个服务声明公共(public)契约(Contract)开始，你不需要任何特别的东西，你可以从带有同步 REST API 的 WCF/ASP.NET Web API 开始。然后，您将确保每个服务都有自己的数据库，因为您的目标是低耦合，然后您可以使用 WCF/ASP.NET Web API 再次创建一个 API 层(对外界可见的层)，因为你的微服务不应该直接暴露给外界。因此，此时您将拥有类似 SOA，但设计和架构简单，但由于您将拥有明确定义的合约，您可以通过向它们添加异步功能来很好地扩展您的服务，为此您将首先添加一个消息队列到每个服务。你知道，你不需要从一个复杂的系统开始，从一些基本的、定义明确的东西开始，如果你需要的话，它可以让你扩展。

如果您愿意，我描述的系统可以轻松扩展以支持事件，并且此时您已经同步消息这一事实也不会阻止您将异步消息添加到系统中。

但这些只是我的两分钱。