微服务之间的通信——请求数据

Question

我正在处理微服务之间的通信。

例如（虚构的例子，只是为了说明）：

• 微服务 A - 存储用户（getUser 等）
• 微服务 B - 存储订单（createOrder 等）

现在，如果我想从客户端应用添加新订单，我需要知道用户地址。所以请求会是这样的：

客户端 -> 微服务 B (createOrder for userId 5) -> 微服务 A (getUser with id 5)

微服务 B 将使用来自用户微服务的详细信息（地址）创建订单。

要解决的问题：如何有效地处理微服务 A 和微服务 B 之间的通信，因为我们必须等到响应返回？

选项：

• 使用 RestAPI，
• 使用 AMQP，如 RabbitMQ 并通过 RPC 处理此问题。 (https://www.rabbitmq.com/tutorials/tutorial-six-dotnet.html)

我不知道什么对性能更好。通过 RabbitMQ 或 RestAPI 调用更快吗？ 微服务架构的最佳解决方案是什么？

Answer 1

在您的情况下，使用直接 REST 调用应该没问题。

选项 1 使用 Rest API：

当您需要同步通信时。比如你的情况。这个选项很合适。

选项 2 使用 AMQP：

当您需要异步通信时。例如，当您的订单服务创建订单时，您可能希望通知产品服务以减少产品数量。或者您可能希望通知用户服务已成功下订单。

我强烈推荐看看http://microservices.io/patterns/index.html

Answer 2

在 REST API 和基于事件的设计或两者之间进行选择完全取决于您的服务的通信行为。

您所做的是根据您的要求选择REST API，您可以在其中看到服务之间的同步行为 并使用 基于事件的设计，您会发现服务需要 异步行为，两者结合也没有什么坏处。

理想情况下，对于进程间通信协议，最好使用消息传递，而对于客户端服务，REST API 最适合。 查看microservices.io中的沟通方式

基于 REST 的架构

• 优势

  1. 当您需要同步环境时，请求/响应非常简单且最适合。

  2. 系统更简单，因为没有中间代理

  3. 促进编排，即服务可以根据其他服务的响应采取行动。

• 缺点

  1. 服务需要发现服务实例的位置。

  2. 服务之间的一对一映射。

  3. Rest 使用 HTTP，它是建立在 TCP/IP 之上的通用协议，在使用它来传递消息时会增加大量开销。

事件驱动架构

• 优势

  1. 事件驱动的架构对 API 开发人员很有吸引力，因为它们在异步环境中运行良好。

  2. 松散耦合，因为它将服务解耦，因为在一次服务的事件中，多个服务可以根据应用程序要求采取行动。将任何新的消费者插入生产者都很容易。

  3. 提高了可用性，因为消息代理会缓冲消息，直到消费者能够处理它们。

• 缺点

  1. 消息代理的额外复杂性，必须具有高可用性
  2. 调试事件请求并不容易。

Answer 3

就我个人而言，我不喜欢为 RPC 使用消息代理。它增加了不必要的复杂性和开销。

如何在用户 Web 服务中托管长期存在的 RabbitMQ 消费者？如果你让它成为一些静态单例，在你的 web 服务中你如何处理扩展和并发？或者你让它成为一个独立的守护进程？现在您有两个用户应用程序而不是一个。如果您的用户消费者速度变慢，当它使用请求消息时，订单服务上下文可能已超时并发送另一条消息或放弃，会发生什么情况。

对于 RPC，我建议使用简单的 HTTP。

有一种涉及消息代理的模式可以避免同步网络调用的需要。该模式是让服务使用来自其他服务的事件并将该数据本地存储在自己的数据库中。然后，当 Orders 服务需要用户记录时，它可以从自己的数据库中访问它。

在您的情况下，您的“用户”应用不需要了解有关订单的任何信息，但您的“订单”应用需要了解有关用户的一些详细信息。因此，每次添加、修改、删除用户等时，用户服务都会发出一个事件（UserCreated、UserModified、UserRemoved）。 Orders 服务可以订阅这些事件并仅存储它需要的数据，例如用户地址。

好处是，在请求时，您的 Orders 服务对另一个服务的同步依赖减少了。测试服务更容易，因为您的请求时间依赖性更少。然而，也有一些缺点，例如用户记录更改发生与 Orders 应用程序接收之间存在一些延迟。需要考虑的事情。

更新 如果您确实使用 RabbitMQ for RPC，请记住使用消息 TTL 功能。如果客户端将超时，则将消息过期设置为该时间段。这将有助于避免消费者浪费工作，并避免队列在负载下备份。消息代理上的 RPC 的一个问题是，一旦队列填满，它可能会增加较长的延迟，需要一段时间才能恢复。将消息过期设置为客户端超时有助于避免这种情况。

关于用于 RPC 的 RabbitMQ。通常我们使用消息代理来解耦和持久化。看 RPC 是一种同步通信，也就是我们在等待响应，那么持久性就不是考虑因素了。这让我们脱钩了。问题是，与通过网关或 Docker 服务名称对 HTTP 进行的解耦相比，这种解耦是否能为您带来任何好处？