分布式数据管理

整体式应用程序通常由大型关系数据库支持，该数据库定义了所有应用程序组件通用的单个数据模型。在微服务方法中，这样一个中央数据库将阻止构建分散和独立组件的目标。每个微服务组件都应具有自己的数据持久层。

然而，分布式数据管理带来了新的挑战。根据 CAP 法则可知，分布式微服务架构本质上以一致性为代价来提高性能，因此需要实现最终一致性。

在分布式系统中，业务事务可以跨多个微服务。由于它们不能利用单个 ACID 事务，因此最终可能是部分执行。在这种情况下，我们需要一些控制逻辑来重做已处理的事务。为此，通常会使用分布式 Saga 模式。在业务事务失败的情况下，Saga 会编排一系列补偿事务，以撤消前面事务所做的更改。AWS Step Functions 使您能够轻松实施 Saga 执行协调器，如下图所示。

Saga 执行协调器

构建经核心数据管理工具和程序策管的关键参考数据集中存储，为微服务提供了一种同步其关键数据并可能回滚状态的方法。将 Lambda 与计划的 Amazon CloudWatch Events 结合使用，您可以构建简单的清理和重复数据删除机制。

状态变化影响多个微服务是很常见的。在这些情况下，事实证明，事件溯源是一种有用的模式。事件溯源背后的核心思想是，将每个应用程序更改表示并保存为事件记录。不是持久保存应用程序状态，而是将数据存储为事件流。数据库事务日志记录和版本控制系统是事件溯源的两个众所周知的示例。事件溯源有几个好处：可以确定和重建任何时间点的状态。它自然会生成持久的审计跟踪，也便于调试。

在微服务架构的上下文中，事件溯源可以通过使用发布/订阅模式解耦应用程序的不同部分，并且它将相同的事件数据输送到独立微服务的不同数据模型中。事件溯源经常与命令和查询责任分割 (CQRS) 模式结合使用，以将读取工作负载与写入工作负载分离，并优化二者的性能、可扩展性和安全性。在传统的数据管理系统中，命令和查询是针对同一个数据存储库运行的。

下图显示如何在 AWS 上实施事件溯源模式。Amazon Kinesis Data Streams 充当中央事件存储的主要组件，可捕获应用程序更改作为事件，并将其保存在 Amazon S3 上。此图描述了三种不同的微服务，包括 Amazon API Gateway、AWS Lambda 和 Amazon DynamoDB。箭头表示事件流：当微服务 1 经历事件状态更改时，它会通过在 Kinesis Data Streams 中写入消息来发布事件。所有微服务都会在 AWS Lambda 中运行自己的 Kinesis Data Streams 应用程序，该应用程序读取消息的副本，根据微服务的相关性进行筛选，并可能转发以供进一步处理。如果您的函数返回一个错误，则 Lambda 将重试批处理，直到处理成功或数据过期。为避免分片停滞，可以将事件源映射配置为以较小的批处理大小重试，限制重试次数或者丢弃太早的记录。要保留丢弃的事件，可以配置事件源映射，以将有关失败批处理的详细信息发送到 Amazon Simple Queue Service (Amazon SQS) 队列或 Amazon Simple Notification Service (Amazon SNS) 主题。

AWS上的事件溯源模式

Amazon S3 持久存储所有微服务中的所有事件，当进行调试、恢复应用程序状态或审计应用程序更改时，它是唯一的事实来源。有两个主要原因可能导致多次向您的 Kinesis Data Streams 应用程序提供记录：创建者重试和使用者重试。您的应用程序必须预计并适当地应对多次处理单个记录的问题。