如何选择计算服务？

在上一节课中，我们学习了如何配置 SDK 命令行工具（CLI），以及如何使用不同的命令通过 Cloud SDK 与 GCP 环境进行交互。

本节课的重点是：如何为我们的具体应用场景或特定工作负载选择合适的 GCP 计算服务。当前主要的计算服务包括：

• Compute Engine
• Google Kubernetes Engine（GKE）
• App Engine
• Cloud Run
• Cloud Functions
• VMware Engine

其中，VMware Engine 不在本次考试范围之内。

回顾计算服务选项

计算、存储和网络是云计算的三大核心支柱。

针对“计算”需求，GCP 提供了多种服务选项。如何判断自己选择了最适合当前场景的服务？实际上，每种计算服务都是为解决特定类型的问题而设计的。因此，关键在于明确你的核心需求，并将其与各项计算服务的特性相匹配。

下面我们来逐一了解这些选项。

计算服务可根据两个主要维度进行分类：

• X 轴表示运维管理程度：即你需要自行管理的操作任务有多少， versus 由 Google 代为管理的部分。“完全”表示你需要承担大部分运维工作；“无”则代表服务完全由 GCP 托管。

• Y 轴表示适用的工作负载类型：“完全”意味着该服务可支持任意类型的应用场景；“有限”则指仅适用于特定用途。

App Engine 的使用场景

App Engine 是一个全托管平台，适用于部署基于 Web 的应用和移动后端服务。之所以将其归类为“有限工作负载”，是因为它仅支持通过 HTTP 协议通信的应用程序，且只支持特定编程语言——若需使用其他语言，必须通过 Docker 构建自定义运行时环境。

当你符合以下情况时，应考虑使用 App Engine：

• 不希望处理底层运维事务，只想专注于开发。
• 不关心操作系统细节。
• 需要在多个地理区域实现应用程序的高可用性。
• 不需要应用具备跨平台迁移能力（即不关注应用可移植性）。
• 应用程序通过 HTTP 进行通信。

Cloud Functions 的使用场景

Cloud Functions 是一种事件触发式代码执行服务。当某个事件发生时，相关代码会被自动执行。正因如此，它的适用场景比 App Engine 更加灵活，因此在工作负载轴上的位置更靠下（表示灵活性更高）。

适合在以下情况下使用 Cloud Functions：

• 希望在某个事件触发后执行特定操作。例如：当用户上传图片时，自动压缩图片并保存到云存储中。
• 使用 JavaScript、Go、Python 3 或 Java 进行开发。
• 不关心底层操作系统。
• 功能具有时间限制：单次函数执行最长不超过 540 秒（9 分钟）。

GKE 的使用场景

Google Kubernetes Engine（GKE）是 Google 提供的托管式 Kubernetes 服务。只要工作负载已容器化，GKE 就能运行各种类型的应用。虽然你无需管理操作系统等底层配置，但仍需定义集群及其运维策略。

当你满足以下条件时，应选择 GKE：

• 工作负载已经容器化。
• 关注点集中在容器管理上。
• 需要良好的可移植性，以便未来迁移到其他云服务商。
• 将容器视为基本的部署单元。

Cloud Run 的使用场景

Cloud Run 是基于 GKE 的全托管服务，其使用场景与 GKE 类似，但更适合以下情况：

• 不关心跨云平台的可移植性。
• 希望由 Google 自动管理集群的创建和维护。
• 工作负载已容器化。
• 希望尽可能降低费用（例如，在特定美国区域每月前 200 万次请求免费）。
• 要求应用程序具备高可用性。
• 不关心底层操作系统或网络配置。

Compute Engine 的使用场景

最后介绍的是 Compute Engine，它适用于几乎所有类型的工作负载，性能强大，并提供对操作系统的直接访问权限。但正如一句名言所说：“能力越大，责任越大。”

当你遇到以下情况时，应选择 Compute Engine：

• 需要对 CPU、GPU、内存、操作系统、存储、网络等底层资源进行精细控制，就像配置一台物理服务器一样。
• 想将现有应用不做修改地直接迁移上云（即“原样迁移”lift and shift）。
• 工作负载未容器化。
• 需要执行批量处理任务，并使用生命周期较短的计算实例（如抢占式实例）。

关于抢占式计算实例，我们将在下一节课中详细介绍。现在，你可以先在主菜单的“计算（Compute）”部分探索各类计算服务选项。

下一节课中，我们将学习短生命周期实例和自定义实例的实际应用。