architecture - 在微服务中，我应该使用 pub/sub 而不是 RPC 来获得更松散耦合的架构吗？

Question

我当前使用通过 TCP 对另一个微服务进行 RPC 调用并获取响应，但我认为我可以通过这种方式做到这一点:

如果不进行 RPC 调用，我可以使用 pub/sub 发送到一个服务，发布一些 channel (如 request_user)并订阅 channel (如 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(一个用于请求，另一个用于响应)？

Answer 1

事实上这个问题没有人可以回答。这取决于:-)

一方面，使用 RPC，您可以在服务之间建立更紧密的关系，但从另一方面来说，您可以拥有更简单的请求/响应通信模型。因此，发送请求的一个服务期望来自另一个服务的某种响应，或者如果无法访问则超时。 RPC与TCP也有 session 和双向通信方式。

使用发布/订阅模型，一个服务会发送一些有关某些已发生事件的消息，并且不关心其他服务将如何处理该消息。或者服务向一项特定服务发送消息，但不期望得到该服务的响应(单向请求)。当然，第二个服务也可以向第一个服务发送消息，传递一些工作结果。

松散耦合本身并不是目标 - 它是一种使系统更加可靠、稳定、可扩展的方法，但它会带来一些价格、工作开销，在某些情况下这是不可能的或根本没有必要。

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