背景

最近打算用阿里云的 FaaS，也就是函数计算 FC（以下简称 FC），实现每天 15 点爬取可转债数据的功能。简单任务，用 FC 自带的「定时触发器」就可以了。

但是，我的需求，需要串行调用 A、B、C 三个函数 ，前者的输出是后者的输入。这就不能简单的用 FC 了，于是需要云工作流 CloudFlow 把多个 FC 串联起来。

但是，之前的 FC 用的 2.0 写的，只能在 HTTP 场景下运行，也就是只能通过网络调用。现在需要兼容 CloudFlow 场景了。这时候升级到了 FC 3.0，发现入参有了变化，于是做了一些实验，研究了一下 event 的结构，整理成了本文。

正文

首先，建了一个简单的 Demo 函数，用来在日志里面查看 event 的结构：

js 复制代码

'use strict';

exports.handler = (event, context, callback) => {
  const eventStr = event.toString();
  console.log('eventStr', typeof eventStr, eventStr);
  const eventObj = JSON.parse(eventStr);
  console.log('eventObj', typeof eventObj, eventObj);
  callback(null, JSON.stringify(eventObj));
}

然后用各种方式访问上面的 FC，记录下结构。

HTTP 场景

给 Demo FC 配上 HTTP 的触发器，然后用 postman 发请求，我们来看一下结构。

postman 的入参：

markdown 复制代码

- params
  - paramsKey: 1
- body
  - '{ "bodyKey": 1 }'

Demo 打印出的 eventObj：

json 复制代码

{
  "version": "v1",
  "rawPath": "/",
  "headers": {
    "Accept": "*/*",
    "Accept-Encoding": "gzip, deflate, br",
    "Connection": "keep-alive",
    "Content-Length": "20",
    "Content-Type": "application/json",
    "Postman-Token": "749739a9-0295-4abb-b76f-2ecad5999db7",
    "User-Agent": "PostmanRuntime/7.36.1"
  },
  "queryParameters": {
    "paramsKey": "1"
  },
  "body": "{\n    \"bodyKey\": 1\n}",
  "isBase64Encoded": false,
  "requestContext": {
    "accountId": "1566720208628252",
    "domainName": "cloud-flow-demo-mqsioywpgk.cn-hangzhou.fcapp.run",
    "domainPrefix": "cloud-flow-demo-mqsioywpgk",
    "requestId": "1-65fad067-15e29182-4264ae9b2a34",
    "time": "2024-03-20T12:02:47Z",
    "timeEpoch": "1710936167477",
    "http": {
      "method": "POST",
      "path": "/",
      "protocol": "HTTP/1.1",
      "sourceIp": "114.251.196.102",
      "userAgent": "PostmanRuntime/7.36.1"
    }
  }
}

可以看到，挺复杂的。

CloudFlow - InvokeFunction 场景

流程初始入参：

json 复制代码

{ "key": "hello world" }

InvokeFunction Payload 配置：

注意：如果不配 Payload，event.toString() === ""，JSON.parse 会报错。

这时候，调用 Demo FC 的时候，入参会是：

json 复制代码

{
  "key3": 100,
  "key2": "hello world"
}

动态的取到了 InvokeFunction 节点的输入（$Input.key），经过上面 Payload 的配置处理之后，转换成了 Demo FC 的入参。调用之后的返回是这样：

json 复制代码

{
  "Header": {
    "x-fc-instance-id": "c-65fad0f3-15416274-c3df2a8aeee0",
    "content-type": "application/octet-stream",
    "x-fc-invocation-function-version": "LATEST",
    "x-fc-request-id": "1-65fad1e1-15a00cff-43f88375f4fd",
    "x-fc-max-memory-usage": "9.23",
    "access-control-expose-headers": "Date,x-fc-request-id,x-fc-error-type,x-fc-code-checksum,x-fc-invocation-duration,x-fc-max-memory-usage,x-fc-log-result,x-fc-invocation-code-version,x-fc-instance-id",
    "x-fc-invocation-duration": "53",
    "date": "Wed, 20 Mar 2024 12:09:05 GMT",
    "content-length": "33",
    "x-fc-code-checksum": "18316564080745679094"
  },
  "Body": {
    "key2": "hello world",
    "key3": 100
  }
}

可以看到，FC 的返回值被放到了 Body 上，如果返回值符合 JSON 格式，它会自动转换成 Object。如果是一般 string，那就是 string 了。

所以，如果你只想把 FC 真实的返回值，原本的输出，并作为下一个节点的输入，需要配置一下它的输出格式：

这样下一个节点接收到的入参就是纯 JSON 了。所以，如果想在 CloudFlow 里使用 InvokeFunction，都需要进行下面的步骤：

配置 Payload 格式；
配置输出格式为 $Output.Body；
重复 1、2。

总结

这篇很抽象，要是没有深度使用 FC 和 CloudFlow 的同学估计会满头雾水，实在是缺少上下文。没关系，这篇文章本来就是为了后面做铺垫的。等后面有具体场景的文章出来，再回头看这篇，就不一样了。

FC 3.0 的升级的确有更高视野的考虑，FC 不再是仅为 HTTP 场景服务，而是可以为多种场景服务了，特别是 CloudFlow，这基本上就是实现低代码开发了。可以用 CloudFlow 编排逻辑，调用各种 FC，理论上可以完成绝大多数功能。关键是特别便宜，真香~~

最近要搞证券这方面的研究，估计 CloudFlow + FC 的组合可以帮的上不少忙，搞起。

阿里云函数计算 FC 3.0 Event 结构

背景

正文

HTTP 场景

CloudFlow - InvokeFunction 场景

总结