Microservices，CQRS:最终一致性与强一致性(写入后读取一致性)

Question

使用CQRS和事件存储，微服务之间的编排将提供最终的一致性，其中一个微服务的更改需要一些时间才能传播到其他相关的下游系统(本质上是其他的微服务)。如果数据如此关键，以至于两个微服务都应该对数据具有很强的一致性，那么有哪些选择呢？我能想到的一种选择是像数据网格那样的写Cache，但在分布式系统中，这是非常脆弱的。

Answer 1

在这种情况下，考虑C.A.P.定理。根据Wikipedia，“CAP定理指出，在存在网络分区的情况下，必须在一致性和可用性之间做出选择。注意，CAP定理中定义的一致性与ACID数据库事务中所保证的一致性有很大不同。”

因为您有两个微服务，所以您的系统肯定需要具有分区容忍度，并且您可以使用A(可用性)或C(一致性)。如果您想使用C，那么您的系统将在可用性方面受到影响。当请求进入Microservice A时，在A从Microservice B返回数据已成功存储的响应之前，不应该将成功消息发送回客户端。通过这种方式，您可以通过牺牲可用性来实现一致性。

Answer 2

强大的协同性在分布式服务中是很难实现的，而对于微服务则是非常困难的，因为它们拥有自己的数据。这意味着您只能在微服务中具有强大的一致性。

但是，您可以使用Saga/流程管理器将关键操作建模为一个复杂的过程。这意味着您使用Saga以您的业务可以接受的方式编排操作的完成。例如，您可以使用类似于预约模式的东西

该模式通过实现两次传递协议(有点类似于两阶段提交)，以有序的方式管理资源分配过程。在第一次传递过程中，发起者要求每个参与者保留自己。如果发起者从所有涉及的服务(在超时内)获得一个OK，它将开始第二次传递，确认对所有参与者的预订。

Answer 3

在这种情况下，每当任何活动以帐户形式启动时，它都可以从利息微服务中获取当前状态，这样您将始终保持同步，但您将使服务相互依赖，以便当利息服务关闭时，帐户服务将有效地关闭。

向下看你的问题，我认为你需要考虑的是一致性是否如此重要(我提出这个问题，就像我们认为一致性是存在的一样。

例如:如果你在亚马逊上下订单，你需要发送一个客户身份证，你应该检查客户身份是否有效。

这将使订单服务依赖于客户服务。

另一个解决方案是在下订单时不要检查客户id，而是在OrderPlace事件上检查它并采取必要的行动。

因此，要确保系统能够更好地响应状态的多变性，而不是专注于微观服务中的事务。但是如果是的话，有一些对商业非常重要的需求，那么就让它们依赖于它们。