如何在微服务中跨服务执行验证

Question

假设有两个微服务:订单和库存。order service中有一个API，它接受< code>ProductId 、< code>Qty等并下订单。

理想情况下，只有在库存服务中存在库存时才允许下订单。人们建议使用Saga模式或任何其他分布式事务。这很好，最终将利用一致性。

但是如果有人想滥用这个系统。他可以使用无效或缺货的产品(< code>ProductId)推送订单。系统将接受所有这些订单，并将这些订单放入队列，库存服务将处理这些无效订单。

这不应该预先处理（在订单服务中），而不是将这些无效订单推送到下一个级别（特别是在 productId 无效的情况下）

处理这些场景的建议是什么？

Answer 1

我不会试图说服你在下单前不要做这个检查，而是像往常一样依靠萨加斯；我会认为这是你必须实现的业务要求。

对我来说，这似乎是一个新的子域：不良行为预防（或者你想怎么称呼它），它伴随着一个新的责任：防止虐待者。您可以将此责任添加到订单微服务中，但您会破坏SRP。因此，它应该在另一个微服务中完成。

这个新的微服务是从您的API网关（如果您有）或从Orders微服务调用的。

如果您不添加新的微服务（出于不同的原因），那么您可以将此新功能作为Orders微服务内部的一个模块来实现，但我强烈建议将其与主机（独立的私有持久性/数据库/表）高度解耦。

Answer 2

您绝对希望预先确保可以捕获尽可能多的无效业务案例。有几种方法可以解决这个问题。这与预订航空公司座位时的情况相同。虽然他们确实超额预订，但我们现在将忽略:)

选项1：您可以将库存项目作为订单的一部分保留。这是一种更悲观的方法，但您的项目将在等待确认时保留。

选项2：只有当有库存项目可用时，您才可以接受订单，但不能保留它，并希望它以后可用。

如果库存项目不可用，并且您希望支持延期交货，您也可以创建延期交货。

如果你选择选项1，如果一个项目已经为客户a预订，而客户B来了，并且无法订购，你可能会错过一个客户。如果客户A决定不完成订单，库存项目将再次可用，但客户B现在已前往其他地方尝试采购该项目。

作为订单履行的一部分，您必须通知库存限制上下文您现在正在购买该商品。但是，您现在可能会发现客户A和客户B都接受了他们的报价，并为最后一件商品创建了订单。一个人会输。此时，无法履行的人将向客户发送一封邮件，告知他们不幸的情况，并可能创建一个延期订单；或者要求客户在X天数后再试一次。

您的领域专家应该决定如何处理这些场景，这完全取决于项目的受欢迎程度等。

Answer 3

处理这些场景的建议是什么？

让您的订单服务访问它过滤掉不需要的订单所需的数据。

基本情况是，虽然库存服务是库存状态的权威机构，但您的订单服务可以使用库存的缓存副本来确定要接受的订单。

对库存的更改最终会被复制到订单服务的缓存中——这就是您的“最终一致性”。如果库存在一段时间内离线，订单可以根据其缓存中的信息继续提供业务价值。

您可能还需要注意缓存中数据的年龄——如果自缓存上次更新以来已经过了很长时间，那么您可能需要改变策略。

您的“聚合”通常不知道它们正在处理缓存；您将与订单数据一起传递一个域服务，该域服务支持聚合完成其工作所需的查询；域服务的实现访问缓存以提供答案。

只要您不允许滥用者提供他自己的域服务实例，或者直接操作缓存，那么缓存数据的完整性就得到了保证。

（例如：当您测试聚合时，您可能会提供针对您的特定测试场景调整的缓存数据；这种劫持不是您希望滥用者能够在您的正式生产环境中实现的）。