SDK 和 Serverless Devs 工具来进行 HTTP

当前阿里云函数计算支持两种类型的函数：事件函数和 HTTP 函数。其中 HTTP 函数结合 HTTP 触发器，能够支持用户直接通过 HTTP 请求利用 Restful API 的方式发起函数调用；
通过这种方式，用户无需集成函数计算提供的 SDK 就能实现函数调用，更好地同已有系统的组件及 Web 服务进行集成。
考虑到 HTTP 函数最初设计的目的，面向 Web 场景，HTTP 函数并未支持异步调用，随着用户使用 HTTP 函数的场景增加，HTTP 函数无法支持异步调用的限制，对于用户更广泛的使用 HTTP 函数带来了诸多的限制。
不支持异步调用，用户有多难？
目前，已经有很多客户使用函数计算 HTTP 触发器搭建 WEB 服务，其中很多人有通过 Web 服务进行文件 （视频、图片等） 处理转码，投递任务，进行压测的需求。
这些需求则往往具有长执行，流量不均匀等特性。具有这些特征的函数在同步执行的场景下有以下缺点：
1、长执行函数增加函数错误的风险，提升机器开销。
• 客户端需要保持长链接，网络波动、客户由于函数执行耗时较长失去耐心自主断开链接等，都增加了函数错误发生的机率。
场景：视频网站用户上传视频转码，耗时长刷新页面导致链接中断，转码失败。
• 保持长链接增加了客户端的机器开销，降低了客户端机器资源的利用率。
2、面对突增流量无法平滑处理和接收。
• 对于有并发限制的场景，客户的突增流量在同步调用的场景下会被限流，从而在客户不做错误处理的时候造成一定请求失败。
场景1：脉冲式压测场景。
场景2：限时线上促销活动。
在这些场景下，客户可以通过异步调用将 HTTP 触发和函数执行进行解耦，提升执行效率和执行成功率，降低开销。
异步调用 at least once 的保证， 目标投递的能力，以及具有可观测性和可管控能力的异步任务模式能更好地让客户享受到函数托管服务的便利，解放客户双手。
HTTP 触发器不支持异步调用时，为了满足需求，客户往往需要通过函数转跳的方式间接实现 HTTP 触发异步调用。具体流程如下：
客户可以创建两个函数，函数 A 为 HTTP 函数，通过 HTTP 同步调用；函数 B 为事件函数，可以由 HTTP 函数通过 SDK 进行异步调用。但是该方案的缺点也很明显：
• 成本高：每次异步调用都需要两次触发。
• 无法实现流控全托管：第一层函数为同步调用，面对突增流量被流控，需要客户自行做自适应，从而无法享受异步调用的流控全托管。
• 增加客户开发维护成本：需要开发和维护两个函数来使用异步功能。
新功能：HTTP 触发器支持异步调用
函数计算当前上线支持了 HTTP 触发器进行异步调用的功能。使用本功能，客户需要准备好一个 HTTP 函数和一个 HTTP 触发器。
客户可以通过函数计算控制台、SDK 和 Serverless Devs 工具来进行 HTTP 函数和触发器的创建。HTTP 触发器客户可以自行配置，如果不进行配置，在创建 HTTP 函数的时候，函数计算会为您自动创建一个默认触发器。