近些年来，越来越多的用户倾向于构建事件驱动的应用架构。如此一来，订阅者无需主动关心事件的产生，只需被动接受来做发布者的事件进而开始处理。简单说来，基于事件驱动的架构设计能够帮助提升系统整体的复用性、交互性和扩展性。

日常工作中，用户会针对不同的事件分别创建多种管道来处理任务，比如事件存储、备份、检索、分析，以及回放等等。为了更快速高效地构建事件驱动型应用，您可以针对 Amazon SNS 主题订阅事件处理管道（由 AWS Event Fork Pipelines 提供支持）。AWS Event Fork Pipelines 是基于 AWS 无服务器应用程序模型 (AWS SAM) 的开源嵌套应用程序套件，您可以从 AWS Event Fork Pipelines 套件（选择 Show apps that create custom IAM roles or resource policies (显示创建自定义 IAM 角色或资源策略的应用程序)）将其直接部署到您的 AWS 账户中。

Event Fork Pipelines 套件广泛采用了无服务器服务，包括 Amazon SNS, Amazon SQS 以及 AWS Lambda。借助无服务器服务的全托管特性，您能够像搭积木一样轻松快速地构建一套完全托管、既高可用同时又具备扩展性的事件驱动型架构。比如，Lambda 通过函数实现事件型微服务，SNS 和 SQS 又能以松耦合的优势方便集成各项微服务以及其它分布式系统。显而易见，这些灵活小巧的“积木”已成为了现代化应用最佳实践的核心要素。

探索事件分叉模式

目前为止，AWS与来自于不同行业和全球多个地域的客户紧密合作，构建了很多基于事件驱动的应用架构。比如：

处理银行交易和股票行情相关的金融事件平台
加速结账支付和物流配送相关的零售事件平台

通常，一套稳健而完整的大型的事件驱动架构设计，除了要实现所有的功能性需求，还要考虑常规的周边配套能力，比如：系统审计能力、数据可发现能力、合规性、商业洞察，以及业务连续性等。使用AWS，您可以迅速地找到对应的服务满足这些常见需求。比如，借助对象存储服务 S3 存储和备份平台产生的所有事件；利用 Elasticsearch 服务将关键事件索引并进行挖掘分析；另外，面对应用程序处理事件失败场景，您也可以搭建事件回放机制待后台应用程序恢复后重新开始。

然而，从最终用户角度出发，凭借自身能力逐个对接 AWS 各项服务完成周边配套能力至最终交付，仍是一项复杂充满挑战的工程。因此，AWS 推出了一站式开箱即用 Event Fork Pipelines 套件，其覆盖了事件驱动型架构所需的常见配套服务，大大缩短了构建完整平台的周期。

当前，AWS 已正式开放了此套件，全球用户均可尝试应用。而且，AWS CTO Werner Vogels 在2018年 AWS re:Invent 大会上也公开向观众介绍演示了 Event Fork Pipelines 套件。

下图演示了由三个嵌套的应用程序管道补充构建的 AWS Event Fork Pipelines 应用程序。当然，您也可以根据架构的需要，在 AWS Serverless Application Repository 上单独部署 AWS Event Fork Pipelines 套件中的任何管道。

事件存储与备份管道
事件搜索与分析管道
事件重播管道

每个管道订阅了相同的 Amazon SNS 主题，一旦有事件发布至相应主题，便可触发后段管道并行处理这些事件。然而，每个管道都是独立的，它们可以基于不同应用场景设置自己的订阅筛选策略。如此一来，不同管道仅需处理它感兴趣的部分事件而不是发布到主题的所有事件。而且，对于消息发布者，它无需更改任何部分便可在现有工作负载中利用 AWS Event Fork Pipelines 套件。这些优势极大地提升了效率，同时也降低了成本。

Figure 1 – 使用Event Fork Pipelines 套件的参考架构

由上图可见，为了使用 Event Fork Pipelines 套件，现有工作负载中的事件处理管道和流程无需做任何改变。其它管道也只需简单订阅当前的 Amazon SNS 主题，即可轻松完成与现有架构无缝对接。接下来，我们会详细介绍每一条管道以及如何部署。

详解事件分叉模式

