阿里云事件生态再升级：使用 EventBridge 驱动全量云产品

作者： 昶风

引言

用户使用阿里云每天都会有大量的事件产生，例如云资源的增删改查、配置的变更、应用的水位报警等。这些事件部分是由用户业务操作触发产生，部分是由系统检测自动产生，这些离散的事件实时反映着用户云上资源的状态，稍加挖掘便可以产生实用的价值。阿里云 EventBridge 作为云上事件枢纽，早已集成了云上产品的各类事件，用户开通 EventBridge 后使用内置的云服务专用总线就可以监听这些事件，无需创建任何额外资源。

同时，阿里云各个云服务提供了 open API 以满足用户对云上资源管理的需求。对于期待搭建事件驱动架构（EDA）应用的云上用户而言，通过事件来触发调用云服务 open API 进行资源管理的能力将是业务能力版图中不可或缺的一部分。

为了增强 EventBridge 对云产品的驱动能力，EventBridge 在近期上线了 open API target，open API target 可以驱动所有云产品 openAPI，使得用户能够基于 EventBridge 来触发云产品 open API 以管理自己的云上资源。

至此，EventBridge 实现了对云服务事件的闭环处理，云服务事件的产生、接收、加工等都可以使用 EventBridge 来完成，帮助用户低成本实现云上事件与资源的管控。

云服务专用总线与阿里云官方事件源

事件总线 EventBridge 是阿里云提供的一款无服务器事件总线服务，支持阿里云服务、自定义应用、SaaS 应用以标准化、中心化的方式接入，并能够以标准化的 CloudEvents 1.0 协议在这些应用之间路由事件，可以帮助用户轻松构建松耦合、分布式的事件驱动架构。

在 EventBridge 架构中，事件的流转过程是这样的：首先事件由事件源产生，随后被投递到事件总线，经过滤转换处理后最终投递给事件目标。事件源是事件的生产者，事件总线是事件在 EventBridge 中的承载者。EventBridge 目前已经支持了阿里云服务产生的各类事件，用户通过一些简单的配置即可获取。

为了保证资源隔离，在事件总线和事件源层面，EventBridge 将云服务事件与用户自定义事件做了隔离处理，我们分别称之为云服务专用总线与阿里云官方事件源。

云服务专用事件总线

在事件总线层面，EventBridge 目前支持的事件总线类型有 2 种：云服务事件总线和自定义事件总线。

自定义事件总线是需要用户自行创建并管理的事件总线，用于接收自定义应用或存量消息数据的事件。自定义应用或存量消息数据的事件只能发布到自定义总线。

而云服务专用事件总线是一个无需创建且不可修改的内置事件总线，用于接收阿里云官方事件源的事件。阿里云官方事件源的事件只能发布到云服务专用总线。

对于云服务事件，EventBridge 真正做到了开箱即用，用户使用云服务专用事件总线即可与众多云服务的事件生态打通。

阿里云官方事件源

EventBridge 将云服务事件统一收敛到一个事件源，称之为阿里云官方事件源。

官方事件源支持了目前阿里云几乎所有类型的云服务，按照分类而言包括但不限于弹性计算、存储、数据库、安全、大数据、人工智能、网络与 CDN、视频服务、容器、中间件、开发运维、域名和网站、物联网、企业应用与服务等。

对于云服务事件，其类型包含以下几类：

1. 操作审计事件：阿里云服务通过操作审计接入作为事件源发布到事件总线 EventBridge 的事件类型。操作审计事件类型有：

• API 调用事件。主要指开发者通过 API 主动对相关资源进行 CRUD 调用的事件，大量阿里云控制台基于 API 开发，对应的操作行为也会记录为 ApiCall 事件。 
• 部分控制台或售卖页的管控事件。由于这些控制台或售卖页并不是基于 API 来开发的，因此操作审计会将此类事件类型记录为 ConsoleOperation 或 ConsoleCall。此类事件的名称并不一定是 API 名称，但能够传达基本操作行为的含义。 
• 阿里云平台对用户资源执行的管控事件。由阿里云发起的操作，比如实例续费、到期释放。例如，在创建 ECS 实例时，设置了实例自动释放时间，那到时就会产生 type:AliyunServiceEvent 的事件，这个事件不是主动调用的，而是阿里云平台调用的，此类事件就是 AliyunServiceEvent 事件。目前此类事件主要存在于预付费实例的到期自动释放事件。 

2. 配置审计事件：阿里云服务通过配置审计接入作为事件源发布到事件总线 EventBridge 的事件类型。配置审计事件类型有：

• 配置变更历史。配置审计将产生的资源变更事件进行推送。
• 资源不合规事件。当检测到资源不合规时，配置审计会将相关资源不合规的事件进行投递。

3. 云监控事件：阿里云服务通过云监控接入作为事件源发布到事件总线EventBridge的事件类型。 
4. 采集事件：只要开通相应的阿里云服务，就可以自动接入事件总线 EventBridge，事件总线 EventBridge 即可采集的事件。

阿里云官方事件源使用示例可以参考：
https://help.aliyun.com/docum...

利用 EventBridge 驱动云产品 open API

基础概念

阿里云官方事件源解决了获取云上事件的问题，使得用户可以感知云上资源的变化。但对于部分用户而言，感知并不是最终目的，他们更期望的是可以进一步对云上的资源进行操作。为了达到这一目的，用户可以在自己的业务代码中使用云服务的 openAPI 来实现，但当业务所使用云服务数目很多时，开发和后续运维成本将会陡然上升。

