消息在微服务架构中

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作为通信协议.

我知道你想开始应用一些最好的企业架构概念,但我会说你最好从更简单但更强大的基础开始.你跳到事件soa是没有意义的,不知道你是否真的需要它.如果我正在启动一个新系统,并希望确保我正确地适应DDD和SOA原则,那么我首先要确定我的域的服务.所以说你有3个服务,你可以从声明每个服务的公共合同开始,你不需要任何特殊的东西,你可以从带有同步REST API的WCF/ASP.NET Web API开始.然后,您将确保每个服务都有自己的数据库,因为您的目标是低耦合,然后您可以使用WCF/ASP.NET Web API再次创建API层(外部世界可见)因为你的微服务不应该直接暴露给外界.所以在这一点上你会有一个像设计一样简单的SOA架构,但是因为你有很好的合同,你可以通过向它们添加异步功能来扩展你的服务,为此你首先要添加一个消息队列每项服务.你知道,你不需要从一个复杂的系统开始,从一些基本的,定义良好的东西开始,这允许你在必要时进行扩展.

如果您愿意,我描述的系统可以扩展为容易支持事件,并且您此时已经同步消息的事实也不会阻止您将asyn消息添加到系统中.

但这些只是我的两分钱.