domain-driven-design - 如何在微服务中跨服务执行验证

Question

假设有两个微服务:订单和库存。订单服务有一个 API 需要 ProductId , Qty等并下订单。

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

但是，如果有人想滥用该系统怎么办。他可以推送包含无效或库存不足的产品 (ProductId s) 的订单。系统将接受所有这些订单并将这些订单放入队列中，库存服务将处理这些无效订单。

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

处理这些情况的建议是什么？

Answer 1

What are the recommendations to handle these scenarios?

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

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

对 Inventory 的更改最终会复制到 Orders 服务的缓存中——这就是您的“最终一致性”。如果 Inventory 离线一段时间，Order 可以根据其缓存中的信息继续提供业务值(value)。

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

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

只要不让滥用者提供自己的域服务实例，或者直接操作缓存，就保证了缓存数据的完整性。

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