为了补足在云服务资源管控方面的能力，EventBridge 在近期上线了 open API target，使得 EventBridge 具有驱动所有云产品 open API 的能力。用户可以使用现有事件来触发 open API 调用，进而进行云资源的管理。open API target 允许用户将阿里云服务的 open API 作为事件目标。具体而言，它类似一个“触发器”，当有满足条件的事件到来时，open API target 会按照用户预先设定的参数去调用云服务 open API。

使用介绍

在使用 open API target 时，需要提供以下参数：

• 云服务名称
• 云服务 API 版本
• API 名称
• API 参数列表
• 调用 API 角色 

以上云产品相关信息可以通过查询对应云产品 sdk 文档来获取。

针对调用 API 角色，其实是允许 EventBridge 以这个角色的身份去调用 open API。用户需要创建一个自定义角色，并将其授信给事件总线 EventBridge。角色的权限方面则可以按照需要去进行设置，在权限最小的原则基础上，确保当前权限内容可以满足调用 target 所指定的 open API。

使用示例

下面举个例子介绍如何通过 open API target 创建 RocketMQ topic 资源。

1. 首先需要准备一个事件源，这里为了便于测试，我们使用一个 source；
2. 选择一个事件总线，点击“创建规则”；

3. 填入事件规则名称与描述

4. 在配置事件模式部分选择准备的 http 事件源

5. 在配置事件目标时，在“云产品接口触发”中选择 RocketMQ，版本选择“2019-02-14”，接口类型选择“OnsGroupCreate”。API 参数按照需求填写，注意这里参数即可以填写常量，也可以使用 jsonPath 从事件中获取。在角色配置一栏选择授信给 EventBridge 的角色，在这里此角色的权限策略已经满足调用此接口的条件。

6. 点击“创建”，完成 open API target 创建工作。

7. 随后使用 http source 发送事件，事件内容如下:

{
 "InstanceId": "MQ_INST_****_BXvPp0bx",
 "GroupId": "GID_openAPITest"
}

8. 观察事件轨迹&MQ 控制台查看，可以发现事件成功投递，对应 Group 成功创建

至此，我们成功通过 EventBridge 调用了云服务 RocketMQ 的 open API。

最佳实践

按需创建快照

快照是云盘数据在某一时刻的完整拷贝或镜像。快照作为云盘的数据拷贝，天然适合灾备场景，也可以用于制作镜像，完成环境复制。针对误操作导致的应用崩溃，快照的存在也可以帮助用户对业务数据进行快速回滚，降低误操作带来的影响。

ECS 提供了周期性创建快照的能力，但对于部分客户而言，按需创建快照或许是一个更为现实的需求。例如针对业务开发上线阶段，对快照的需求可能较为迫切，此时可能需要在每次发布前都保存快照，以便问题排查和数据回滚。但进入业务维护阶段，创建快照的需求可能并不频繁。

如图所示，用户在 EventBridge 控制台创建 http source 与 open API target，其中 open API target 具体为创建 ECS 镜像。当业务进行部署时，用户可以通过 http source 来投递事件到 EventBridge，最终触发快照创建。投递事件的逻辑也可以在业务中进行更加自定义的定制，例如仅在大版本更新时才去进行 webhook 触发等。这样一来，用户无需引入ECS  相关 open API，且对镜像的创建操作也真正的做到了按需进行。

测试环境资源管理

针对云上测试场景，有时需要先创建一些资源，待测试完成之后，再对这些资源进行删除。

假定测试订单处理场景是这样的：用户在函数计算上部署了测试下单服务与订单处理服务，测试下单服务将发送一定数目的订单数据发送至 RocketMQ，订单处理消费 MQ 中的数据。服务配置信息等从数据库中读取。

测试前需要以下前提条件：

1. 在数据库中插入测试数据
2. 创建 RocketMQ topic 以做订单异步处理

测试结束后需要清理回收的资源：

1. 数据库中删除测试数据；
2. 清理掉刚刚测试创建的 topic；

如图，要满足上述测试场景，用户可以按照类似方式使用 EventBridge：

• 创建资源初始化规则，此规则包含 2 个 target，open API target 用于创建 rocketmq topic，而 mysql target 则用于初始化测试数据；  
• 创建资源清理规则，此规则和资源初始化规则类似，区别在于此处的 target 执行的是资源清理逻辑； 
• 创建测试启动规则，此规则的 target 是函数计算服务，用户通知测试下单服务开启测试流程。 

在上述规则创建完成之后，用户仅需要在投递事件到对应规则即可完成测试工作的各个阶段。

运维自动化

运维工作的场景之一就是监控项配置，下面是一些运维时常见的场景。

1. 某些业务发布期间会触发监控项报警，运维人员可能需要临时关闭报警，以避免不必要的短信、电话内容带来误判，等待发布结束之后再开启报警；
2. 当有员工加入或者离职时，人事系统需要将此用户从报警联系中添加或者移除，这样保证新加入员工可以及时获取报警信息，同时也避免了业务运维状况信息泄露给离职人员；
3. 当有新业务部署时，需要增加主机监控，监测业务进程指标。

使用 EventBridge + 云监控 CMS 就可以实现上述运维工作的自动化。

如图，在 EventBridge 上配置好 CMS 相关的 open API target。针对业务系统，在业务部署前后向 EventBridge 投递相应事件，完成报警项的关闭与开启，同时自动配置主机监控。针对人事系统，在员工离职与入职环节增加事件投递这一步骤，进而触发报警联系人的更新。这样，用户仅需在 EventBridge 上进行简单的操作，即可实现对监控能力的运维自动化。

感兴趣的小伙伴们可以扫描下方二维码加入钉钉群讨论（群号：44552972）

点击此处，进入 EventBridge 官网了解更多信息～