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

文化&方法 微服务

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

作者： Andrew Morgan

正文：

在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