Pra*_*tic 10 domain-driven-design microservices
假设有两个微服务:订单和库存.还有就是为了服务,它的API ProductId,Qty等,并下订单.
理想情况下,如果库存服务中存在库存,则只允许下订单.人们建议使用Saga模式或任何其他分布式交易.这很好,最终将利用一致性.
但是如果有人想滥用这个系统怎么办呢.他可以推销ProductId无效或库存不足的产品订单.系统将接受所有这些订单并将这些订单放入队列,库存服务将处理这些无效订单.
不应该事先处理(在订购服务中)而不是将这些无效订单推送到下一级别(特别是在productId无效的情况下)
处理这些方案有哪些建议？
处理这些方案有哪些建议？
让您的订单服务访问过滤掉不需要的订单所需的数据.
基本情节是,虽然库存服务是库存状态的权限,但您的订单服务可以使用库存的缓存副本来确定接受哪些订单.
对库存的更改最终会复制到订单服务的缓存中 - 这就是您的"最终一致性".如果Inventory在一段时间内脱机,Order可以根据其缓存中的信息继续提供业务价值.
您可能还想关注缓存中数据的年龄 - 如果自上次更新缓存以来已经过了太多时间,那么您可能想要更改策略.
您的"聚合"通常不会知道他们正在处理缓存; 您将传递订单数据一个域服务,该域服务支持聚合需要执行其工作的查询; 域服务的实现访问缓存以提供答案.
只要您不允许滥用者提供自己的域服务实例,或直接操作缓存,就可以确保缓存数据的完整性.
(例如:当您测试聚合时,您可能会提供针对您的特定测试场景调整的缓存数据;那种劫持不是您希望滥用者能够在您的生产环境中实现的).
| 归档时间： |
|
| 查看次数： |
2157 次 |
| 最近记录： |