微服务-所有微服务之间是否共享事件存储技术（在事件源解决方案中）？

Question

据我目前的一点经验所知，“微服务”的核心概念之一是它依赖于自己的数据库，独立于其他微服务。

深入研究如何在微服务系统中处理分布式事务，最好的策略似乎是事件源模式，其核心是事件存储。

不同微服务之间是否共享事件存储？或者每个微服务都有多个独立的事件存储数据库和一个公共事件代理？

如果第一个选项是解决方案，那么使用CQRS，我现在可以假设每个微服务的数据库都是作为查询端的，而共享事件存储在命令端。这是一个错误的假设吗？

既然我们讨论的是这个主题：在使用乐观锁定的流中并发写入的情况下，我必须重试多少次？

非常感谢你给我的每一条建议！

Answer 1

TLDR：所有这些模式都适用于单个有界上下文（如果您愿意，服务），不要在有界上下文之外分发域事件，将集成事件发布到ESB（企业服务总线）或类似的公共接口上。

好的，我们这里有三种模式，分别简单介绍一下，然后一起介绍一下。

1. 微服务
2. CQRS
3. 活动来源

微服务

https://docs.microsoft.com/en-us/azure/architecture/microservices/核心目标：将系统中的更改隔离并解耦到单个服务，从而实现独立的部署和测试，而不会产生附带影响。这是通过在公共API后面封装更改并限制服务之间的运行时依赖来实现的。

CQRS

https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs核心目标：在单个服务中隔离写关注点和读关注点并将其解耦。这可以通过几种方式实现，但核心思想是读模型是为查询而优化的写模型的投影。

活动来源

https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing核心目标：使用业务域规则作为数据模型。这是通过将状态建模为不可变域事件的仅追加流，并通过从一开始就重放流来重建当前聚合状态来实现的。

所有在一起

这里有很多很棒的内容https://docs.microsoft.com/en-us/previous-versions/msp-n-p/jj554200（V＝PANTP。10）每一个都有它自己的复杂性，权衡和挑战，而一个有趣的练习，你应该考虑，如果成本超出利益。它们都适用于单个服务或有界上下文。一旦您开始在服务之间共享数据存储，您就会面临问题，因为共享数据存储不能单独更改，因为它现在是一个公共接口。

相反，请尝试将集成事件发布到共享总线，作为其他服务和绑定上下文的公共接口，以便使用和使用它们来构建其他域上下文数据的投影。

最好将集成事件发布为当前聚合状态的幂等快照（upsert X，delete X），尤其是在总线不是持久性的情况下。这允许您在需要时从域重新发布集成事件，而不会在使用者之间产生不一致的状态。

Answer 2

通常情况下：在服务架构（包括微服务）中，每个服务都在私有数据库中跟踪其状态。

这里的“私有”主要是指不允许其他服务写入或读取它。这可能意味着每个服务都有自己的专用数据库服务器，或者服务可能共享一个设备，但只有自己的设备的访问权限。

另一种表达方式是：服务通过公共api共享信息来相互通信，而不是通过将消息写入彼此的数据库。

对于使用事件源的服务，每个服务只能对其流进行读写访问。如果这些流碰巧存储在同一个家庭-罚款；但是系统的正确性不应该取决于不同的服务在同一设备上存储它们的事件。

Answer 3

不同微服务之间是否共享事件存储？或者每个微服务都有多个独立的事件存储数据库和一个公共事件代理？

从他们的角度来看，每个微服务都应该写入自己的事件存储。这可能意味着单独的实例或同一实例中的单独分区。这允许独立缩放微服务。

如果第一个选项是解决方案，那么使用CQRS，我现在可以假设每个微服务的数据库都是作为查询端的，而共享事件存储在命令端。这是一个错误的假设吗？

有点。正如我上面写的，每个微服务都应该有自己的事件存储（或者共享实例中的分区）。微服务不应将事件附加到其他微服务事件存储区。

关于阅读活动，我认为阅读活动通常应该被允许。轮询事件存储是将更改传播到其他微服务的最简单（在我看来也是最好的）解决方案。它的优点是，远程微服务可以以其所能达到的速率进行轮询，并查询它想要的事件。这可以通过创建事件存储副本（根据需要）进行很好的扩展。

在某些情况下，您可能不希望从事件存储中发布每个域事件。有人说可能存在其他微服务不应依赖的内部域事件。在这种情况下，您可以将事件标记为免费（或不免费）供外部使用。

在微服务中传播更改的最干净的解决方案是让其他微服务可以订阅实时查询。它的优点是投影逻辑不会泄漏给其他微服务，但缺点是发出查询的微服务必须定义并实现这些查询；当您注意到其他微服务复制了投影逻辑时，您可以这样做。此查询的一个示例是电子商务应用程序中的订单总价。您可以有这样一个查询，每次在订单中添加/删除/更新项目时，都会发布该订单的总价格。

既然我们讨论的是这个主题：在使用乐观锁定的流中并发写入的情况下，我必须重试多少次？

您需要多少就有多少，即直到写入成功为止。您可能有99999的限制，只是为了在重试机制出现严重错误时被检测到。在任何情况下，只有在同一流（对于一个聚合实例）上同时完成写入时，才应重试并发写入，而不是对整个事件存储区。