rabbitmq - 什么时候在微服务架构中不使用诸如 RabbitMQ 之类的消息代理？

Question

我是 RabbitMQ 等消息代理概念的新手，想学习一些最佳实践。
RabbitMQ 似乎是促进微服务之间异步通信的好方法，但是，我有一个初学者问题，我在其他任何地方都找不到答案。
什么时候去不是 在微服务架构中使用诸如 RabbitMQ 之类的消息代理？
举个例子:
假设我有两项服务。服务一个 与服务 乙 (授权服务)
客户端向服务发出请求 一个 反过来，它必须与服务通信 乙 (身份验证服务)对用户进行身份验证并授权请求。 (使用基本身份验证)

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

在我有限的理解中，我可以预见在上述场景中使用 AMQP 的问题是服务 一个 能够处理请求并在可接受的时间范围内向客户端发送响应，因为它必须等待服务 B 消费并响应消息。
本质上，让 Service 是个坏主意吗？一个 等待来自服务的响应 乙 通过 AMQP？
还是我完全错过了 AMQP 的重点？

Answer 1

好吧，实际上您所描述的内容大多接近于 HTTP。
HTTP 是同步的，这意味着您必须等待响应。如您所言，此问题的解决方案是 AMQP。使用 AMQP，您不一定需要等待(您可以对其进行配置)。
这不一定是一个坏主意，但大多数微服务所依赖的是一种称为最终一致性的东西。由于这将是一个很长的答案，有很多如果我建议查看 Microservices Architecture
例如 here是关于 http 与 amqp 的部分，因为它主要是关于同步与异步通信的问题
它详细介绍了微服务设计的不同方法，列出了针对您的特定问题和其他问题的利弊。
例如，在您的情况下，身份验证将发生在 API 网关，因为它不被认为是为所有客户端应用程序打开微服务的最佳实践。