微服务架构CQRS

Question

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

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

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

问题：

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

Answer 1

架构决策是关于权衡的，因为您定义了需求，所以一切都会发生（特别是关于 q.2）。对于每个服务来说，独立使用缓存而不是作为公共资源是有意义的（从部署的角度来看，您可以使用单个实例来托管不同的缓存），用您自己的服务包装缓存 API 似乎并没有多大作用的意义。

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