抽象来看，AWS Event Fork Pipelines 属于无服务器设计模式。具体而言，它是基于 Serverless Application Model 嵌入了多个无服务应用的套件。您可以通过 AWS Serverless Application Repository 直接将完整套件部署至您的 AWS 账号，帮助完善事件驱动的平台。或者，也可以根据实际场景需要，只部署单个管道。

以下是套件中每一内嵌管道的详细说明：

事件存储与备份管道

Figure 2 – 事件存储与备份管道架构

上图显示了事件存储与备份管道的架构设计。您只需为此管道订阅特定 Amazon SNS 主题，管道便可自动备份流经系统的所有事件。构成此管道的服务包括：

Amazon SQS 队列，用来缓存来自于 Amazon SNS 主题传输的事件；
Lambda 函数，自动轮询队列中的事件并将其发送至 Amazon Kinesis Data Firehose 流；
S3 存储桶，备份需要保留的事件（也可添加生命周期策略进行数据管理）；

为了更好应用于不同环境，也可对上述架构进行调优适配。比如，将事件最终转储至 S3 存储桶之前，在 Kinesis Firehose 流中对数据进行格式转换或压缩等。一旦数据加载至存储桶，也可以使用 Amazon Athena 通过标准 SQL 查询存储桶中事件。或者，基于事件类型也可备份至相同或不同存储桶。

事件搜索与分析管道

Figure 3 – 事件搜索与分析管道架构

上图显示了事件搜索与分析管道的架构设计。同样，通过 Amazon SNS 主题订阅，管道便可对流经系统的事件创建搜索域并编制索引，然后对这些事件进行分析。构成此管道的服务包括：

Amazon SQS 队列，用来缓存来自于 Amazon SNS 主题传输的事件；
Lambda 函数，自动轮询队列中的事件并将其发送至 Amazon Kinesis Data Firehose 流；
Elasticsearch 域，加载来自于 Firehose 流数据事件并编制索引；
S3 存储桶，存储无法在搜索域中编制索引的死信事件；

类似于备份管道，可同样进行相关的调优适配。比如：配置管道是重用账户中的现有 Elasticsearch 域，还是应创建一个新域；事件进入域之前，在 Kinesis Firehose 流中对数据进行格式转换或压缩等要在事件缓冲、转换和压缩等。最终，借助于 Kibana 工具运行分析索引的事件并在可视化控制面板中实时更新。

事件重播管道

Figure 4 – 事件搜索与分析管道架构

上图显示了事件重播管道的架构设计。此管道能够帮助记录系统在过去 14 天内处理过的事件，一旦当您的平台需要从故障中恢复时，可将暂存的事件再次放入业务处理管道重新处理。构成此管道的服务包括：

Amazon SQS 队列，用来缓存来自于 Amazon SNS 主题传输的事件；
Lambda 函数，自动轮询队列中事件并将事件重新导入也订阅了主题的常规事件处理管道中；

默认情况下，重播功能处于禁用状态，即管道不会自动重新导入此管道队列中的事件。如果您需要开启重播功能，需要管理员在AWS Lambda 重播函数的事件源中启用 Amazon SQS 重播队列。

应用事件分叉模式

接下来，我们一起来看下如何将这些不同的管道集成在一起协同工作。以下图列展示了一个电商类应用，使用了 Event Fork Pipelines 模式构建事件驱动架构。您可以在 AWS Serverless Application Repository 中搜索到这个模版应用，通过 Lambda 控制台部署至自己账号；而且，也可在 GithHub 上获得源代码。

Figure 5 – 基于Event Fork Pipelines的电商应用架构

上述应用展示了买家在电商平台购物下单的场景，后端接口部署在 API Gateway 并以 RESTful API 的形式对外开放。接口背后业务逻辑通过 Lambda 函数 CheckoutApiBackendFunction 实现。该函数将收到的所有订单信息发布至 SNS 指定主题_CheckoutEventsTopic_ ，转而所有订阅者管道都将收到对应事件消息。其中，第一个管道“结账付款”负责实际业务逻辑处理，由应用开发人员研发部署。管道包含了一些对象资源：

SQS 队列 CheckoutQueue ，负责缓存上游所有订单信息；
Lambda 函数 CheckoutFunction ，从队列获取订单信息并进行业务处理；
DynamoDB 表格 CheckoutTable，安全可靠地存储处理后的订单信息；

