将 Amazon SNS 事件扇出到 Amazon Event Fork Pipelines - Amazon Simple Notification Service
Amazon Event Fork Pipeline 的工作原理部署 Amazon Event Fork Pipelines
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

将 Amazon SNS 事件扇出到 Amazon Event Fork Pipelines

对于事件归档和分析，Amazon SNS 现在建议使用其与 Amazon Data Firehose 的本机集成。您可以订阅 Firehose 传输流到 SNS 主题，这使您能够向存档和分析端点 [如 Amazon Simple Storage Service（Amazon S3）存储桶、Amazon Redshift 表、Amazon OpenSearch Service（OpenSearch Service）等] 发送通知。将 Amazon SNS 与 Firehose 传输流结合使用是一种完全托管且无代码的解决方案，不需要您使用 Amazon Lambda 函数。有关更多信息，请参阅 扇出到 Firehose 传输流。

您可以使用 Amazon SNS 构建事件驱动的应用程序，这些应用程序使用订阅者服务自动执行工作以响应发布者服务所触发的事件。此架构模式可提高服务的可重用性、可互操作性和可扩展性。但是，将事件处理分解为可满足常见事件处理要求的管道（例如，事件存储、备份、搜索、分析和重放）可能会非常耗费人力。

为了加快事件驱动型应用程序的开发，您可以订阅事件处理管道（由 Amazon Event Fork Pipelines 提供支持）到 Amazon SNS 主题。AmazonEvent Fork Pipelines 是一套开源嵌套应用程序，基于 Amazon 无服务器应用程序模型（Amazon SAM），您可以直接从 Amazon Event Fork Pipelines 套件将其部署到您的 Amazon 账户（选择显示创建自定义 IAM 角色或资源策略的应用程序）。

对于 Amazon Event Fork Pipeline 使用案例，请参阅 部署和测试 Amazon SNS Event Fork Pipelines 示例应用程序。

主题

Amazon Event Fork Pipeline 的工作原理

Amazon Event Fork Pipeline 是一种无服务器设计模式。不过，它也是一个基于 Amazon SAM 的嵌套的无服务器应用程序套件（可直接从 Amazon Serverless Application Repository (Amazon SAR) 部署到您的 Amazon Web Services 账户来丰富事件驱动的平台）。您可以根据架构的需要单独部署这些嵌套的应用程序。

下图显示由三个嵌套的应用程序补充的 Amazon Event Fork Pipelines 应用程序。您可以根据架构的需要，在 Amazon SAR 上单独部署 Amazon Event Fork Pipelines 套件中的任何管线。

Amazon Event Fork Pipelines 架构，展示了如何通过三个不同的管线筛选和处理来自 Amazon SNS 主题的事件：事件存储和备份、事件搜索和分析以及事件重播。这些管线被描绘成垂直堆叠的框，每个管线都独立并行处理来自同一 Amazon SNS 主题的事件。

为每个管线订阅了相同的 Amazon SNS 主题，并允许管线在事件发布到主题时并行处理这些事件。每个管线都是独立的，并且可以设置其自己的订阅筛选策略。这允许管线仅处理它感兴趣的部分事件（而不是发布到主题的所有事件）。

注意

由于您将三个 Amazon Event Fork Pipelines 与常规事件处理管道一起部署（可能已订阅 Amazon SNS 主题），因此，您无需更改当前消息发布者的任何部分即可在现有工作负载中利用 Amazon Event Fork Pipelines。

事件存储与备份管线

下图显示了事件存储与备份管线。您可以为此管线订阅 Amazon SNS 主题来自动备份流经系统的事件。

此管线包含一个 Amazon SQS 队列（该队列缓冲由 Amazon SNS 主题传输的事件）、一个 Amazon Lambda 函数（该函数自动轮询队列中的这些事件并将其推入 Amazon Data Firehose 流）和一个 Amazon S3 存储桶（该存储桶持久备份流所加载的事件）。

Fork-Event-Storage-Backup-Pipeline 旨在处理和备份来自 Amazon SNS 主题的事件。流程从 Amazon SNS 主题开始，事件通过该流程扇出到 Amazon SQS 队列。然后，这些经过筛选的事件由 Lambda 函数处理，该函数会将它们转发到 Amazon Kinesis Data Firehose。在将事件加载到 Amazon S3 备份存储桶之前，Firehose 流负责缓冲、转换和压缩这些事件。最后，可以使用 Amazon Athena 来查询存储的数据。该图使用一系列图标和箭头来说明从一项服务到另一项服务的流程，清楚地标记了管线的每个组件。

要微调 Firehose 流的行为，可将其配置为在将事件加载到存储桶之前对事件进行缓冲、转换和压缩。在加载事件时，可以使用 Amazon Athena 通过标准 SQL 查询来查询存储桶。您也可以将管道配置为重用现有 Amazon S3 存储桶或创建一个新的存储桶。

事件搜索与分析管线

