[肥用云计算] Serverless Trigger使用 [第2章]

之前的走马观花后，在后续的章节分开不同方面去看 **Serverless**。本文主要集中在 **trigger** 层面来细看一下。

PS，我们会主要在 阿里云 的环境中 使用 serverless 开发者工具 – yaml 模式 的方式进行开发部署，同时在 web界面 中进行检查。同样的， 在 web界面 也可以进行开发。使用 devTool yaml 是为了更加的直观的看到每个的组件的关系，同时对 yaml文件可以进行版本管理。代码参考请看。

概述

从前文知道，Serverless 的其中一大优势，就是可以 快速的部署业务。同时他也有另外一个优势，就是 业务主体 和 触发器 进行解耦合。

比如，传统的 web http 服务器开发应用，都是监听80端口，访问端口后才触发做业务；Serverless 会将 业务逻辑 和 80端口http访问 两部分给解耦了。Serverless 可以分开来两部分进行编写。

业务逻辑，专注于写业务就可以了；触发逻辑，有可能是 http、定时器、MQ 消息等触发器触发，是所有业务逻辑的入口。

🦄 有点是事件驱动的内味。

Trigger 就是 Serverless 的入口。
Trigger 种类有两种，一种是 Http Trigger，一种是 Event Trigger。下面分开两种分别细看。

例子

http trigger

前文中已经有 http trigger 的例子，这里就直接引用。

示例目的：响应 http 80 的请求。

# 直接使用模板来创建 serverless
s init start-fc-http-nodejs14 -d start-fc-http-nodejs14

? 地域 cn-shenzhen
服务名称，只能包含字母、数字、下划线和中划线。不能以数字、中划线开头。长度在 1-128 之间
? 服务名 test02
# 全部都选 【test02】
? 函数名 http01
? please select credential alias default
# 选择之前的密钥的 alias

修改返回值。

// 代码片段
// 改代码 index.js，返回 hello  world
// resp.send(JSON.stringify(params, null, '    '));
resp.send(JSON.stringify({body: "hello world"}));

s deploy 重新部署后，访问链接，验证成功，符合预期。

oss trigger

示例目的：响应 oss 创建文件请求。设计一个 oss trigger，如果文件上传到 uploads 的文件夹后，自动就把文件复制到 相同的bucket 的 copys 文件夹中。

# 直接使用模板来创建 serverless
s init start-fc-event-nodejs14 -d start-fc-event-nodejs14

? 地域 cn-shenzhen
服务名称，只能包含字母、数字、下划线和中划线。不能以数字、中划线开头。长度在 1-128 之间
? 服务名 test02
# 全部都选 【test02】
? 函数名 oss01
? please select credential alias default
# 选择之前的密钥的 alias

但是模板 s.yaml 是没有 trigger 的配置，所以需要我们补充上去。

🦄 Event trigger 比较复杂，建议可以在 web界面 先配置后，导出 s.yaml 文件，把 trigger信息再补充到原文件中。

      # 下面是 s.yaml 的代码片段
      service: ${vars.service}
      function:
        name: "oss01"
        description: 'hello world by serverless devs'
        runtime: nodejs14
        codeUri: ./code
        handler: index.handler
        memorySize: 128
        timeout: 60
        # 下面是补充的信息
      triggers:
        - name: oss-trigger01
          description: ''
          # 1719759326012690 是主账户ID，zhangyihengfctest 是 bucket 的名字；
          sourceArn: acs:oss:cn-shenzhen:1719759326012690:zhangyihengfctest
          type: oss
          # role AliyunOssEventNotificationRole 的 ARN 信息
          role: acs:ram::1719759326012690:role/aliyunosseventnotificationrole
          qualifier: LATEST
          config:
            events:
            # oss 创建一个文件的事件
              - oss:ObjectCreated:PostObject
            filter:
              key:
                # 前置文件夹
                prefix: uploads
                suffix: ''

说明请看注释。

前置条件 : 记得先授权给角色

ARN： aliyun resource name 的简称，简明的意思就是 资源在阿里云体系下的唯一ID。

s deploy 部署后，在对应的 bucket 的 uploads文件夹 上传文件，检查 log，打印了hello world。符合预期，因为模板就是响应事件并打印 hello world。

再次修改代码，实现文件上传到 uploads 文件夹后就可以 复制到 copys 文件夹。
截取代码的片段，详情请看 gitee。

let objectBuffer = await getBuffer(client, objectName);
// 将文件buffer进行备份到OSS中
await putBuffer(client, objectBuffer, 'copys/' + newObjectName)

修改完成，重新 s deploy 部署一下。

验证结果，上传文件，从 FC 的函数日志检查，发现可以打印 ossObject 的信息。

从 OSS 文件浏览器检查。uploads 文件夹的刚上传的文件。

copys 文件夹里面的，已经被复制过来的文件。

符合预期。

🦄 这个 trigger，可以应用在上传文件后需要进一步处理的逻辑，就显得很丝滑。比如上传文件后进行转码等。

检查其他的 trigger

进入了 创建触发器 的创建界面，可以看到有很多不同类型的触发器。
比如常规的触发器，定时、OSS、日志等。

还有就是 MQ 事件触发器。

另外，还有各种的云产品的事件触发。下图是 ECS服务器的各种的事件触发。

🦄 所以云计算厂商想拥抱 Serverless，就是需要把自己的产品都能提供 Serverless的触发和调用；但是同时，开发者如果业务强依赖于 Serverless，就有可能是给绑定在某个云计算厂商中，有一定的风险。

总结

Trigger 是所有 Serverless 的入口，他分了 Http 和 Event 两种不同的类型。
在编写 Serverless，一定保持 做业务逻辑和触发器逻辑 相隔离，让业务逻辑灵活、内聚、低耦合。