EventBridge 事件领域重点特性介绍（二）| 学习笔记-阿里云开发者社区

开发者学堂课程【EventBridge 入门课程：EventBridge 事件领域重点特性介绍（二）】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/1220/detail/18280

EventBridge 事件领域重点特性介绍

四、演示

接下来，通过两个案例来给大家演示一下如何利用 telphone 来基于这种 IaC 的实践方式部署 EventBridge 相关资源。首先，先看一下 telphone。

各个云厂商或者第三方提供 provider,统一管理的地方，在这里看到页面是阿里云的 provider 官方页面。这里左侧罗列了很多阿里云上可以操作的资源，需要关注的主要是 EventBridge 的这些资源。这里介绍如何使用这个 provider 要拷贝这个内容到描述文件。现在看一下具体的代码。

主要有两个案例，第一个通过钉钉监控云上资源的变化，主要目标是熟悉 EventBridge 总线怎么去部署使用。然后熟悉 EventBridge 的事件模式匹配，这是一个比较关键的特性。熟悉 EventBridge 的事件转化的配置。这是一个很重要特性。这里有一个例子，只要拷贝一小段就可以使用阿里 cloudprovider。因为在其他的文件里面已经定义了这个内容，所以这里需要提供的是 access 的三项，就可以开始操作，利用阿里账号的 aSK 可以操作流量资源。其他第一组就能删掉。这里的定义的描述文件主要是一个 rule。因为这里需要注意的是这次操作的事件是阿里云上的 action trail 的事件。回到控制台页面，先看一下这个事件特点。

在 default 事件总线上所有阿里云的事件都会在 default 总线上提供事件源。其中有一些设计的类型。然后再看其他的事件源，的其他的云产品同样也有 action trail 这件事件。action trail 提供了对所有云上的资源的操作审计的能力。可以利用这个特性来发现所有账号内对资源进行操作的事件，把它通知到钉钉。这个要具体怎么做呢？在 default 总线上看到只需要定一个 rule。因为有一个默认 default 总线，直接写上填写它的 bus name，叫default。然后定义这个资源的类型叫 EventBridge rule。起一个名字叫 ordinary define。这面主要注意的是需要通过这个 filter pattern,也就是事件的模式匹配去把 default 总线上所有的 action trail 事件过滤出来。刚才能看到所有的 action trail 相关的审计事件虽然它们的 source 来源不同，但是他们的后缀都是 action trail。以这个为例，通过后缀匹配的方式。事件的模式匹配有很多种，这里 EventBridge 官方文档都有详细的介绍。这些功能都是很灵活强大，而且使用简单，这里使用后缀匹配的方式。只需要提供一个就可以自动匹配到所有相关的所需要的事件。配置好了后缀匹配的模式之后再需要看target。target需要投递到钉钉，这里指定的 type 是 acs ding talk，target 可以在官方文档上面查到详细的信息，如果不确定也可以在 telphone 里面查找。在rule 的栏目里面，可以看到 targets。然后可以看到所需要填写的字段名称 prime list是一个参数列表。已经能够支持通过 telphone 配置的 target 都列在这里，其中包含了 acs ding talk 钉钉。然后相关相因为每个target的类型不同，那么它的参数列表也就不同。还需要关注它的参数列表，具体包含的内容,在这里有一个链接可以指向 EventBridge 官方文档。在这里可以查到钉钉的参数列表主要包含这一类。包括 url。这是用来做钉钉通知的机器人的 web hook，发送的消息内容。这里有一个举例。回到代码里面。根据官方文档的描述内容，现在已经填好了end point，即 web hook 的 url。给它取了个名字叫 test target。它所需要的参数已经罗列在这里。看一下怎么填写。

URL 是一个指定的固定的字符串，这个 form，它的形式是一个常量，value 直接填了一个字的常量进来。第二个参数是 secret key。它也是一个常量，刚才看到文档里介绍了一个 secret key，也把它填在这里。第三个是 body。这里就利用了模板的能力做了事件转换。The forms your template。其实是 value 构造了一个字典。在这个里面用 json 的格式，所以这里需要注意用 Jasonco包含的是对字典的描述，它的 key 就是生成的字典的一个 key，那它的 value，是 Jason pass。直接引用了一个事件，收到事件的字段。Source 引用的是 dollar.source，type 引用的是 dollar.type。分别指向 source 和 type。内容分别是后面这三个相关的事件里面包含的字段内容。这里可以看到是data 指的一个 identity count 是指的这个 count 还有事件内容。接下来是真正文本内容模板，这里也需要一个 jason 的格式，这是钉钉的 target 所要求的格式。这两个字都是固定的，然后 text 内容，content 里面的这部分才是要自定义去填写的内容。其他的这部分都是固定的格式，这里构造了一个字符串。需要注意的是这里有两个 dollar，其实在 telphone 的语法里面做了转移，因为如果只用一个dollar，会被识别为 telphone，这个 HCL 就是它自身的一个变量引用，所以需要用 double dollar 转译一下。这样实际的效果就相当于引用了前面所定义的字典里面的某个变量。接下来看一下要怎么去把它部署到 EventBridge 上。假设已经安装好了，这个时候一步操作。在这里看到 dot.telphone 的目录被创建出来了。还有相应的一个 love.excel。到现在已经完成了要部署的一般要先 plan 一下Telphone 的 plan 是提供了对整个资源的预览，就方便去 rview 将要产生的一些变更。这里可以看到 plan six to app 有六个资源将被创建。下一个案例。看有一个资源将被创建，这一个资源是要从 default 总线上面，把的 action trail 的一些事件路由到钉钉上的路。看来没有问题，直接部署。输入 yes 去确认操作。现在部署已经完成，看一下控制台。回到杭州的。现在应该是在杭州操作的。这里已经创建了。然后看一下这里就是刚才填写的一些变量的内容和模板内容。这是匹配的事件的模式，成功部署进来了。接下来有了这个 rule 之后，应该怎么触发它产生一些事件，才能看到钉钉上的通知效果？这是提前准备好的，一名钉钉通知机器人。现在去 kms 上创建一个凭据。随便创建一个凭据。现在凭据创立成功。应该可以看到，再来通过事件追踪来确认一下。这里好像已经拿到了事件。这里的事件应该是一次 api call。所以是不是应该改一下？重新部署，把它这个事件改成api call。事件轨迹可以看到什么东西都没有。目前还没有投递。所以需要再处理，再创建一次。现在也看到了，第二个事件已经产生了。钉钉上面已经得到通知。Sac审计事件，这个账号在杭州执行了操作。

