应用架构的演进 I 使用无服务器保证数据一致性
在微服务架构中，一个业务操作往往需要跨多个服务协作完成，包含了读取数据和更新多个服务的数据同时进行。在数据读取和写入的过程中，有一个服务失败了，势必会造成同进程其他服务数据不一致的问题。
亚马逊云科技开发者社区为开发者们提供全球的开发技术资源。这里有技术文档、开发案例、技术专栏、培训视频、活动与竞赛等。帮助中国开发者对接世界最前沿技术，观点，和项目，并将中国优秀开发者或技术推荐给全球云社区。如果你还没有关注/收藏，看到这里请一定不要匆匆划过，点这里让它成为你的技术宝库！
面对分布式事务，如何维护微服务应用架构的数据一致性呢？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 模式+无服务器云原生服务，可以较好地在保证一致性和高弹性之间取得平衡。亚马逊广泛采用这种架构和技术栈支持其业务。
文章来源：
还未添加个人签名 2019-09-17 加入
进入亚马逊云科技开发者网站，请锁定 https://dev.amazoncloud.cn 帮助开发者学习成长、交流，链接全球资源，助力开发者成功。
评论