微服务架构下，如何确保数据在不同服务间的一致性？

本文共计3690个文字，预计阅读时间需要15分钟。

在微服务中，一个逻辑上的原子操作可以实现跨多个微服务的操作。例如，单机系统也可能采用多个数据库或消息传递解决方案。利用多个独立的数据存储，如果涉及一个分布式流程，可以实现解决方案。

在微服务中，一个逻辑上原子操作可以经常跨越多个微服务。即使是单片系统也可能使用多个数据库或消息传递解决方案。使用多个独立的数据存储解决方案，如果其中一个分布式流程参与者出现故障，我们就会面临数据不一致的风险 - 例如在未下订单的情况下向客户收费或未通知客户订单成功。在本文中，我想分享一些我为使微服务之间的数据最终保持一致而学到的技术。

为什么实现这一目标如此具有挑战性？只要我们有多个存储数据的地方（不在单个数据库中），就不能自动解决一致性问题，工程师在设计系统时需要注意一致性。目前，在我看来，业界还没有一个广为人知的解决方案，可以在多个不同的数据源中自动更新数据 - 我们可能不应该等待很快就能获得一个。

以自动且无障碍的方式解决该问题的一种尝试是实现两阶段提交（2PC）模式的XA协议。但在现代高规模应用中（特别是在云环境中），2PC似乎表现不佳。为了消除2PC的缺点，我们必须交易ACID for BASE并根据要求以不同方式覆盖一致性问题。

Saga模式

在多个微服务中处理一致性问题的最着名的方法是Saga模式。您可以将Sagas视为多个事务的应用程序级分布式协调。根据用例和要求，您可以优化自己的Saga实施。相反，XA协议试图涵盖所有场景。Saga模式也不是新的。它在过去已知并用于ESB和SOA体系结构中。最后，它成功地转变为微服务世界。跨越多个服务的每个原子业务操作可能包含技术级别的多个事务。Saga Pattern的关键思想是能够回滚其中一个单独的交易。众所周知，开箱即用的已经提交的单个事务无法进行回滚。