在 GCP 上部署 SSR Web 应用程序的正确方法是什么？答案

【问题标题】：What is the proper way to deploy SSR web app on GCP?在 GCP 上部署 SSR Web 应用程序的正确方法是什么？
【发布时间】：2021-02-07 05:27:59
【问题描述】：

起点：我有一个通用 JS 应用程序（基于 Next.js、Nuxt.js、Universal Angular 等构建），我希望它在 GCP 上启动并运行（我认为同样的问题可以参考 AWS ，原理相同）。该应用程序不是“真正的”后端（带有数据库连接、业务逻辑等），它更像是“前端-后端”——它所做的只是前端的 SSR。该应用程序使用 Docker 进行容器化。应用程序应该是生产就绪的（不应该部署在某些 beta 服务上）。

我遇到了 4 个可能的选项：

计算引擎
GKE (Kubernetes)
云跑
应用引擎

接下来的问题是：最适合此应用需求的 GCP 服务是什么？

【问题讨论】：

元素太少。首先，您是否执行处理服务器端？那么，您是否需要全局可用性/缓存支持 (CDN)？您期望的流量配置文件是什么（恒定或尖峰）？冷启动持续时间（从容器启动到第一个请求服务的时间）？有很多参数！尽可能多地分享！
@guillaumeblaquiere 服务器预计只会呈现一些 html 并返回它。后端没有繁重的工作——只有渲染。内容预计将托管在第 3 方（如图像托管在其他地方，只是嵌入了链接）。但是最好缓存请求（不要重新运行渲染）。它也是恒定负载，启动时间尽可能短（所以我不考虑需要预热的云功能）。谢谢！
好的，但是有“处理”。我的意思是你有一个网络服务器来回答端点，生成正确的 HTML 并发送结果。这不是静态 HTML 服务，对吧？为什么 Cloud Function 的启动时间不好？您需要小于 100 毫秒的延迟？
是的，这是正确的 - 有处理，它不是静态 html。据我所知，云功能的冷启动会导致 1-3 秒的延迟。该应用程序应该是高度可用的，并且处理速度尽可能快。您的意思是云功能的 100 毫秒延迟是它们预热的时候？无论如何，您认为 Cloud Function 是正确的方法吗？

标签： google-app-engine kubernetes google-cloud-platform cloud google-compute-engine

【解决方案1】：

我是 Cloud Run 的忠实粉丝，我无法向您推荐另一个最佳地点。但是为什么用文字来表达

Compute Engine：传统服务器，需要自行管理所有无聊的事情（高可用性、备份、补丁/更新/升级）。并且不要扩展到 0。对于 HA，您需要 3 个 VM（至少，在同一个区域中）。相当昂贵。
GKE：与计算引擎非常相似。此外，您还需要具备 K8S 技能。
AppEngine：很棒的解决方案，但不像 Cloud Run 那样可定制。此外，您不能在 App Engine 标准上直接提供容器，只能在 flex 版本、自定义运行时（您不缩放到 0，而是缩放到 1）上提供服务；这里的主要优势是，与 Compute Engine 相比，服务器管理更容易，并且包括本地区域 HA。

对于 Cloud Run、Cloud Function 和 App Engine（具有自动/基本扩展模式的标准版），服务可以扩展为 0。因此，当有请求进来时，服务会启动并需要一段时间才能能够处理请求（大约 300 -> 500 毫秒，除非您使用重型框架，例如 Spring Boot，这需要几秒钟）。

如果这个冷启动有问题，你可以设置一个最小实例来保持一个实例的温暖，从而放弃这个冷启动。

Cloud Functions 无法做到这一点
App Engine，您无需折扣地支付未使用的实例（保持温暖但不提供流量）
使用 Cloud run，当实例空闲时，您支付的实例成本降低 10 倍（90% 的折扣）。

遗憾的是，Cloud Run 上的最小实例仍处于 Beta 阶段（我相信它很快就会在 GA 中推出，但它今天还没有像你说的那样“准备好生产”。

注意：根据我的经验，Beta 版已准备好生产，如果出现问题，您根本没有经济补偿

IMO，我建议您在没有最小实例参数的情况下对 Cloud Run（在 GA 中）进行测试，看看冷启动对您来说是否是一个真正的问题。如果是，你有 beta 参数，但你考虑它时它可能是 GA！

【讨论】：