试用 Cloud Run

一段时间以来，我们一直在探索将部分工作负载迁移到无服务器基础设施。起初，我们将 AWS Lambda 视为首选方案，但 Cloud Run 对容器的开箱即用支持是一个颇具吸引力的选择，因为它降低了迁移现有容器的成本。

起初，我们考虑先迁移非静态网站，以下是我们在使用过程中的心得，以及我们认为它尚未成熟到可以投入正式使用的原因。

迁移工作负载

如果您的容器已经存储在 GCR 上，设置 Cloud Run 非常简单。代码需要进行调整，以监听 Cloud Run 设置的 $PORT。结果这比预想的要复杂，因为我们使用的是 Nginx，而它的配置文件不支持环境变量。

可选方案有两种：一是使用 LUA 或 PERL 等脚本语言，根据环境变量创建 Nginx 变量；二是使用 envsubst 转换配置模板，替换其中的环境变量值。

加密流量

Cloud Run 的一个明显优势是，您不再需要配置 TLS/SSL 端点，因为 Cloud Run 会负责处理。

这提高了安全性，因为您不再需要紧跟 TLS 设置的最佳实践、决定支持哪些协议等等。但这也减少了您的灵活性，因为您可能希望采用严格的策略，或者需要支持旧版浏览器。

在这些情况下，托管式且无法配置的 TLS 设置就是一个大问题。

连接外部服务

服务启动并运行后，一直报告 SQL 数据库连接错误。出乎我们意料的是，Cloud Run 仅支持连接 Google 内部服务。不支持连接未在 GCP 上运行的数据库。

这也限制了 Cloud Run 在若干需要出站连接的使用场景中的实用性。如果您确实需要出站连接，可以在专用的 GKE 上运行 Cloud Run，但其设置过于复杂，文档也不清晰，我们干脆放弃了。

为了继续测试，我们最终使用 Cloud SQL 在 GCP 上搭建了数据库。不过，SQL 连接是通过挂载到容器 /cloudsql/ 下的套接字文件完成的。

这一设置同样需要修改代码，但非常简单，真正“有趣”的是处理 IAM 策略错误和缺失的 API。这个过程并不愉快，但一旦搞定，复用同一个服务账号连接数据库就无需额外操作，而且显然更加安全。

扩展性

Cloud Run 设置完成、数据库连接正常之后，关键时刻到来了：它的扩展能力和性能究竟如何。

向该服务发起数千个连接时，它表现出色，达到了 1k QPS，峰值达到 1.6k QPS。

扩展性令人惊喜，而且开箱即用；如果数据库资源配置不足，您可能会遇到数据库瓶颈。

延迟

遗憾的是，延迟成了决定性的障碍。对于我们的网站而言，保持相对较低的延迟对于提供良好的用户体验非常重要。

我们当前的延迟平均在 40 ms 到 2000ms 之间，第 95 百分位为 3000 ms。

Cloud Run 的延迟则糟糕透顶，达到 4000ms 到 8000ms。冷启动之后可以看到延迟有所下降，但即便如此，其数值仍然很高，在 600ms 到 4000ms 之间，并且经常再次飙升至 8000ms。

结论

Cloud Run 看起来非常有前景，而且由于开箱即用地支持容器，显然拥有巨大潜力。它与 Cloud Build 的集成似乎也是自动化部署的一大加分项。

不支持出站连接限制了它的实用性和集成场景，我推测这样做是为了防止该服务被滥用于发动 DDoS 攻击。

虽然其扩展数据令人印象深刻，但延迟问题非常严重，这限制了它在运行网站甚至 API 方面的实用性。

只要不需要出站连接，将该服务用于对延迟不敏感的工作仍然是一个可选方案。