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

Question

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

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

让我们假设用户想要创建一个订单（一个电子商务系统）。但是用户可以有信用额度。所以流程如下：

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

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

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

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

1. Web 服务一直在等待，直到订单获得批准或取消（肯定包括超时）？
2. Web-service 返回 200 ok 然后用户需要间隔一段时间检查订单状态？
3. 使用网络套接字？
4. 还有别的吗？

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

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

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

Answer 1

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

这里我会建议关注，

• 用户发出订单的 POST 请求
• OrderService 首先与 UserService 核对信用额度（它可以是 REST API 调用，因为它可能是对 UserService 的简单 DB 调用）
• 然后 OrderService 可以根据 UserService 的返回响应进行操作

这种方法的优点

• 用户可以看到即时响应
• 编码更简单，因此可测试和可维护的代码

这种方法的缺点

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

最主要的是，所有的选择都会有取舍。由您决定哪一个最适合您。

Answer 2

据我了解

遵循我的规则 - 先验证再操作

在订单进入 UI 上的订单服务之前验证订单。您可以在 UI 上调用 userservice api，它提供信息用户可以下订单或不下订单。

第 1 步。在 UI 上调用 userservice API，验证用户信用额度

第 2 步。如果验证成功或失败

Step 3. 根据step2结果采取行动。如果成功调用订单服务，如果不做你想做的事（调用其他服务等）

优势

1. 良好的用户体验 - 用户在尝试下订单时收到验证消息“您无法下订单，您的限额很低”或类似的信息。最后没有收到消息“你的限制很低/或任何东西”

2. 代码复杂度更低

3. 更微服务的 Arch。 -

既然你关注微服务，那么如果你在 orderservice 中调用 userservice 意味着 orderservice 依赖于它，或者你可以说是紧密绑定 - 这里你正在失去微服务架构的好处。

如果用户服务关闭会发生什么。客户无法下订单，或者如果您更改用户服务响应中的任何内容，那么您也必须更改订单服务。

如果将来在下订单之前需要更多验证（调用其他服务），你会怎么做。

4. 重定向灵活性 - 假设如果用户服务验证失败，那么您必须调用其他服务（其他独立微服务），如果您在 orderservice 中使用其他服务，则服务随着项目的增长而增加

5. OrderService 上的请求较少 - 只有在其他服务或其他事物通过验证时，请求才会进入 orderservice。

从我的角度来看

1. 尽量让微服务独立。

2. 首先验证和操作。

3. 良好的用户体验

4. 易于处理负载（如果您认为）

有了这一切，现在你对传奇的依赖减少了。

这只是我的意见 - 根据你的领域选择你认为最好的

Answer 3

问题是用户在此期间会做什么 简单的流程？我的意思是：用户发出 POST 请求 /orders 和 ...

您可以在您的 saga 运行时回复用户创建的 orderId，状态为“待定”。请求应该在 200 结束。

用户如何获得状态？

推送通知、websocket、电子邮件、短信。由您来通知用户事件的状态、成功、失败、waiting_for_approval。

1. Web-service awaits until the order gets approved or canceled?
2. Web-service returns 200 ok and the user check the order state with some interval?
3. use web sockets?
4. something else?

1. 不推荐。 Saga 应该是异步的。等待回复是同步的（请求/回复风格）。
2. 这可行，但如果您的 saga 运行时间较长，则可能会出现问题，例如：任何需要人工验证/批准的事情。
3. 假设您在订单创建后回复 200 处于待处理状态，这将起作用，一件事是您必须确保您的 websocket 处于活动状态，否则您仍然必须通过电子邮件、短信通知他们。

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

你必须选择你的毒药。

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

使用编排的传奇（类似于）Netflix conductor、Uber Cadence、Temporal（类似于 Cadence）。这将允许您执行如下所示的操作。至少，更容易。

google shopping api 的流程图及其处理方式。

更多链接：https://developers.google.com/shopping-content/guides/about-orders