初窥 GCP Serverless 产品
· 2 min read
最近似乎 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 Functions | Google Cloud Run |
|---|---|---|
| Runtime | Node.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 Scheduler | HTTP、Cloud Pub/Sub、Cloud Scheduler |
| 并发 | 一个实例处理一个请求 | 支持多个请求并发 |
| 存储 | 不提供本地存储持久化，如果需要可以用 GCS 或者其他云存储服务，本地文件系统会存入内存中计费 | |
| 自动扩缩容 | 来一个请求，起一个实例 | 根据并发、处理耗时动态扩缩容 |
在体验过两个产品后，我个人会更倾向于 Cloud Run 的模式（Instance as a Service？）它能够提供更少阻力的业务开发条件（没有固定 Runtime），并且再高并发情况下能够一定程度上减少成本消耗，一定程度上避免了 FaaS 模式的冷启动带来的性能延迟。
并发与实例数
当 Cloud Run 服务并发设置 1 的时候，他的实例数与请求关系等同于 FaaS 模式。
以下图表，绿色线代表请求量（QPS），蓝色的线代表实例数
当 400 施压实例（每个实例 3 QPS）打到并发数为 1 的 Cloud Run 服务上效果如下：
当同样的压力施加到 80 并发的 Cloud Run 服务上效果如下：
在不考虑计费差异的情况下，Cloud Run 的实例数更少（当然，规格可能也会相对大一些，但总资源消耗预期是更少的）
关于 Cloud Run 的 Autoscaling 可见 knative-serving-scaling