何时不应在微服务架构中使用消息代理，例如RabbitMQ？

Question

何时不应在微服务架构中使用消息代理，例如RabbitMQ？

rabbitmqmicroservices

5

我对像RabbitMQ这样的消息代理的概念还比较陌生，想学习一些最佳实践。

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

在微服务架构中，什么情况下不需要使用诸如RabbitMQ之类的消息代理呢？

以一个例子为例：

假设我有两个服务。服务 A 和服务B（认证服务）

客户端向服务A 发出请求，服务 A 需要与服务B（认证服务）通信以对用户进行身份验证和授权请求。（使用基本认证）

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

在我有限的理解中，我能预见到在像上述场景中使用AMQP的问题是，服务A必须等待服务B处理和响应消息后才能处理请求并向客户端发送响应，这可能导致在可接受的时间范围内无法完成。

实际上，让服务A通过AMQP等待服务B的响应是否是个坏主意呢？

还是说我完全误解了AMQP的用途？

- ben goodenough

个人而言，我喜欢避免使用消息代理，因为它增加了复杂性（在我看来，不需要过多的流动部件）。我通常仅使用grpc进行同步的服务间通信。如果需要异步执行，则接收方服务将简单地创建一个数据库记录（将任务添加到内部队列）并立即返回响应，例如排队电子邮件等待发送。只有当每个微服务由自己的开发团队维护时，我才会使用消息代理。 - Dĵ ΝιΓΞΗΛψΚ

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- A_kat · Accepted Answer

实际上，您所描述的大部分内容都与HTTP密切相关。

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

这不一定是一个坏主意，但大多数微服务依赖于称为最终一致性的东西。由于这将是一个相当长的答案，有很多如果的话，我建议您查看微服务架构。

例如，这里是关于HTTP与AMQP的部分，因为这基本上是关于同步与异步通信的问题。它详细介绍了微服务设计的不同方法，列出了针对您特定问题和其他问题的利弊。

例如，在您的情况下，身份验证将在API网关处发生，因为不考虑将微服务开放给所有客户端应用程序不被认为是最佳实践。