2 min read
初窥 GCP Serverless 产品

最近似乎 Serverless 又有点冷清下来了,也挺久没关注了,看四月份 GCP 发布的 Cloud Run 所以来看看 Cloud Run 和 Cloud Functions 大体区别吧

Serverless

Serverless 现在业界似乎比较公认的定义是:开发人员无需关注支撑架构,即为无需关注底层架构,只需关注业务开发逻辑及业务自身可用性即可。但初期大多数人都认为 Serverless == Function as a Service,然并不全是。我理解是:只要用户不需要关心「Server」那么就是「Serverless」。当前,因为 Serverless 的存在,所以决定了应用是无状态的。早起的 Serverless 发展多以 FaaS 方向延伸(本文接下来要介绍的 Google Cloud Functions 就是 FaaS),FaaS 大多是以提供 Runtime 支持而用户的代码类似于 plugin 的形式存在,当触发时装入,完成时卸载。

但 FaaS 其实也有些诟病,例如说:并非所有应用都可以拆成一个个函数,亦或者会带来巨大的维护成本;函数的编写使用受限于平台提供的 Runtime;无法编写过于复杂或者有额外 lib 依赖的函数等等。今年 4 月 GCP 推出了 Cloud Run,我个人认为这是一个比较不错的解决方案。它一定程度上解决了上述乃至更多 FaaS 的痛点。

Cloud Functions 与 Cloud Run 对比

对比项Google Cloud FunctionsGoogle Cloud Run
RuntimeNode.js(Node.js 6、8 或 10)、Python 3(Python 3.7) 或 Go(Go 1.11)任意你想要的都可以有
事件与触发HTTP、Cloud Storage、Cloud Pub/Sub,Cloud Firestore、Firebase、Stackdriver Logging,Cloud SchedulerHTTP、Cloud Pub/Sub、Cloud Scheduler
并发一个实例处理一个请求支持多个请求并发
存储不提供本地存储持久化,如果需要可以用 GCS 或者其他云存储服务,本地文件系统会存入内存中计费
自动扩缩容来一个请求,起一个实例根据并发、处理耗时动态扩缩容

在体验过两个产品后,我个人会更倾向于 Cloud Run 的模式(Instance as a Service?)它能够提供更少阻力的业务开发条件(没有固定 Runtime),并且再高并发情况下能够一定程度上减少成本消耗,一定程度上避免了 FaaS 模式的冷启动带来的性能延迟。

并发与实例数

当 Cloud Run 服务并发设置 1 的时候,他的实例数与请求关系等同于 FaaS 模式。

concurrency

以下图表,绿色线代表请求量(QPS),蓝色的线代表实例数

当 400 施压实例(每个实例 3 QPS)打到并发数为 1 的 Cloud Run 服务上效果如下:

bench-con1

当同样的压力施加到 80 并发的 Cloud Run 服务上效果如下:

bench-con80

在不考虑计费差异的情况下,Cloud Run 的实例数更少(当然,规格可能也会相对大一些,但总资源消耗预期是更少的)

关于 Cloud Run 的 Autoscaling 可见 knative-serving-scaling

REF