This is super-nice and elegant but in practice it becomes a bit tricky
在实践中意味着,您需要设计您的微服务器,以便遵守规则时,满足必要的业务一致性:
that services cannot directly connect to a DB “owned” by another service.
换句话说 – 不要对自己的责任作出任何假设,并根据需要改变边界,直到找到一种方式来完成这项工作。
现在,你的问题:
What are the best patterns to keep things consistent and live a happy life?
对于不需要立即一致性的事物,并且更新忠诚度点似乎落在该类别中,您可以使用可靠的pub / sub模式从一个微服务器发送事件以供其他人处理。可靠的一点是,您需要对事件处理的东西进行好的重试,回滚和幂等(或事务性)。
如果您在.NET上运行,一些支持这种可靠性的基础架构示例包括NServiceBus和MassTransit.全面披露 – 我是NServiceBus的创始人。
更新:关于关于忠诚度积分的关注的以下意见:“如果余额更新被延迟处理,客户可能实际上可以订购比点数更多的项目”。
许多人为了强烈的一致性而奋斗着这些要求。事实是,通常可以通过引入额外的规则来处理这些情况,例如用户最终得到负面忠诚度点通知他们。如果T在没有将忠诚点排除在外的情况下通知用户,他们将根据某些转换率向他们收费。当客户使用积分购买商品时,客户可以看到此政策。