Chr*_*nte 9 distributed-computing distributed-system event-sourcing microservices
就我目前的一点点了解，“微服务”的核心概念之一就是它依赖于自己的数据库，独立于其他微服务。
深入探讨如何在微服务系统中处理分布式事务，最好的策略似乎是事件溯源模式，其核心是事件存储。
事件存储是否在不同的微服务之间共享？或者每个微服务都有多个独立的事件存储数据库和一个公共事件代理？
如果第一个选项是解决方案，使用 CQRS 我现在可以假设每个微服务的数据库都用作查询端，而共享事件存储在命令端。这是一个错误的假设吗？
既然我们在这个主题中：如果使用乐观锁定在 Stream 中进行并发写入，我必须重试多少次？
非常感谢您给我的每一条建议！
事件存储是否在不同的微服务之间共享？或者每个微服务都有多个独立的事件存储数据库和一个公共事件代理？
从他们的角度来看，每个微服务都应该写入自己的事件存储。这可能意味着同一实例内的单独实例或单独分区。这允许微服务独立扩展。
如果第一个选项是解决方案，使用 CQRS 我现在可以假设每个微服务的数据库都用作查询端，而共享事件存储在命令端。这是一个错误的假设吗？
有点。正如我上面写的，每个微服务都应该有自己的事件存储（或共享实例内的分区）。微服务不应将事件附加到其他微服务事件存储。
关于阅读事件，我认为一般应该允许阅读事件。轮询事件存储是将更改传播到其他微服务的最简单（在我看来也是最好的）解决方案。它的优点是远程微服务以它所能达到的速度和它想要的事件轮询。通过创建事件存储副本，可以根据需要进行非常好的扩展。
在某些情况下，您不想从事件存储中发布每个域事件。有人说可能存在其他微服务不应该依赖的内部域事件。在这种情况下，您可以将事件标记为免费（或不免费）以供外部消费。
在微服务中传播更改的最干净的解决方案是让其他微服务可以订阅实时查询。它的优点是投影逻辑不会泄露给其他微服务，但也有发射微服务必须定义+实现那些查询的缺点；当您注意到其他微服务重复投影逻辑时，您可以执行此操作。此查询的一个示例是电子商务应用程序中的总订单价格。WhatIsTheTotalPriceOfTheOrder每次在订单中添加/删除/更新项目时，您都可以发布这样的查询。
既然我们在这个主题中：如果使用乐观锁定在 Stream 中进行并发写入，我必须重试多少次？
根据您的需要，即直到写入成功为止。您可以设置 99999 的限制，以便在重试机制出现严重错误时进行检测。在任何情况下，只有在同一流（对于一个聚合实例）上同时完成写入时才应重试并发写入，而不是整个事件存储。