这个案例最近是什么？通过事件轨迹，也可以清楚看到事件命中了 orditanary。然后投递到的事件目标就是刚才配置的 web hook 的地址，然后显示投递的结果是成功。再来看一下第二个案例。这些都注视掉了。第二个案例相对而言会复杂一点，第二个案例是要演示通过自定总线触发function的一次调用目标，熟悉部署使用event bridge 自定义线对于刚才不同的是，刚才使用的是默认存在底线。这里创建一个新的自定义总线。然后熟悉自定义应用的事件配置，熟悉发生的事件目标配置。接下来也可以分步骤来操作，先将其他的资源不使用。我们要创建一个自定义总线是非常简单的，只需要用provider提供的资源类型，给他一个名字，叫 demo evenbus。相应的还有一个source，source也比较简单，因为是自定应用的 source 事件源，所以它没有什么特殊的配置，只是需要提供一个名字。提供一个自定义，提供一个它所创建关联的一个总线。现在正好把它创建这里描述的这个自定义总线上。然后再提供 description。填 faulse 的时候就是自定义应用了。这样我们就会创建一个自定的 bus，加上一个自定义应用的source。看一下项目。然后现在有两个资源需要添加。再回到刚才的总线列表。事件总线里看到多了一个 demo 这就是刚刚创建出来的总线。在查看事件源可以看到，刚刚又创建了一个事件源，事件源的类型是自定义应用。自定义应用其实并不是关联到具体资源需要用户通过 sdk 自己去通调用的 api 传进来复合事件就可以了。这个仅仅是用做演示，所以用了这样一个简单自定义应用。接下来要关联要创建相应的一个 target 资源，就是 FC 的一些资源。这里也可以通过查阅里面的文档可以得到通过创建一个fc的 service 和 fc 的 function 来通过 telphone 自动的部署一个 function，同时这里在创建 function 的同时，提供了function 所执行的代码的源文件。在这里写了一个很简单的 demo，一个 paython 的脚本。打个日志把 event 原本的输出来。这里借助 telphone 的 file 这样一类资源的能力。把 python 脚本文件打包成 code.z，因为一个 rule 就需要传递一个Z文件的路径，直接引用这个 data.code。指定了这个文件所在的路径，那么在 apply 的时候，这个资源就会把这些源代码直接上传。把 function 给部署出去。这时也可以看一下效果。应该是又有两个资源要添加 data 这个不算是资源 data 是对内容的只读的操作与 soure 是资源，所以创建了一个 service 的一个方式。服务里面多了 ESF service 这是刚刚创建的一个 FC 的 service。里面又创建了一个 function。这就是刚刚在本地所编辑的代码文件。接下来看一下怎么配置，把 fc 的 function 作为一个 target。这里还是通过一个 rule。在 rule 里面，因为指定的 source 是自定义的s ource，所以需要引用前面创建好的 Source 资源，把它的 ID 填在这里作为 source 来过滤。这是对 field patter 的写法。用这个含义是指过滤字匹配上，这个 id 的所有事件。

那下来就是 target 内容。FC 的 target 销量并没有包含复杂的转换基本上都是常量。主要是需要在这里去做，对它的 enpoint 做一个拼装。那这里要把自己的 region id 账号，还有 service name 版本号。用 function 这个放在这里相应的这些参数其实又是把上面的一些变量又再填写了一遍。这里要填一个常量的，直接引用 telphone 描述里面的文本就可以，这个变量就可以。方式内容也是一样，直接可以引用D fc方式的内容.然后另外这个其实就指的版本，这里都有同一天 latest 最新的版本，body 是要传递的事件内容，original form 表达的是会把这个事件原封不动地传递给function。Rule 也需要指定 bus。要在刚刚创建的自定义 bus 总线上生效，所以要指定 bus 的名字。通过引用的方式，接下来在创建这个资源，app，创建好了。总线上多了一个规则叫 demorule。服务类型是函数计算。变量都已经填写好了。Source 已经被替换为添加自定义 source 的名称。现在填写的是最简化的一些配置。有很多高级的功能没有开启，比如服务的一些日志都还没有打开。所以想要观察这个函数调用是否成功，可以一键启用日志。可以验证这条路是不是已经顺畅。在这个 rule 里面，可以去控制台里模拟发布一个事件。这个与用户使用 sdk 是调用 event bridge 是完全等效的。在这里要模拟的这个事件源是这个 demo event source。看下日志已经开启了。日志已经开启了。这里直接模拟调用一下。事件发布成功。可以返回到事件追踪，再看一下刚刚发生的事件，事件源过滤一下。这个事件类型叫 ui create post object。