微服务传奇模式的消费者等待回应

Question

我想阐明什么是组织架构的最佳方法。

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

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

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

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

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

一切看起来不错。但是问题是用户在此简单流程中将做什么？ 我的意思是：用户发出POST请求/订单，然后...

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

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

面临的挑战是我描述了最简单的情况。实际上，可能会涉及数十个服务（甚至第三方）。当然，我期望负载很大。因此队列可能已满。

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

Answer 1

赞扬一个很好的问题。如果我们看一下Saga模式，它可以像分布式系统中的事务一样执行ACID，但需要权衡取舍。权衡之一是如果服务或实体中的任何一个未能完成应做的工作，则确保回滚。如果您完成一项Saga的服务超过5个，这甚至会变得非常复杂。如果可以编排，这将是高度可扩展的选项。

在这里，我将建议以下

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

这种方法的优点

• 用户可以看到即时回复
• 较少复杂的代码，因此可测试且可维护的代码

这种方法的缺点

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

最主要的是，所有选项都需要权衡取舍。由您决定哪个人最适合您。

Answer 2

据我

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

在UI上的订单服务之前验证订单。您可以在UI上调用userservice api，该API使信息用户可以下订单。

步骤1。在用户界面上，调用userservice API，该API验证用户信用额度

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

步骤3.根据步骤2的结果采取措施。如果成功，则致电订购服务，如果没有做您想做的事情（致电其他服务等。）

优势

1. 良好的用户体验-用户在尝试下达订单时收到验证消息“您无法下达限制而无法下达订单”。最后没有收到消息“您的限制太低/或其他任何限制”

2. 代码复杂度较低

3. 更多的微服务Arch。-

由于您遵循微服务，因此如果您在orderservice内调用用户服务，则意味着orderservice依赖于微服务，或者您可以说绑定紧密-在这里，您将失去mircroservice arch的好处。

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

如果将来在下订单之前需要更多验证（致电其他服务），该怎么办。

1. 重定向灵活性-假设如果从userservice验证失败，那么您必须调用其他服务（其他独立的微服务），并且如果您正在使用orderservice内部的其他服务，服务随着项目的增长而增加

2. 对OrderService的请求减少-仅当从其他服务或其他事物传递了验证时，请求才进入orderservice。

所以从我的角度来看

1. 尽可能使微服务独立。

2. 首先验证并采取行动。

3. 良好的用户体验

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

有了这些，现在您就不再需要依赖传奇了。

这只是我的意见-根据您的域选择最合适的语言

Answer 3

<块引用>

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

您可以在 saga 运行时回复用户创建的 orderId 状态为“pending”。请求应该在 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. 这会奏效，但如果您的传奇长期运行，则可能会出现问题，例如：任何需要人工验证/批准的内容。
3. 假设您在待处理状态下创建订单后回复 200，这将起作用，一件事是您必须确保您的 websocket 处于活动状态，否则，您仍然必须通过电子邮件、短信通知他们。

<块引用>

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

你必须选择你的毒药。

<块引用>

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

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

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

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