在微服务中,我应该使用pub/sub而不是RPC来获得更松散的耦合体系结构吗？

Question

我目前通过TCP使用RPC调用另一个微服务并获得响应,但我想我可以这样做:

如果没有进行RPC调用,我可以使用pub/sub发送到一个服务,发布一些通道(如request_user)并订阅一个通道(如 object_user_response),然后订阅此request_user的另一个服务,发布object_user_response.

像那样:

Service A <-- (sub)object_user_response <------  Redis
Service A --> (pub)request_user ------------->   Redis

Service B <-- (sub)request_user <--------------- Redis
Service B --> (pub) object_user_response ------> Redis

在接收到object_user_response时,服务A检查用户的id是否与该函数请求的相同.

我应该使用RPC或Pub/sub吗？在松耦合架构方面,将数据发送到微服务并从那里获得响应的最正确方法是使用RPC调用还是使用两个pub/sub,on用于请求而另一个用于响应？

Answer 1

实际上没有人回答这个问题.这取决于 :-)

使用RPC从一方面您就可以在服务之间建立更紧密的关系,但从另一方面,您可以获得更简单的请求/响应通信模型.因此,一个服务发送请求期望来自另一个服务的某种响应或者如果它不可访问则超时.RPC with TCP还具有会话和双向通信方式.

使用发布/订阅模型,一个服务发送一些关于某个发生事件的消息,并不关心该消息将如何由另一个服务处理.或者服务将消息发送到一个特定服务,并且不期望它的响应 - (单向请求).当然,第二服务可以向第一服务发送消息,也传递一些工作结果.

松散耦合本身并不是一个目标 - 它是一种如何使系统更可靠,稳定,可扩展的方式,但它带来了一些价格,工作开销,在某些情况下它是不可能的或根本不必要的.

因此,根据您的需要,您可以选择第一种或第二种方法.如果您不能简单地发送请求并忘记它或者没有意义,则使用RPC,无论如何您都需要响应.RPC更容易实现.发布/订阅适用于某种"繁重"的后台作业,如图像,视频,文件处理,发送电子邮件等,您发送请求的地方,它将在队列中处理.使用pub/sub,您可以更有效地利用资源.

Answer 2

取决于您的用例，实际上与“解耦”无关。如果来自生产服务的调用必须等待来自消费服务的响应，则应使用同步消息传递 (RPC)。当生产服务发送一条打算由另一个服务使用的消息并继续其合并方式而无需等待甚至不需要响应时，将使用异步通信形式（例如发布/订阅）。

在微服务世界中，当您可以避免使用异步形式的通信时，异步形式的通信是更可取的，因为阻塞线程和等待响应的成本很高。良好的架构将有助于解耦服务之间的运行时依赖关系，以便每个服务尽可能独立运行，而不直接依赖其他服务来完成分配的工作。