作者：王川（弗丁）
引言
EventBridge 作为构建 EDA 架构的基础设施，通过一些外围概念和个性提供了灵便丰盛的事件收集、解决和路由的能力。对于不少用户来说，通过控制台里的便捷的疏导来应用 EventBridge 应该是最快的上手形式。此外，也有很多用户面临着大量的云产品的治理，应用控制台治理每一个资源的形式变成了惨重的手工操作累赘。
为了解决这个问题，当初曾经可能通过 OpenAPI、terraform 等形式将 EventBridge 的能力方便快捷的带给用户。本文将重点介绍 EventBridge 和 IaC 的重点概念和个性，而后演示如何利用 IaC 理念自动化部署 EventBridge 来应用这些概念和个性。
EventBridge 概述
事件驱动架构
事件驱动架构是一种松耦合、分布式的驱动架构，收集到某利用产生的事件后实时对事件采取必要的解决，紧接着路由至上游零碎，无需期待零碎响应。应用事件总线 EventBridge 能够构建各种简略或简单的事件驱动架构，以标准化的 CloudEvents 1.0 协定连贯云产品和利用、利用和利用等。
事件驱动架构体系架构具备以下三个能力：
• 事件收集 ：负责收集各种利用产生的事件，如新建订单，退换货订单等其余状态变更；
• 事件处理 ：对事件进行脱敏解决，并对事件进行初步的过滤和筛选；
• 事件路由：剖析事件内容并将事件路由散发至上游产品。
事件驱动架构具备以下劣势：
• 升高耦合 ：升高事件生产者和订阅者的耦合性。事件生产者只需关注事件的产生，无需关注事件如何解决以及被分发给哪些订阅者；任何一个环节呈现故障，都不会影响其余业务失常运行；
• 异步执行 ：事件驱动架构实用于异步场景，即使是需要高峰期，收集各种起源的事件后保留在事件总线中，而后逐渐散发传递事件，不会造成零碎拥塞或资源过剩的状况；
• 可扩展性： 事件驱动架构中路由和过滤能力反对划分服务，便于扩大和路由散发；
• 敏捷性： 事件驱动架构反对与各种阿里云产品和利用集成，反对事件路由至任何零碎服务，提供各种麻利高效的部署计划。
应用 EventBridge 构建 EDA 架构
事件总线 EventBridge 是阿里云提供的一款无服务器事件总线服务。EventBridge 提供的几个外围概念，能够满足构建 EDA 架构的须要。
事件总线 EventBridge 反对以下事件源：
**• 阿里云官网事件源
• 自定义事件源 **
事件总线 EventBridge 的事件总线包含以下类型：
• 云服务专用事件总线 ：一个无需创立且不可批改的内置事件总线，用于接管您的阿里云官网事件源的事件；阿里云官网事件源的事件只能公布到云服务专用总线；
• 自定义事件总线：须要您自行创立并治理的事件总线，用于接管自定义利用或存量音讯数据的事件；自定义利用或存量音讯数据的事件只能公布到自定义总线。
在 EventBridge 中，一个事件规定蕴含以下内容：
• 事件模式：用于过滤事件并将事件路由到事件指标；
• 事件指标：包含事件的转换和解决，负责生产事件。
EventBridge 提供了简洁的事件模式匹配语法，同时具备灵便的事件转换能力，前面将会通过演示来展现一些具体的例子。
此外，EventBridge 还提供了一些加强能力，这些能力使得 EDA 架构中流经的事件更加通明，具备了开箱即用的观测和剖析能力：
• 事件追踪：能够查看公布到事件总线 EventBridge 的事件内容和解决轨迹；
• 事件剖析：对公布到事件总线的各种事件进行查问剖析解决和可视化图表展现，以便发现事件外在价值。
IaC 简介
在介绍完事件总线 EventBridge 的相干根底内容后，接下来一起理解下 IaC。在 DevOps 的实际中，IaC 是十分重要的局部，通过将基础设施代码化，版本化，便能够轻松的借助版本控制工具来提供 single source of truth、协调多人单干的变更、施行严格的 review、借助一些 CI/CD pipeline 工具（甚至 GitOps）来主动触发部署。软件系统的开发者仅付出很小的致力去形容需要，就能够在几分钟后失去所需的虚拟机、网络等云上的服务，极大的缩短了部署工夫，同时还可能保障多个环境的配置一致性，通过缩小人为操作也升高了引入谬误的概率。
IaC 的代码实际中个别有两种形式，命令式和申明式。
• 命令式：顾名思义，须要明确收回每一个动作的指令，形容的是 How，比方“创立一台 xx 规格的 ECS”。代码须要对每一步动作的程序认真编排，解决各种可能的谬误，尤其要留神解决好每次变更对曾经存在的资源的影响，否则稍有不慎就可能造成服务中断。举例来说，作为开发者能够通过本人相熟的编程语言调用阿里云的 OpenAPI 来治理资源，因为这些 API 是相似 Create、Describe、Delete 等操作，这就是一种命令式的 IaC 实际。
• 申明式： 意味着开发者仅形容本人的需要终态是什么样子，即形容 What，比方“一台 xx 规格的 ECS”。相熟 Kubernetes 的同学应该对这个概念很相熟了。IaC 工具能够通过形容资源之间的依赖关系主动编排程序，如果有曾经存在的资源，则比对冀望的状态和理论状态的差别，并依据差别做出更新；如果不存在，须要进行创立。能够看出，申明式对开发者十分敌对，极大的升高了开发者的心智累赘。
IaC 带来的劣势：
• 降低成本： 无效治理资源，并缩小为此投入的人力；
• 晋升效率 ：放慢资源交付和软件部署的速度；
• 危险管制：
• 缩小谬误；
• 进步基础架构一致性；
• 打消配置偏移
terraform 作为 IaC 畛域的佼佼者，提供了弱小的自动化治理基础设施的能力。生态丰盛，很多云厂商都提供了官网插件，阿里云的大多数产品（包含 EventBridge）都对 terraform 做了很全面的反对，使得跨多云部署基础设施变得极其简略。既然是 IaC，terraform 提供了本人的语言 HCL（hashicorp configuration language），HCL 具备相似 json 的简洁的语法，通过申明式的资源形容，能够让开发者疾速上手。
入手实际
筹备工作
• 装置 terraform cli 工具，能够参见 https://www.terraform.io/cli 的内容。
• 创立一个 tf 文件 terraform.tf，内容如下（须要替换 <> 内的值）
provider "alicloud" {
access_key = "<your access key>"
secret_key = "<your secret key>"
region = "<region id>"
}案例 1：通过钉钉监控云上资源变动
假如一个用户应用了很多云上的资源作为生产环境，须要感知线上资源的变更操作，一个可行的计划是利用 EventBridge 将来自于 ActionTrail 的审计事件投递到用户的钉钉。
首先依据钉钉官网文档创立一个机器人，记下 webhook url 和加签的秘钥，接下来会用到。
创立一个 tf 文件 1_actiontrail2dingding.tf，内容如下（须要替换 <> 内的值）
# 案例 1：通过钉钉监控云上资源变动
# 指标：# - 相熟部署应用 EventBridge 的 default 总线
# - 相熟 EventBridge 的事件模式匹配
# - 相熟 EventBridge 的事件转换配置
# 申明一个 default 总线上的规定
resource "alicloud_event_bridge_rule" "audit_notify" {
# default 总线默认存在，所以这里能够间接应用
event_bus_name = "default"
rule_name = "audit_notify"
description = "demo"
# 通过后缀匹配的形式过滤来自所有云产品事件源的 ActionTrail:ApiCall 事件
# 其余更多模式匹配的介绍能够查阅文档：https://help.aliyun.com/document_detail/181432.html
filter_pattern = jsonencode(
{
"type" : [
{"suffix" : ":ActionTrail:ApiCall"}
]
}
)
targets {
target_id = "test-target"
endpoint = "<your dingtalk bot webhook url>"
# type 的取值能够查阅文档：https://registry.terraform.io/providers/aliyun/alicloud/latest/docs/resources/event_bridge_rule#type
type = "acs.dingtalk"
# 每个事件指标都有一组对应的 param_list，具体能够查阅文档：https://help.aliyun.com/document_detail/185887.html
# 每一个 param 的 form 关系到事件转换的配置，能够查阅文档：https://help.aliyun.com/document_detail/181429.html
param_list {
resource_key = "URL"
form = "CONSTANT"
value = "<your dingtalk bot webhook url>"
}
param_list {
resource_key = "SecretKey"
form = "CONSTANT"
value = "<your dingtalk bot secret key>"
}
# 这里展现了 TEMPLATE 类型的事件转换形容
# value 是应用 jsonpath 援用事件内容的字典，template 则是模板内容，EventBridge 最终会依据这两者联合事件自身渲染出这个参数的值
param_list {
resource_key = "Body"
form = "TEMPLATE"
value = jsonencode(
{
"source": "$.source",
"type": "$.type"
"region": "$.data.acsRegion",
"accountId" : "$.data.userIdentity.accountId",
"eventName" : "$.data.eventName",
}
)
template = jsonencode(
{
"msgtype" : "text",
"text" : {"content": "来自 $${source} 的 $${type} 审计事件：$${accountId} 在 $${region} 执行了 $${eventName} 操作"
}
}
)
}
}
}在命令行窗口顺次执行命令：
• 初始化 terraform init
• 预览变更 terraform plan
• 利用变更 terraform apply
在云产品控制台进行操作，这里以 KMS 为例
钉钉上收到音讯告诉
在 EventBridge 控制台查看事件轨迹
案例 2：自定义总线触发 FunctionCompute
假如一个用户的利用会产生一些事件，其中一个链路是通过 FunctionCompute 对这些事件进行弹性的解决。那么就能够通过 EventBridge 的自定义事件源和函数计算事件指标来实现这个计划。
创立一个模仿对事件进行解决的 python 脚本文件 src/index.py，内容如下：
# -*- coding: utf-8 -*-
import logging
def handler(event, context):
logger = logging.getLogger()
logger.info('evt:' + str(event))
return str(event)创立一个 tf 文件 2_trigger_function.tf，内容如下（须要替换 <> 内的值）
# 案例 2：自定义总线触发 FunctionCompute
# 指标：# - 相熟部署应用 EventBridge 的自定义总线
# - 相熟 "自定义利用" 事件源配置
# - 相熟“FunctionCompute”事件指标配置
# 因为用户本人产生的事件须要投递到自定义总线，这里申明一个叫 demo_event_bus 的自定义总线
resource "alicloud_event_bridge_event_bus" "demo_event_bus" {
event_bus_name = "demo_event_bus"
description = "demo"
}
# 申明一个在 demo_event_bus 总线上的自定义事件源，用于通过 sdk 或者控制台向 EventBridge 投递事件
resource "alicloud_event_bridge_event_source" "demo_event_source" {
event_bus_name = alicloud_event_bridge_event_bus.demo_event_bus.event_bus_name
event_source_name = "demo_event_source"
description = "demo"
linked_external_source = false
}
# 申明一个叫 fc_service 的函数计算服务，publish=true 意味着会立刻部署上传的函数代码。resource "alicloud_fc_service" "fc_service" {
name = "eb-fc-service"
description = "demo"
publish = true
}
# 将后面筹备的 python 脚本文件打包成 zip 用于部署到函数计算
data "archive_file" "code" {
type = "zip"
source_file = "${path.module}/src/index.py"
output_path = "${path.module}/code.zip"
}
# 申明一个 fc_service 服务中的函数，其中 filename 援用了下面形容的 zip 包，会将这个代码包上传。resource "alicloud_fc_function" "fc_function" {
service = alicloud_fc_service.fc_service.name
name = "eb-fc-function"
description = "demo"
filename = data.archive_file.code.output_path
memory_size = "128"
runtime = "python3"
handler = "index.handler"
}
# 申明一个在 demo_event_bus 总线上的规定
resource "alicloud_event_bridge_rule" "demo_rule" {
event_bus_name = alicloud_event_bridge_event_bus.demo_event_bus.event_bus_name
rule_name = "demo_rule"
description = "demo"
# 通过匹配 source 过滤来自于后面创立的自定义事件源的事件
filter_pattern = jsonencode(
{"source" : ["${alicloud_event_bridge_event_source.demo_event_source.id}"]
}
)
targets {
target_id = "demo-fc-target"
# type 的取值能够查阅文档：https://registry.terraform.io/providers/aliyun/alicloud/latest/docs/resources/event_bridge_rule#type
type = "acs.fc.function"
endpoint = "acs:fc:<region id>:<your account id>:services/${alicloud_fc_service.fc_service.name}.LATEST/functions/${alicloud_fc_function.fc_function.name}"
param_list {
resource_key = "serviceName"
form = "CONSTANT"
value = alicloud_fc_service.fc_service.name
}
param_list {
resource_key = "functionName"
form = "CONSTANT"
value = alicloud_fc_function.fc_function.name
}
param_list {
resource_key = "Qualifier"
form = "CONSTANT"
value = "LATEST"
}
# 留神 form=ORIGINAL 意味着每次投递事件都会将事件的原始内容作为这个参数的值
param_list {
resource_key = "Body"
form = "ORIGINAL"
}
}
}在命令行窗口顺次执行命令
• 初始化 terraform init
• 预览变更 terraform plan
• 利用变更 terraform apply
在控制台模仿自定义事件源公布事件
在 FunctionCompute 的控制台页面查看函数调用日志
在 EventBridge 控制台查看事件轨迹
总结
EventBridge 作为构建 EDA 架构的基础设施，通过一些外围概念和个性提供了灵便丰盛的事件收集、解决和路由的能力，并反对通过 OpenAPI、terraform 等形式将这些能力方便快捷的带给用户。本文介绍了 EventBridge 和 IaC 的重点概念和个性，而后演示了如何利用 IaC 理念自动化部署 EventBridge 来应用这些概念和个性。
期待大家能够挖掘更多利用 EventBridge 疾速搭建 EDA 架构的 idea，并应用 terraform 快捷的将这些 idea 变为事实。
相干链接
[1] 阿里云 terraform 文档
https://help.aliyun.com/produ…
[2] terraform registry 文档
https://registry.terraform.io…
[3] 钉钉官网文档
https://open.dingtalk.com/doc…
想要理解更多 EventBridge 相干信息，扫描下方二维码退出钉钉群～
点击此处，即可观看文章对应的视频～