当从传统的单体应用架构转移到微服务架构时，特别是涉及数据一致性时，数据一致性是微服务架构中最困难的部分。传统的单体应用中，一个共享的关系型数据库负责处理数据一致性。在微服务架构中，如果使用“每个服务一个数据库”的模式，那么每个微服务都有自己的数据存储。
因此，数据库在应用程序之间是分布式的。如果每个应用程序使用不同的技术来管理它们的数据，比如非关系型数据库，这种分布式架构虽然在数据管理方面有许多好处，比如可伸缩性、高可用性、灵活性等，但在数据管理方面也存在一些关键问题，比如事务管理、数据一致性/完整性等方面。
问题：分布式系统中的数据一致性
对于单体应用程序，通过ACID事务，一个共享的关系型数据库处理并保证数据的一致性。ACID 是一个缩写，具体含义如下：
为了保持强数据一致性，关系型数据库管理系统支持ACID特性。
但在微服务架构中，每个微服务都有自己的数据存储，并采用不同的技术。因此，没有中央数据库，也没有单一的工作单元。业务逻辑被跨越到多个本地事务中。这意味着你不能在微服务架构中的数据库之间使用单一的事务工作单元。但你仍然需要在你的应用程序中使用ACID特性。
让我们用一个简单的样例场景来解释。在一个订单管理系统中，可能存在库存管理、支付和订单管理等服务。假设这些服务都按照微服务架构设计，并应用了“每个服务一个数据库”的模式。为了完成订单流程，订单服务首先调用库存管理服务进行库存控制和预留，订单中的相关产品被预留，以防止卖给其他客户。第二步是支付步骤。支付服务负责支付业务。订单服务调用支付服务，从客户的信用卡中完成支付。由于每个服务都是独立的，对分离的数据库的更新在服务范围内被提交。最后一步是创建订单记录。在这一步中，假设发生了技术错误，订单记录无法创建，订单号无法发送给客户，但已从客户那里收到了付款。这里出现了数据一致性问题。接下来我会在文章的“可能的解决方案”部分讨论在这一点之后可以做些什么。
首先，没有一种单一的解决方案适用于所有情况。根据具体情况，可以采用不同的解决方案。
解决问题有两种主要方法：
在分布式事务中，事务在两个或多个资源上执行（例如数据库、消息队列）。通过分布式事务管理器或协调器，跨多个数据库保证数据的完整性。
分布式事务是一个非常复杂的过程，因为涉及多个资源。
两阶段提交（2PC） 是一种阻塞协议，用于保证在分布式事务中所有事务要么全部成功，要么全部失败。
XA标准 是2PC分布式事务的规范。JTA包括Xtandard API。符合JTA标准的应用服务器支持Xtandard API。但所有资源必须部署到单个JTA平台才能运行2PC。对于微服务架构来说，这不太合适。
分布式事务的优点：
分布式事务的缺点：
最终一致性是分布式系统中用于实现高可用性的模型。在一个最终一致性的系统中，允许一段时间的不一致，直到解决分布式数据的问题。
这个模型不适用于跨多个微服务的分布式ACID事务。最终一致性使用BASE数据库模型。
虽然ACID模型提供了一个一致的系统，但BASE模型提供了高可用性。
BASE这个缩写代表：
SAGA 是一种操作最终一致性模型的常见模式：
(1) 基于协同的SAGA：在这种情况下，不存在中央协调器。每个服务在其任务完成后产生一个事件，并且每个服务监听事件以采取行动。这种模式需要一个成熟的事件驱动架构。
(2) 基于编排的SAGA：协调器服务（Saga执行编排器，SEG）负责根据业务逻辑对事务进行排序。编排器决定应执行哪些操作。如果某个操作失败，编排器会撤销先前的步骤。这称为补偿操作。补偿是在系统保持一致状态时发生故障时要执行的操作。
有一些可用的框架可以实现Saga编排模式，例如Camunda、Apache Camel。
SAGA的优点：
SAGA的缺点：
在维护分布式数据存储之间的数据一致性可能非常困难。在设计新应用程序时需要有不同的思维方式。我们可以说，数据一致性的责任从数据库转移到了应用程序级别。
解决方案取决于使用案例和一致性要求。总的来说，应考虑以下设计考虑因素。
(1) 尽可能避免在微服务之间使用分布式事务。使用分布式事务会带来更复杂的问题。
(2) 设计你的系统，尽可能不要求分布式一致性。为了实现这一点，识别事务边界;
(3) 考虑使用事件驱动架构进行异步非阻塞服务调用
(4) 通过补偿和协调过程设计容错系统，以保持系统的一致性
(5) 最终一致性模式需要在设计和开发方面进行思维方式的转变
微服务架构具有诸如高可用性、可伸缩性、自动化、自治团队等很多优点。为了最大程度地发挥微服务架构风格的效率，传统方法需要进行一些改变。数据和一致性管理是需要仔细设计的。
京公网安备 11010802035086号