使用 Saga 实现微服务中的数据一致性

看新闻很累？看技术新闻更累？试试下载 InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！

在 QCon 2017 旧金山大会上，软件架构师 Chris Richardson做演讲介绍了微服务中的数据一致性技术。演讲主要提出了一种称为“Saga 模式”的方法，它将一个分布式事务划分一组较小的事务，所划分的事务或者全部提交，或者全部回滚。

演讲的要点包括：

• 单个微服务可以确保符合 ACID，因为每个微服务都具有自己的数据库。
• 要在微服务架构中实现分布式事务，可以考虑采用 Saga 模式。它将一个事务划分成一组较小的事务，事务间通过消息传递连接在一起，所有事务必须全部完成，或全部回滚。
• Saga 模式并不提供隔离性保证，这意味着必须对异常情况采取一定的措施。
• 为了保证 Saga 提交或回滚，应组合使用事务日志结尾和消息传递。

Richardson 指出，微服务体系结构中的每个微服务，都应该具有不能被其它微服务直接访问的专用数据库。

这种架构虽然实现了松耦合，但是 Richardson 指出，它同时也引入了数据一致性的问题。“我们应该如何实现跨多个微服务的事务？”

为解决数据一致性问题，Richardson 提出了一种 Saga 模式。其核心理念是避免使用长期持有锁（例如两阶段提交）的长事务，而应将事务切分为一组按序依次提交的短事务。Saga 满足 ACD 特性：

• 原子性：所有的事务或者全部执行，或者全部补偿。
• 一致性：本地数据库和应用代码都提供参照完整性。
• 持久性：由消息代理和数据库提供保证。

虽然 Saga 的特性接近于 ACID ，但仍不满足隔离性。这意味着 Saga 可从未完成的事务中读取和写入数据，从而引入了各种隔离异常。为了解决这个问题，Richardson 列出了多种对策。包括使 Saga 中事务可交换，甚至是使用版本文件支持事务以任何顺序发生。

Richardson 还展示了回滚将面对更大的挑战，因为回滚不再是无代价的，正如在符合 ACID 的数据库中那样。回滚必须在应用代码中实现。最重要的是，当同步 API 请求触发异步 Saga 时，必须决定何时给出响应。是否应该阻止响应直至 Saga 完成，还是应立即返回并由用户通知？Richardson 推荐后者，因为后者提高了可用性，也因为大多数 UI 可以隐藏来自用户的异步性。

理查德森还介绍了 Saga 的两种协调方式。一种称为编排（choreography），Saga 件在微服务之间异步发射。另一种称为编制（orchestration），只是一个集中的服务触发器，跟踪 Saga 中的所有步骤。Richardson 认为，编制方法具有最大的优势。它可以减少循环依赖，并且如果它是集中式的，就更容易推理一个 Saga。为了实现这一点，他介绍了 Tram，一种为 Java 编写的开源 Saga 框架。

据 Richardson 介绍，Saga 间的通信类似于正常事务，Saga 必须保证全部完成或全部回滚。由此，Richardson 认为消息传递是唯一合理由的选择方式，主要因为与 HTTP 相比，消息传递具有持久性保证。他还建议在发送消息之前，将消息写入到本地数据库，这意味着可对事务日志结尾，这样新的日志在到来后就可以发布，进一步强化了 ACD 保证。

完整的演讲可在线观看。 Tram 的开源代码 tig 在 GitHub 上。

查看英文原文： Data Consistency in Microservices Using Sagas