c# - 微服务架构 CQRS

Question

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

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

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

问题:

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

Answer 1

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

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