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

Question

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

例如(虚构示例,仅用于说明):

• 微服务A - 存储用户(getUser等)
• 微服务B - 商店订单(createOrder等)

现在,如果我想从客户端应用程序添加新订单,我需要知道用户地址.所以请求将是这样的:

客户端 - >微服务B(userOd 5的createOrder) - >微服务A(ID为5的getUser)

微服务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:

当您需要异步通信时.例如,当您的订单服务创建订单时,您可能希望通知产品服务以减少产品数量.或者您可能想要成功放置用户订单的nofity用户服务.

我强烈建议您查看http://microservices.io/patterns/index.html

Answer 2

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

您所做的取决于您的要求，您可以选择REST API（您可以看到服务之间的同步行为），也可以选择基于事件的设计（您发现服务需要异步行为），两者结合起来也没有什么坏处。

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

基于 REST 的架构

• 优势

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

  2. 由于没有中间经纪人，系统更简单

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

• 退税

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

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

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

事件驱动架构

• 优势

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

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

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

• 退税

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