上述组件和管道构成了电商应用的核心部分，为业务逻辑执行提供了必要运行环境。然而，构建一个稳定成熟同时能驱动业务发展的完整平台应用仅有这些是远远不够的；同时，也需满足其它众多非功能性方面要求，比如系统的健壮能力、是否合规，以及是否能够加速创新等，具体表现为：

安全地备份数据

经过压缩的订单数据存储时必须加密保存，而且对数据统一脱敏以此符合安全合规要求；

检索和分析订单

对于订单尤其是金额超过100美金，系统要提供关键指标检索和分析能力，比如平均送货时间，最受欢迎商品，偏爱支付方式等；

最近订单补发

订单配送过程中若出现任何问题无法成功，系统必须允许2周之内问题订单的补发，这是电商业务稳定运行的关键因素之一；

然而，如果所有这些事件驱动管道都需要从头构建的话，这无疑是巨大的挑战。为了避免重复造轮子，您可以选择直接使用 Event Fork Pipelines 套件，订阅已有 SNS 主题便可轻松拥有完整功能。每一管道的配置和工作机理如下：

事件存储和备份通道工作内容：
删除信用卡信息
缓存数据60秒
压缩数据为GZIP格式
采用默认CMK客户主秘钥加密

客户主秘钥 Customer master key（CMK）是客户通过安全托管服务 AWS KMS 服务自主生成的主秘钥信息。更多相关内容信息，请参见文档 Amazon Kinesis Data Firehose Developer Guide 段落Choosing Amazon S3 for Your Destination, Data Transformation, and Configuration Settings。

事件搜索和分析管道工作内容：
索引失败重试持续时间为30秒
创建单独存储桶保存索引失败的订单
制定订单过滤策略限制索引范围

更多相关内容信息，请参见文档 Amazon Kinesis Data Firehose Developer Guide 段落 Choosing Amazon ES for Your Destination。

事件重播管道的目标队列配置为上述业务处理即结账付款管道的入口队列。更多相关内容信息，请参见文档 Amazon SQS Developer Guide 段落 Queue Name and URL。

事件搜索和分析管道中的订单过滤策略，用来匹配所有订单中总金额超过100美金的订单，为JSON格式。更多相关内容信息，请参见文档 Amazon SNS Developer Guide 段落 Message Filtering。

通过事件分叉管道模式套件，您不再需要重复造轮子。部署也是非常简单，只需直接在 AWS Serverless Application Repository 部署至您的账号即可。

部署 AWS Event Fork Pipelines

AWS Event Fork Pipelines 套件在 AWS SAR 中作为一组公共应用程序提供（选择<显示创建自定义 IAM 角色或资源策略的应用程序>），可在该 SAR 中使用 AWS Lambda 控制台手动部署和测试这些应用程序。有关使用 AWS Lambda 控制台部署管道的信息，请参阅为 AWS Event Fork Pipelines 订阅 Amazon SNS 主题。

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

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

YAML

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

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

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

创建新的事件分叉管道

现有 Event Fork Pipelines 项目 AWS Github 官方地址在此，我们真挚地邀请您能够跟我们一起来创建新的事件管道。除了上述事件存储和备份，事件搜索和分析，以及事件重播，还有哪些常见案例场景能够被抽象成标准化事件管道？期待在 Event Fork Pipelines 套件中看到您的贡献和身影。 ****

总结

Event Fork Pipelines 是由一系列无服务器服务基于 AWS Serverless Application Model 开发出来的事件驱动架构设计模式和无服务器套件。您可以非常快速便捷地一键部署整套框架，用来丰富增强现有的内部事件驱动架构。您不用编写任何代码、搭建任何基础设施或人工干预，便可轻松获得事件存储与备份管道、搜索和分析管道，以及重播管道等。另外，您可以选择任何区域（已有架构图中涉及的各项服务）部署；而且，不需要承担任何额外费用，仅包括套件中各服务本身使用过程中产生的用量费用。

还在等什么？赶紧点击项目来部署吧！

作者介绍：

!

### 王泽耀

AWS 解决方案架构师，主要负责合作伙伴架构咨询和方案设计，同时致力于 AWS 云服务在国内的应用及推广。曾就职于 IBM，服务国内不同行业企业客户。

原文链接：
https://amazonaws-china.com/cn/blogs/china/enriching-event-driven-architectures-with-aws-event-fork-pipelines/

创作场景

借助 AWS Event Fork Pipelines 增强事件驱动架构设计