何时不在微服务架构中使用 RabbitMQ 等消息代理？

Question

我不熟悉 RabbitMQ 等消息传递代理的概念，想学习一些最佳实践。

RabbitMQ 似乎是促进微服务之间异步通信的好方法，但是，我有一个初学者问题，我无法在其他任何地方找到答案。

什么时候不会在微服务架构中使用 RabbitMQ 等消息代理？

举个例子：

假设我有两个服务。服务 A 和服务 B （授权服务）

客户端向服务 A 发出请求，该服务又必须与服务 B (auth service) 通信以验证用户身份并授权请求。 （使用基本身份验证）

           Internet                
Client ----------------> Service A +-------> Service B [Authenticate/Authorization]
         HTTP request            HTTP or AMQP??

在我有限的理解中，我可以预见在上述场景中使用 AMQP 的问题是服务 A 能够处理请求并向客户端发送响应可接受的时间范围，因为它必须等待服务 B 消费并响应消息。

本质上，让服务 A 通过 AMQP 等待服务 B 的响应是不是一个坏主意？

还是我完全错过了 AMQP 的要点？？

Answer 1

实际上，您所描述的内容大多接近 HTTP。

HTTP 是同步的，这意味着您必须等待响应。正如您提到的，此问题的解决方案是 AMQP。使用 AMQP，您不一定需要等待（您可以配置它）。

这不一定是一个坏主意，但大多数微服务所依赖的是一种称为最终一致性的东西。因为这将是一个很长的答案，有很多如果我建议看看Microservices Architecture

例如here 是关于 http 与 amqp 的部分，因为它主要是关于同步与异步通信的问题 它详细介绍了微服务设计的不同方法，列出了针对您的特定问题和其他问题的优缺点。

例如，在您的情况下，身份验证将发生在 API 网关，作为让微服务对所有客户端应用程序保持开放的最佳实践。