本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
示例 Amazon Event Fork Pipeline 使用案例
以下场景描述了一个事件驱动的、无服务器电子商务应用程序，该应用程序使用 Amazon Event Fork Pipelines。您可以在中使用此示例电子商务应用程序
此电子商务应用程序通过由 API Gateway 托管并由 Amazon Lambda 函数 CheckoutApiBackendFunction 支持的 RESTful API 来获取买方的订单。此函数将收到的所有订单发布到名为 CheckoutEventsTopic 的 Amazon SNS 主题，该主题转而将订单分散到四个不同的管道。
第一个管道是由电子商务应用程序的拥有者设计和实现的常规结算处理管道。此管道具有 Amazon SQS 队列 CheckoutQueue（此队列缓冲所有收到的订单）、一个名为 CheckoutFunction 的 Amazon Lambda 函数（此函数轮询队列以处理这些订单）和 DynamoDB 表 CheckoutTable（此表安全地保存所有已下订单）。
应用 Amazon Event Fork Pipeline
电子商务应用程序的组件处理核心业务逻辑。但是，电子商务应用程序拥有者还需满足：
-
合规性 - 安全的、压缩的静态加密备份，清理敏感信息
-
弹性 - 在执行过程中断的情况下重播最近的订单
-
可搜索性 - 对已下订单运行分析并生成指标
应用程序拥有者可为 Amazon Event Fork Pipelines 订阅 CheckoutEventsTopic Amazon SNS 主题，而不是实施此事件处理逻辑
-
事件存储与备份管道配置为转换数据以删除信用卡详细信息，缓冲数据 60 秒，使用 GZIP 压缩数据，并使用 Amazon S3 的原定设置客户自主管理型密钥来加密数据。此密钥由 Amazon 管理并由 Amazon Key Management Service（Amazon KMS）提供支持。
有关更多信息，请参阅《亚马逊数据 Firehose 开发者指南》中的 “为目的地选择亚马逊 S3”、“亚马逊数据 Firehos e 数据转换” 和 “配置设置”。
-
为事件搜索与分析管道配置了一个 30 秒的索引重试持续时间、一个用于存储无法在搜索域中编制索引的订单的存储桶和一个用来限制已编制索引的订单集的筛选策略。
有关更多信息，请参阅 Amazon Data Firehose 开发者指南中的为您的目的地选择 OpenSearch 服务。
-
事件重播管道 为配置了常规订单处理管道（由电子商务应用程序拥有者设计和实施）的 Amazon SQS 队列部分。
有关更多信息，请参阅 Amazon Simple Queue Service 开发人员指南中的队列名称和 URL。
在事件搜索与分析管道的配置中设置以下 JSON 筛选策略。它仅匹配总金额为 100 美元或更多的传入订单。有关更多信息，请参阅Amazon SNS 消息筛选。
{
"amount": [{ "numeric": [ ">=", 100 ] }]
}使用 Amazon Event Fork Pipelines 模式，电子商务应用程序拥有者可以避免在编写用于事件处理的一致逻辑后经常产生的开发开销。相反，她可以直接从 Amazon Serverless Application Repository 将Amazon Event Fork Pipelines 部署到其 Amazon Web Services 账户。