应用架构的演进 I 使用无服务器保证数据一致性

<!--StartFragment--> 在微服务架构中，一个业务操作往往需要跨多个服务协作完成，包含了读取数据和更新多个服务的数据同时进行。在数据读取和写入的过程中，有一个服务失败了，势必会造成同进程其他服务数据不一致的问题。 面对分布式事务，如何维护微服务应用架构的数据一致性呢？SAGA 是一种常用的管理分布式系统数据一致性的模式。  图 1 源于：《Microservices Patterns》\ 作者：Chris Richardson SAGA 的关键思想是： * 每个操作都可以作为一个小的事务来执行。 * 如果出现失败则补偿撤销已执行的操作。 这可以确保整体的数据最终保持一致。 有几种不同的方法来构建 SAGA 的协调逻辑： ### **1.协同式** 协同式的工作原理如图所示，决策和执行顺序逻辑分布在 SAGA 的每一个参与方中；通过交换事件的方式进行沟通，订阅彼此的事件并做出相应的响应。  图 2 源于：《Microservices Patterns》\ 作者：Chris Richardson 协同式虽然复杂，但是适用于对事件发布的可靠性要求很高的场景。通常使用 Transaction Outbox 模式来确保事件被可靠地发布，即使发生系统故障。  图 3 源于：《Microservices Patterns》\ 作者：Chris Richardson 如图所示，在执行订单服务的业务逻辑时，在写入订单服务数据库的相应数据表的同时，不直接发布事件,再写一份到本地事务性的出站队列（Outbox）。只有当本地事务提交成功后，才异步地从 Outbox 中取出事件发布。一旦事件发布成功，就从 Outbox 删除这条事件。以此来确保： * 事件只会在本地事务提交后发布，不会在事务失败时发布。 * 即使系统发生故障，事件也不会丢失，会在系统重启后从 Outbox 重新发布。 * 每个事件只会发布一次，不会重复发布。 Transaction Outbox 模式牺牲了发布事件的实时性，以换取发布的可靠性，同时配置实现相对比较复杂。我们可以通过云原生服务比如 DynaomDB Stream 保证实时性和可靠性，还能降低配置的复杂度。DynaomDB Stream 是亚马逊云科技提供的一种轻量级的变更数据捕获机制，实现了一种流式的变更日志，可以对 DynamoDB 表中的数据进行近乎实时的数据变更监控。  如图所示的 DynamoDB Streams 工作机制： * 当表中有数据更改（创建、更新、删除）时，DynamoDB 会将这些更改的详细信息以流的形式记录在 DynamoDB Streams 中。 * 流包含了对表的操作类型（插入、修改、删除）以及操作前后的完整数据内容。 * 应用程序可以通过各种方式消费流，以实现近实时的数据处理和分析。 DynamoDB Streams 有以下特点： * 全量的变更捕获，无信息丢失。 * 可以消费多次，对读取流没有影响。 * 多个应用可以同时消费一个流。 * 按顺序保存和传递变更信息。 * 与表直接整合，无需建立独立的流。 ### **2.编排式** 编排式—决策和执行顺序逻辑集中在一个 SAGA 编排器中；排版器发出命令消息给各个参与方，指示参与方服务完成本地事务操作。  图 5 源于：《Microservices Patterns》\ 作者 Chris Richardson 我们可以利用云原生服务和工具来进一步提高编排式 SAGA 模式的工作和生产效率。比如使用 Amazon Step Functions 提供可视化的无服务器工作流，来编排 SAGA 中一系列分布式操作。利用 Step Functions 的编排机制来协调 SAGA 中各个服务的交互。  图 6 在亚马逊云上，可以通过 Step Functions 来坐标 SAGA 模式的各个函数执行流程。无服务器服务可以提供保证： * **AmazonLambda+AmazonDynamoDB：** 实现幂等函数和事务写入。 * **AmazonSQS：** 作为函数之间的异步通信。 * **AmazonSNS：** 发布—订阅模型进行函数触发。 * **AmazonCloudWatch：** 记录函数执行日志。 * …. ### **小结** SAGA 模式+无服务器云原生服务，可以较好地在保证一致性和高弹性之间取得平衡。亚马逊广泛采用这种架构和技术栈支持其业务。  <!--EndFragment-->