微服务 Saga 模式消费者等待响应

Dav*_*ell 8 rest events event-driven saga microservices

我想澄清组织架构的最佳方式是什么。

我有休息 api 和微服务架构。我已经应用了每个服务模式的数据库。

所以让我们想象一下用户想要创建一个订单(一个电子商务系统)。但是用户可以有信用额度。所以流程如下:

  • OrderService 创建一个挂单。然后推送一个关于它的事件。

  • UserService 处理该事件并发布超出信用额度事件或信用保留事件。

  • OrderService 接收事件并将订单的状态更改为已批准或已取消。

一切看起来都不错。但问题是用户在这个简单的流程中会做什么?我的意思是:用户发出 POST 请求 /orders 和 ...

  1. Web 服务等待订单获得批准或取消(包括肯定超时)?
  2. Web 服务返回 200 ok 然后用户需要每隔一段时间检查订单状态?
  3. 使用网络套接字?
  4. 还有什么?

不幸的是,上面的任何选项都有其优点和缺点。

挑战在于我描述了最简单的情况。实际上,可能涉及数十个服务(甚至第三方)。当然,我期待高负载。所以队列可能被填满。

请提出解决方案进行讨论。我非常感谢答案以及指向生产就绪系统文档的链接。

小智 1

感谢一个好问题。如果我们看一下 Saga 模式,它可以像分布式系统中的事务一样进行 ACID 操作,但需要进行一些权衡。权衡之一是确保在任何服务或实体未能完成其应做的事情时进行回滚。如果您有超过 5 个服务完成一个 Saga,这可能会变得更加复杂。不过,如果您可以进行编排,这将是一个高度可扩展的选项。

在这里我将提出以下建议,

  • 用户发出订单 POST 请求
  • OrderService 首先检查 UserService 关于信用额度的信息(它可以是 REST API 调用,因为它可能是 UserService 的简单数据库调用)
  • 然后 OrderService 可以根据 UserService 的返回响应采取行动

这种方法的优点

  • 用户可以看到立即回复
  • 代码不太复杂,因此可测试和可维护的代码

这种方法的缺点

  • 如果外部(第三方)rest api 调用过多,此解决方案将无效
  • 它可能会引入单点故障

最主要的是,所有的选择都会有权衡。由您决定哪一种最适合您。