由 AWS 无服务器精英 Forrest Brazeal 撰写的客座博文。Forrest 是 Trek10, Inc. 的高级云架构师，Trek10 上 Think FaaS 无服务器播客的主持人，以及无服务器社区研讨会和活动的常驻演讲者。

事件与无服务器的关系就像烘豆与烧烤一样。无服务器的理念意即专注于提供业务价值的代码和配置。事实证明，在很多时候，这意味着处理事件：对应于外部世界发生事件的结构化数据。可以创建仅响应事件触发器的无服务器应用程序，而不是维护在轮询时占用资源的长时间运行的服务器任务。

在使用 AWS 中的事件时，我有很多选择：Amazon Kinesis 数据流、Amazon Simple Notification Service (SNS)、Amazon Simple Queue Service (SQS) 等，具体取决于我的要求。最近，我一直在使用一个名称中包含“event”字样的服务：Amazon CloudWatch Events。

CloudWatch Events：无服务器事件处理中保存最完好的密钥
最初知道 CloudWatch 是一项收集我的 Lambda 日志，并允许我按计划运行各项功能的服务。但 CloudWatch Events 还允许我使用 CloudWatch API 发布自己的自定义事件。它对 SNS 提供类似的定价和分发保证，并支持将大量 AWS 服务作为目标。

最重要的是，我甚至不必配置事件总线 — 因为它就在 CloudWatch 控制台中。现在，我可以使用 boto3 AWS SDK for Python 发布一个事件：

import boto3
cw = boto3.client('cloudwatch')
cw.put_events(
    Entries=[
        {
            'Source': 'my.app.event',
            'DetailType': 'MY_EVENT_TYPE',
            'Detail': '{"my_data":"As a JSON string"}'
        }
    ]
)

简而言之，CloudWatch Events 为我提供了一个完全托管的事件管道，支持任意数量的使用者，通过它我可以删除任何想删除的 JSON 字符串。这对于构建无服务器应用程序非常有用。

事件驱动架构实际操作

我每天在 Trek10 上为客户构建云原生解决方案。我经常将事件驱动架构当作一种将旧版系统迁移到无服务器的强大方法，使下游集成等操作更容易。以下是我最喜欢的几个模式：
• 绞杀遗留数据库
• 设计事件源应用程序

绞杀遗留数据库

“绞杀者模式”隐藏了包装 API 背后的遗留系统，同时逐渐将用户迁移到新界面。Trek10 之前曾写过这个。流式传输变更为云，因为事件是在关闭遗留数据库的同时打开报告和分析用例的一个极佳方式。下图显示了将遗留数据库写入事件。

此模式也可以以其他方式工作：我可以将新数据写入 CloudWatch Events，将其用于现代数据源，并创建第二个将数据同步回遗留系统的消费者。

##设计事件源应用程序
事件溯源仅仅意味着将系统状态中的变更视为事件，将它们发布在分类帐或总线上，以供不同的下游应用程序使用。

通过使用 CloudWatch Events 作为集中总线，可以对事件进行清理记录，如以下事件验证流程图所示。

验证功能确保只有符合应用程序标准的事件才会被标记为“有效”，并且提供给下游消费者使用。默认总线处理大量事件（记住，服务日志会传到这里！），因此设置仅与我关心的事件匹配的规则非常重要。

CloudWatch Events 通过提供单一总线来简化这些模式，但可以在其中应用筛选条件和订阅消费者，而无需预置或维护任何基础设施。而这才刚刚开始。

用例：使用 CloudWatch Events 进行多帐户事件处理

当我开始连接多个 AWS 账户时，CloudWatch Events 变得很有意思。通过使用过滤规则来选择转发哪些事件，在不同帐户中的 CloudWatch Event 总线之间建立信任关系变得轻而易举。

例如，想象一下大型企业 AnyCompany 的小部件处理系统。AnyCompany 有许多不同的开发团队，每个团队都使用自己的 AWS 账户。某些服务在检查仓库或在全国旅行时，会生成有关小部件的信息。另一些服务需要这些数据来运行报告或创新新产品。

假设服务 A 生成有关新小部件的信息，服务 B 希望实时查看有关小部件的聚合，而服务 C 需要有关小部件的历史数据以进行报告。完整的事件流可能如下图所示。

1.服务 A 使用以下事件正文将新的小部件事件发布到其 AWS 账户中的 CloudWatch Events：

{
            'Source': 'cwi.servicea',
            'DetailType': 'NEW_WIDGET',
            'Detail': '{"widget_id":"abc123"}'
}

2.筛选规则将带 cwi.servicea 标记的事件转发到中心事件处理帐户。使用 CloudFormation，它们可以按如下方式定义规则：

CentralForwardingRule:
    Type: AWS::Events::Rule
    Properties:
      描述：发送事件至中心账户的规则
      EventPattern:
        source:
          - cwi.servicea
      Targets:
        - Arn: !Sub arn:aws:events:${CENTRAL_ACCOUNT_REGION}:${CENTRAL_ACCOUNT_ID}:event-bus/default
          Id: CentralTarget
          RoleArn: <IAM ROLE WITH ACCESS TO PUT CW EVENTS>

3.该事件根据其标准进行验证。

4.使用新的源 valid.cw.servicea 在中心事件总线上重新发布有效事件。这一点很重要，因为为避免无限循环，单个事件只能转发一次。

5.筛选规则将有效事件转发到服务 B 的 AWS 账户，在该账户中，它更新连接到 AWS AppSync API 的DynamoDB 表。

6.第二条规则将同一事件转发到 Service C 帐户，在该帐户中，它通过 Kinesis Data Firehose 流向 Amazon S3 存储桶，以便使用 Amazon Athena 进行分析。

CloudWatch Events 在这里提供的是一个解耦系统，主要使用“即插即用”服务，但为未来的创新提供了灵活性。

充分利用云

我喜欢 CloudWatch Events 的最大原因是什么？这是一个奇妙的原生云服务。除了观察 AWS 服务限制之外，几乎不需要代码，也没有任何操作职责。我甚至不需要部署任何项目就可以开始使用该服务。然而，在表面之下，我正在使用一个强大的 AWS 基础设施，它可以毫不费力地支持复杂的分布式应用程序。

这非常接近理想的无服务器应用程序。每次我制作事件驱动应用程序时，都会确保考虑 CloudWatch Events 可以带来什么。

本文转载自AWS技术博客。

原文链接：
https://amazonaws-china.com/cn/blogs/china/building-serverless-pipelines-with-amazon-cloudwatch-events/

创作场景

使用 Amazon CloudWatch Events 构建无服务器管道