写点什么

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

  • 2019-09-30
  • 本文字数:2423 字

    阅读完需:约 8 分钟

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

由 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 boto3cw = 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/


2019-09-30 15:18907
用户头像

发布了 1908 篇内容, 共 147.2 次阅读, 收获喜欢 81 次。

关注

评论

发布
暂无评论
发现更多内容

架构实战营 模块二作业

Dylan

架构实战营

细说Python Lambda函数的用法,建议收藏!

华为云开发者联盟

Python 函数 匿名 Lambda函数 表达式

架构实战营模块 2 作业

Lukefang

使用gradle插件发布项目到nexus中央仓库

程序那些事

Java maven Gradle 程序那些事

架构实战营模块2作业

林子钧

作业 架构实战营 模块二

甲方日常 94

句子

工作 随笔杂谈 日常

模块二:课后作业

iHai

架构实战营

关于 Spring 中 getBean 的全流程源码解析

小傅哥

Java spring 源码分析 小傅哥 getBean流程

聪明人的训练(十九)

Changing Lin

4月日更

一文搞懂分布式锁的原理与实现

架构精进之路

分布式锁 4月日更

华仔架构-模块

大师兄

产品经理训练营 Week4 学习心得

Mai

微信朋友圈高性能架构

chenmin

后端服务太多,且涉及多种语言,如何进行高效管理?

我爱娃哈哈😍

架构 架构设计 架构场景实战

产品经理训练营 Week3 学习心得

Mai

【LeetCode】移除元素Java题解

Albert

算法 LeetCode 4月日更

微信朋友圈高性能复杂度分析

thewangzl

架构实战营-作业2

大肚皮狒狒

作业

图算法系列之无向图的数据结构

Silently9527

Java 数据结构和算法 图算法 无向图

app架构师,10天拿到字节跳动安卓岗位offer,好文推荐

欢喜学安卓

android 程序员 面试 移动开发

陌陌一面,为什么SpringBoot的 jar 可以独立运行?

Java小咖秀

jar maven springboot 集成 pom

架构学习模块二作业

架构实战营

产品经理训练营Week14学习心得

Mai

模块2—分析一下微信朋友圈的高性能复杂度

sandy

架构实战营

一文带你更方便的控制 goroutine

万俊峰Kevin

线程 并发 Go 语言 goroutine

Spark任务等待与运行策略

小舰

4月日更

这三年被分布式坑惨了,曝光十大坑

悟空聊架构

6种常见的地标识别算法整理和总结

华为云开发者联盟

KNN CNN 地标识别 GLDv2 地标识别算法

架构训练营-模块二作业

Neil43

架构训练营

架构实战营第二模块作业

DZ

带你入门目标检测算法

华为云开发者联盟

网络 数据集 目标检测 yolo two-stage

使用 Amazon CloudWatch Events 构建无服务器管道_语言 & 开发_亚马逊云科技 (Amazon Web Services)_InfoQ精选文章