下图显示了事件搜索与分析管线。您可以为此管线订阅 Amazon SNS 主题以便在搜索域中为流经系统的事件编制索引，然后对这些事件进行分析。

此管线包含一个 Amazon SQS 队列（该队列缓冲由 Amazon SNS 主题传输的事件）、一个 Amazon Lambda 函数（该函数轮询队列中的事件并将其推入 Amazon Data Firehose 流）、一个 Amazon OpenSearch Service 域（该域为 Firehose 流所加载的事件编制索引）和一个 Amazon S3 存储桶（该存储桶存储无法在搜索域中编制索引的死信事件）。

Amazon 架构中的事件搜索与分析管线。它从左边开始，Amazon SNS 主题接收所有事件。然后，这些事件通过表示“扇出筛选出的事件”的虚线汇入到 Amazon SQS 队列中。该队列中的事件由 Lambda 函数处理，该函数随后将事件转到 Amazon Kinesis Data Firehose 流。Data Firehose 将事件定向到两个目的地：一条路由通向 Amazon Elasticsearch Service 进行索引，另一条路由将无法处理的事件或“死信”事件发送到 Amazon S3 死信存储桶。在最右边，Elasticsearch Service 的输出馈送到 Kibana 控制面板中进行分析和可视化。整个流程是水平布局的，每个组件都通过显示数据流方向的线条相连。

要在事件缓冲、转换和压缩方面微调 Firehose 流，您可以配置此管线。

您也可以配置管道是应重用 Amazon Web Services 账户中的现有 OpenSearch 域，还是应创建一个新域。在搜索域中为事件编制索引时，您可以使用 Kibana 对事件运行分析并实时更新可视化控制面板。

事件重播管线

下图显示了事件重播管线。要记录系统在过去 14 天内处理过的事件（例如，当您的平台需要从故障中恢复时），您可以为此管道订阅 Amazon SNS 主题，然后重新处理事件。

此管线包含一个 Amazon SQS 队列（该队列缓冲由 Amazon SNS 主题传输的事件）和一个 Amazon Lambda 函数（该函数轮询队列中的事件，并将事件重新导入也订阅了主题的常规事件处理管线中）。

流程图格式的事件重播管线。从左到右，它以 Amazon SNS 主题开头，该主题将经过筛选的事件分发给两个并行进程。上方的流程代表您的常规事件处理管线，其中包括处理事件的 Amazon SQS 队列。下方的流程被标记为“fork-event-replay-pipeline”，包含一个 Amazon SQS 重播队列，事件在由 Lambda 重播函数处理之前会暂时存储在该队列中。此 Lambda 函数能够根据重播功能的启用还是禁用，将事件重新导入您的常规事件处理管线中或将其保留以供重播。该图还表明，操作员可以控制启用或禁用事件重播功能。
注意

默认情况下，重播功能已禁用，而不会重新导入您的事件。如果您需要重新处理事件，则必须启用 Amazon SQS 重播队列作为 Amazon Lambda 重播函数的事件源。

部署 Amazon Event Fork Pipelines

Amazon Event Fork Pipelines 套件（选择 Show apps that create custom IAM roles or resource policies（显示创建自定义 IAM 角色或资源策略的应用程序））在 Amazon Serverless Application Repository 中作为一组公共应用程序提供，可在该 SAR 中使用 Amazon Lambda 控制台手动部署和测试这些应用程序。有关使用 Amazon Lambda 控制台部署管线的信息，请参阅订阅 Amazon Event Fork Pipelines 到 Amazon SNS 主题。

在生产场景中，我们建议在整个应用程序的 Amazon SAM 模板中嵌入 Amazon Event Fork Pipelines。利用嵌套应用程序功能，可通过将资源 AWS::Serverless::Application 添加到您的 Amazon SAM 模板并引用嵌套应用程序的 Amazon SAR ApplicationId 和 SemanticVersion 来做到这一点。

例如，您可以通过将以下 YAML 片段添加到 Amazon SAM 模板的 Resources 部分来将事件存储与备份管线用作嵌套应用程序。

Backup:   
    Type: AWS::Serverless::Application
  Properties:
    Location:
      ApplicationId: arn:aws:serverlessrepo:us-east-2:123456789012:applications/fork-event-storage-backup-pipeline
      SemanticVersion: 1.0.0
    Parameters: 
      #The ARN of the Amazon SNS topic whose messages should be backed up to the Amazon S3 bucket.
      TopicArn: !Ref MySNSTopic

在指定参数值时，您可以使用 Amazon CloudFormation 内部函数来引用模板中的其他资源。例如，在上述 YAML 片段中，TopicArn 参数引用 Amazon SAM 模板中其他位置定义的 AWS::SNS::Topic 资源 MySNSTopic。有关更多信息，请参阅 Amazon CloudFormation 用户指南中的内置函数参考。

注意

Amazon SAR 应用程序的 Amazon Lambda 控制台页面包含 Copy as SAM Resource（复制为 SAM 资源）按钮，此按钮将嵌套 Amazon SAR 应用程序所需的 YAML 复制到剪贴板。