假设有两个微服务：订单和库存。订单服务中有一个API，需要ProductId，Qty等来下订单。
理想情况下，如果库存服务中存在库存，则只允许订购。人们建议使用Saga模式或任何其他分布式交易。这很好，最终将利用一致性。
但如果有人想滥用这个系统怎么办？他可以使用无效或库存不足的产品（ProductId s）推送订单。系统将获取所有这些订单并将这些订单放入队列，库存服务将处理这些无效订单。
不应该提前处理（在订购服务中）而不是将这些无效订单推送到下一级别（特别是在productId无效的情况下）
处理这些情况有哪些建议？
答案 0 :(得分：6)
处理这些情况有哪些建议？
让订单服务人员访问过滤掉不良订单所需的数据。
基本情节是，虽然库存服务是库存状态的权限，但您的订单服务可以使用库存的缓存副本确定接受哪些订单。
对库存的更改最终会复制到订单服务的缓存中 - 这是您最终的一致性＆＃34;。如果库存在一段时间内下线，订单可以根据其缓存中的信息继续提供商业价值。
您可能也希望关注缓存中数据的年龄 - 如果自上次更新缓存以来已经过了太多时间，那么您可能想要更改策略。
您的＆＃34;聚合＆＃34;通常不知道他们正在处理缓存;您将与订单数据一起传递域服务，它支持聚合需要执行其工作的查询;域服务的实现访问缓存以提供答案。
只要您不允许滥用者提供自己的域服务实例，或直接操作缓存，就可以确保缓存数据的完整性。
（例如：当您测试聚合时，您可能会提供针对您的特定测试场景调整的缓存数据;那种劫持不是您希望滥用者能够在您的生产环境中实现。）
答案 1 :(得分：0)
您绝对希望事先确保能够捕获尽可能多的无效业务案例。有几种方法可以解决这个问题。这与在航空公司预订座位时的情况相同。虽然他们做的超额预订我们现在忽略了：）
选项1：您可以预订库存物料作为订单的一部分。这更像是一种悲观的方法，但是当您等待确认时，您的项目将被保留。
选项2：只有当库存商品可用但不保留库存商品并希望以后可用时，您才能接受订单。
如果库存商品不可用且您想要支持延期交货，您也可以创建延期交货。
如果您使用选项1，如果已为客户A预留了某个项目且客户B出现且无法订购，则您可能会错过客户。如果客户A决定不完成订单，则库存商品将再次可用，但客户B现已离开其他地方尝试获取商品。
作为订单履行的一部分，您必须告知您现在正在处理该项目的库存限制上下文。但是，您现在可能会发现客户A和B都接受了他们的报价并为最后一个项目创建了订单。一个会失败。此时，无法完成的人将向客户发送邮件并告知他们不幸的情况，并可能创建一个后退订单;或要求客户在X天内重试。
您的域名专家应该就如何处理方案进行调用，这一切都取决于项目的受欢迎程度等。
答案 2 :(得分：0)
我不会试图说服你在下订单之前不做这个检查，而是依靠Sagas，因为通常这样做;我将认为这是您必须实施的业务要求。
这对我来说似乎是一个新的子域：不良行为预防（或者你想如何称呼它）带来新的责任：防止滥用者。您可以将此职责添加到Order微服务中，但是您可能会破坏SRP。所以，应该在另一个微服务中完成。
这个新的微服务是从您的API网关（如果有的话）或Orders微服务中调用的。
如果您不添加新的微服务（出于不同的原因），那么您可以将这个新功能作为Orders微服务中的模块实现，但我强烈建议将其与主机高度分离（单独和私有持久性/数据库/表格）。