微服务架构CQRS

Question

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

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

1. 使用CQRS模式，以便可以轻松分隔查询和命令。目前，我有2个终点
2. 我有一个“手动” API网关，它将充当我需要的各种微服务的代理
3. 使用NServiceBus在微服务之间进行通信

问题：

1. 我正在考虑使用Redis缓存查询。例如，缓存用户详细信息。但是，由于它是一个缓存，所以我认为它不应成为事实的来源，这意味着我将同时更新另一个数据存储。根据我对最佳做法的理解，1个微服务只能处理1个数据存储。因此，我将创建一个仅处理对我有意义的缓存数据的端点。
   处理和添加/更新命令的最佳方法是什么？更新缓存并触发事件以更新主数据存储？或更新数据存储并触发事件以更新缓存。我的感觉是，我应该在缓存之前先更新主数据存储区（因为我不打算公开并终结点来更新缓存，所以它应该仅用于只读目的），但这会导致一些潜在的不一致。尽管我知道，在微服务领域，数据“最终是一致的”，这是否意味着对于诸如更新之类的简单操作，即使用户提交了更改，用户也可能不会直接更新其个人数据？
2. 我可以看到人们越来越拥护事件采购。如果（目前）真的不需要审核，甚至不需要重播事件的方式，是否需要？我觉得我可以使用消息总线/ sagas来完成所有工作，我认为这比使用事件存储要好得多。我说得对吗？

Answer 1

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

关于处理命令-最终还是可以选择的-您可以同时更新真相源和事务性缓存（实际或近似取决于您的需要），您可以在查询后更新中标记要更新（未缓存）版本-还有谁说您甚至需要缓存，并且可能还有其他几种选择

Answer 2

我不确定从哪里开始，但我会尽力回答您的一些问题。但是我100％与Arnon Rotem-Gal-Oz在一起。这都是关于权衡的问题。

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

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

关于最终一致性的另一件事。很多人最终都会遇到问题，但是在引入缓存时他们不会眨眼。但是缓存永远不会与数据存储100％同步，因此您从缓存中检索的数据已经不与数据存储100％一致，因此最终还是一致的。我希望能回答您有关最终一致性的问题？ o：-）

  

我可以看到人们越来越拥护事件采购。如果（目前）我真的不需要审核甚至不需要重播事件的方式，我是否需要它？

即使您需要审核或重播事件的方法，我也没有发现引入事件来源的任何理由。

注意：我指的是一种事件源，您可以根据某些事件存储中的事件来构建（或合并）对象（或集合）。

只需将您发送的消息存储在某个地方。这样，您便拥有了审核日志，并且可以重播事件。由于您已经在使用NServiceBus，因此可以使用其审核功能。

如果您想了解所有这些信息，请给我发送电子邮件至support@particular.net，我们可以对此进行进一步讨论。