本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Fanout Amazon SNS 事件 Amazon 到事件分叉管道
<a name="sns-fork-pipeline-as-subscriber"></a>


|  | 
| --- |
| 对于事件归档和分析，Amazon SNS 现在建议使用其与 Amazon Data Firehose 的本机集成。您可以将 Firehose 传输流订阅 SNS 主题，这样您就可以向存档和分析终端节点发送通知，例如亚马逊简单存储服务 (Amazon S3) 存储桶、亚马逊 Redshift 表、亚马逊 OpenSearch 服务（服务）等。OpenSearch 将 Amazon SNS 与 Firehose 传输流配合使用是一种完全托管且无需代码的解决方案，您无需使用任何功能。 Amazon Lambda 有关更多信息，请参阅 [扇出到 Firehose 传输流](sns-firehose-as-subscriber.md)。 | 

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

为了加快事件驱动型应用程序的开发，您可以订阅 Amazon SNS 主题的事件处理管道（由事件 Amazon 分叉管道提供支持）。 Amazon Event Fork Pipelines 是一套基于[Amazon 无服务器应用程序模型](https://www.amazonaws.cn/serverless/sam/) (SA Amazon M) 的开源[嵌套](https://docs.amazonaws.cn/serverless-application-model/latest/developerguide/serverless-sam-template-nested-applications.html)应用程序，您可以直接从 Ev [Amazon ent Fork Pipelines 套件](https://serverlessrepo.aws.amazon.com/applications?query=aws-event-fork-pipelines)（选择**显示创建自定义 IAM 角色或资源策略的应用程序**）将其部署到您的 Amazon 账户中。

有关 E Amazon vent Fork Pipelines 用例，请参阅[部署和测试 Amazon SNS Event Fork Pipelines 示例应用程序](sns-deploy-test-fork-pipelines-sample-application.md)。

**Topics**
+ [Amazon 事件分叉管道的工作原理](#how-sns-fork-works)
+ [部署 Amazon 事件分叉管道](#deploying-sns-fork-pipelines)
+ [部署和测试 Amazon SNS Event Fork Pipelines 示例应用程序](sns-deploy-test-fork-pipelines-sample-application.md)
+ [将 Amazon 事件分叉管道订阅到 Amazon SNS 主题](sns-subscribe-event-fork-pipelines.md)

## Amazon 事件分叉管道的工作原理
<a name="how-sns-fork-works"></a>

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

**Topics**
+ [事件存储与备份管线](#sns-fork-event-storage-and-backup-pipeline)
+ [事件搜索与分析管线](#sns-fork-event-search-and-analytics-pipeline)
+ [事件重播管线](#sns-fork-event-replay-pipeline)

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

![Amazon 事件分叉管道架构，展示了如何通过三个不同的管道筛选和处理来自 Amazon SNS 主题的事件：事件存储和备份、事件搜索和分析以及事件重播。这些管线被描绘成垂直堆叠的框，每个管线都独立并行处理来自同一 Amazon SNS 主题的事件。](http://docs.amazonaws.cn/sns/latest/dg/images/sns-fork-pipeline-as-subscriber-how-it-works.png)


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

**注意**  
由于您将三个 Amazon 事件分叉管道放置在常规事件处理管道旁边（可能已经订阅了您的 Amazon SNS 主题），因此您无需更改当前消息发布者的任何部分即可在现有 Amazon 工作负载中利用事件分叉管道。

### 事件存储与备份管线
<a name="sns-fork-event-storage-and-backup-pipeline"></a>

下图显示了[事件存储与备份管线](https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:077246666028:applications~fork-event-storage-backup-pipeline)。您可以为此管线订阅 Amazon SNS 主题来自动备份流经系统的事件。

该管道由一个用于缓冲由 Amazon SNS 主题传送的事件的 Amazon SQS 队列、一个自动轮询队列中这些事件并将其推送到流中的 Amazon Lambda 函数以及一个持久备份流加载的事件的 Amazon S3 存储桶组成。

![Fork-Event-Storage-Backup-Pipeline，旨在处理和备份 Amazon SNS 主题中的事件。流程从 Amazon SNS 主题开始，事件通过该流程扇出到 Amazon SQS 队列。然后，这些经过筛选的事件由 Lambda 函数处理，该函数会将它们转发到 Data Firehose。在将事件加载到 Amazon S3 备份存储桶之前，Firehose 流负责缓冲、转换和压缩这些事件。最后，可以使用 Amazon Athena 来查询存储的数据。该图使用一系列图标和箭头来说明从一项服务到另一项服务的流程，清楚地标记了管线的每个组件。](http://docs.amazonaws.cn/sns/latest/dg/images/sns-fork-event-storage-and-backup-pipeline.png)


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

### 事件搜索与分析管线
<a name="sns-fork-event-search-and-analytics-pipeline"></a>

下图显示了[事件搜索与分析管线](https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:077246666028:applications~fork-event-search-analytics-pipeline)。您可以为此管线订阅 Amazon SNS 主题以便在搜索域中为流经系统的事件编制索引，然后对这些事件进行分析。

该管道由一个用于缓冲由 Amazon SNS 主题传送的事件的 Amazon SQS 队列、一个轮询队列中的事件并将其推 OpenSearch 送到流中的 Amazon Lambda 函数、一个为 Firehose 流加载的事件编制索引的 Amazon S3 域以及一个存储无法在搜索域中编制索引的死信事件的 Amazon S3 存储桶组成。

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


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

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

### 事件重播管线
<a name="sns-fork-event-replay-pipeline"></a>

下图显示了[事件重播管线](https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:077246666028:applications~fork-event-replay-pipeline)。要记录系统在过去 14 天内处理过的事件（例如，当您的平台需要从故障中恢复时），您可以为此管道订阅 Amazon SNS 主题，然后重新处理事件。

该管道由一个 Amazon SQS 队列和一个 Amazon Lambda 函数组成，该队列用于缓冲由 Amazon SNS 主题传送的事件，以及一个用于轮询队列中的事件并将其重新驱动到您的常规事件处理管道的函数，该管道也已订阅您的主题。

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


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

## 部署 Amazon 事件分叉管道
<a name="deploying-sns-fork-pipelines"></a>

[Amazon Event Fork Pipelines 套件](https://serverlessrepo.aws.amazon.com/applications?query=aws-event-fork-pipelines)**（选择 “显示创建自定义 IAM 角色或资源策略**的应用程序”）在中作为一组公共应用程序提供 Amazon Serverless Application Repository，您可以从中使用[Amazon Lambda 控制台](https://console.amazonaws.cn/lambda/)手动部署和测试它们。有关使用 Amazon Lambda 控制台部署管道的信息，请参阅[将 Amazon 事件分叉管道订阅到 Amazon SNS 主题](sns-subscribe-event-fork-pipelines.md)。

在生产场景中，我们建议在整个应用程序的 Amazon SAM 模板中嵌入 Amazon 事件分支管道。嵌套应用程序功能允许您通过将资源添加到 Amazon SAM 模板、引用嵌套应用程序的 S Amazon AR `ApplicationId` 和`[AWS::Serverless::Application](https://docs.amazonaws.cn/serverless-application-model/latest/developerguide/serverless-sam-template.html#serverless-sam-template-application)`来实现此`SemanticVersion`目的。

例如，您可以将以下 YAML 代码段添加到 SA Amazon M 模板的`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`参数引用了模板中其他地方定义的`[AWS::SNS::Topic](https://docs.amazonaws.cn/AWSCloudFormation/latest/UserGuide/aws-properties-sns-topic.html)` Amazon SAM 资源`MySNSTopic`。有关更多信息，请参阅 *Amazon CloudFormation 用户指南*中的[内置函数参考](https://docs.amazonaws.cn/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference.html)。

**注意**  
您的 Amazon SAR 应用程序的 Amazon Lambda 控制台页面包括**复制为 SAM 资源**按钮，该按钮可将嵌套 SA Amazon R 应用程序所需的 YAML 复制到剪贴板。