微服务架构 CQRS答案

【问题标题】：Microservices architecture CQRS微服务架构 CQRS
【发布时间】：2019-05-17 08:25:05
【问题描述】：

我正在启动一个个人项目，以了解实现微服务的最佳方式。它可能是经过精心设计的，但它更像是一个学习过程。这可能无关紧要，但我正在使用.Net Core

我对设计解决方案的想法如下：

问题：

我正在考虑使用 Redis 来缓存查询。例如，缓存用户详细信息。但是，由于它是一个缓存，我认为它不应该是事实的来源，这意味着我将同时更新另一个数据存储。根据我对最佳实践的理解，1 个微服务应该只处理 1 个数据存储。因此，我将创建一个仅处理对我有意义的缓存数据的端点。
处理和添加/更新命令的最佳方法是什么？更新缓存并触发事件以更新主数据存储？或者更新数据存储和触发事件来更新缓存。我的感觉是我应该在缓存之前先更新主数据存储（因为我不打算公开和端点来更新缓存，它应该仅用于只读目的）但这会导致一些潜在的不一致。虽然我明白，在微服务世界中，数据是“最终一致的”，这是否意味着对于像更新这样的简单操作，即使他提交了他的更改，用户也可能不会直接更新他的个人数据？
我可以看到人们越来越提倡事件溯源。如果（目前），我真的不需要审核，甚至不需要重播事件的方法，我需要吗？我有一种感觉，我可以使用消息总线 / sagas 来完成这一切，我认为它比使用事件存储的性能要高得多。我说的对吗？

【问题讨论】：

【解决方案1】：

我不确定从哪里开始，但我会尝试回答您的一些问题。但我 100% 支持 Arnon Rotem-Gal-Oz。这都是关于权衡的。

使用消息传递时，队列中可能会有一条消息用于订购已耗尽库存的商品。换句话说，虽然客户（和系统）认为它可以订购产品，但当消息到达时，它就不再有库存了。从技术角度来看，您可以说这意味着您的数据不一致。

从业务角度来看，这意味着一种不同的情况，您可以退还钱，让客户等待库存补充或为他们提供替代方案。企业总能找到处理不一致的方法。换句话说，现实世界已经很好地处理了最终的一致性。

关于最终一致性的另一件事。很多人在最终一致性方面存在问题，但在引入缓存时他们不会眨眼。但是缓存永远不会 100% 与数据存储同步，因此您从缓存中检索的数据已经不是 100% 与数据存储一致，因此最终是一致的。我希望这能回答你关于最终一致性的问题吗？ o:-)

我可以看到人们越来越提倡事件采购。如果（目前）我真的不需要审核，甚至不需要重播事件的方法，我需要它吗？

即使您需要审计或重播事件的方法，我认为没有任何理由引入事件溯源。

注意：我的意思是您根据某些事件存储中的事件构建（或混合）对象（或聚合）的那种事件源。

只需将您发送的消息存储在某处即可。这样你就有了你的审计日志，你可以重播你的事件。由于您已经在使用 NServiceBus，您可以使用它的审计功能。

如果您想了解更多有关这一切的信息，请发送电子邮件至 support@particular.net，我们可以进一步讨论。

【讨论】：

谢谢。我们什么时候应该考虑使用事件存储？感觉使用消息总线类型的通信比使用事件存储的性能要好得多。
两者似乎是非常不同的解决方案。一种是一种数据存储，另一种用于发送消息。我没有看到如何选择一个而不是另一个来达到相同的目标？
虽然解决方案完全不同，但我真正想要的是微服务之间最好的通信方式。为此，我似乎可以使用事件存储或消息传递？对我而言，不同之处在于事件存储可用于重播，而消息传递是一次性的

【解决方案2】：

架构决策是关于权衡的，既然您定义了需求，一切都会顺利进行（尤其是关于 q.2）关于q1。每个服务独立使用缓存而不是作为公共资源是有意义的（从部署的角度来看，您可以使用单个实例来托管不同的缓存）用您自己的服务包装缓存 API 似乎并没有多大意义有道理。

关于处理命令 - 最终一致性再次成为一种选择 - 您可以以事务方式更新事实来源和缓存（真实或近似，取决于您的需要），您可以在查询后更新中标记您想要最新的更新（未缓存）版本 - 此外，谁说您甚至需要缓存，并且可能还有其他几个选项

【讨论】：