FC web api与传统web api的对比

可用资源

FC web api的web server只是一个接入层,计算层对接的是云厂商的FC运行时环境,可用资源受FC配额的限制,目前阿里云FC的默认配额是最高100个并发。另外,有一点需要注意的是,如果是计算密集型的功能,一定要将内存配额至少设为2G,这样才能保证可以用满一个核的算力。

传统web api的计算是直接在web server上完成,可用资源受web server所在云主机的限制。

运行环境

FC web api所对应的每一个method(FC)都可以有单独的运行环境,可以单独配置不同的软件依赖,也可以使用不同的技术栈。

传统web api的所有method都是在同一个环境里运行,远不如FC轻便灵活。

使用成本

FC web api仅需api网关常驻,后端对接的FC都是按每个FC的具体配额按0.1s的使用时间粒度收费。

传统web api的所有功能代码都需要常驻,即使无人调用,也要占用资源。

响应时间

FC web api经api网关触发FC(如果是自建web server作为api网关,需要调用sdk触发;如果是使用阿里云API网关服务,需要将函数配置为HTTP触发),这一步有几毫秒的时间消耗,另外,当FC容器需要冷启动时,响应时间会大大增加,冷启动时间由函数镜像大小和初始化函数的耗费时间决定。

传统web api由于是常驻进程,没有网关触发FC的时间消耗及有可能遇到的冷启动等待,响应时间在一般情况下要优于FC web api,除非请求数量太多导致服务出现拥塞。

适用场景

FC web api适用于处理实时性要求不高的,较低频的请求。如上所述,FC的触发机制决定了响应时间可能存在一个较大范围的波动。另外,当FC被web api高频触发时,还存在到达资源配额上限(并发容器达到100个)导致其他FC无法正常运行的风险。例如,我们的web service是通过FC web api实现的,同时,监控该服务的告警发送动作也通过FC完成。那么,有可能当大流量涌入,FC资源被拉满,服务质量严重下降时,却会由于资源配额耗光的原因无法推送告警。

传统web api适用于处理要求实时性的高频请求。

上一篇:eslint使用心得


下一篇:记一次从Rails至Golang的接口迁移