GCP 优化技巧：从成本到性能的全方位实践指南

Google Cloud Platform（GCP）提供了强大而灵活的基础设施，但如果不加管理，成本可能快速攀升，性能也可能无法达到预期。本教程旨在为初学者和有一定基础的用户提供一套切实可行的优化策略，帮助你在控制开销的同时，确保应用获得卓越的响应速度和稳定性。我们将从成本可视化、资源合理选型、存储与网络优化、自动化运维等多个维度展开。

成本可视化与预算控制

优化始于洞察。只有清楚地知道每一分钱花在哪里，才能精准地“砍”掉不必要的支出。

启用细粒度账单导出

GCP 默认的账单总览只能提供粗略信息。为了深入分析，你需要将详细的使用费数据导出到 BigQuery。

• 操作步骤：在“结算”页面中设置“账单导出”，选择项目和 BigQuery 数据集。
• 优化价值：导出后，你可以使用 SQL 查询按项目、服务、标签、区域甚至每小时粒度分析成本，快速定位费用飙升的源头。

设置预算与提醒

预算不仅能控制总额，更能扮演“警报器”的角色。

• 创建预算：为每个项目或生产、开发环境分别设置预算金额。阈值建议设定为 50%、80%、100%的实际预算，而非 100% 一个点。
• 关联通知：通过 Cloud Monitoring 将预算告警发送到邮件，或通过 Pub/Sub 触发自动响应脚本（如限制非关键服务的资源）。

巧用标签进行成本归因

标签是将资源映射到团队、业务单元或环境的唯一标识。

• 强制标签策略：利用 Organization Policy 要求关键资源（如 VM、GKE 集群）必须添加 environment、team 等标签。
• 标签驱动报告：在 BigQuery 账单数据中，直接按标签 team 分组聚合成本，实现内部透明计费。

计算资源优化

计算实例通常是最大的开销来源。选择错误机型和计费模式会造成大量浪费。

选择合适的机器系列

避免直接选用默认的 n1-standard 机型。

• 通用工作负载：优先测试 E2 系列，它提供动态资源管理，性价比通常比 N1 高出约 30%。
• 计算密集型：使用 C2 或 C2D，它们基于高性能 CPU，适合仿真建模、游戏服务器等。
• 内存密集型：M 系列或 M3 专为超大内存数据库设计，避免为内存需求过多购买计算核心。
• 突发性流量：考虑 Tau T2D 或 E2 共享核心机型，它们允许短时超额使用 CPU，适合开发环境和轻量 Web 应用。

承诺使用折扣（CUD）与抢占式实例

• 承诺使用折扣：对于稳定运行的基础负载（如生产数据库、Kubernetes 节点），购买 1 年或 3 年的承诺可节省 40%~70% 的费用，无需预付。购买后折扣会自动应用于符合条件的用量。
• 抢占式 VM：适合无状态、容错且可中断的工作负载，比如批处理作业、CI/CD 流水线、视频转码。成本仅为标准价的 20%~40%，但 24 小时会自动终止，需要优雅处理中断。

合理调整大小与自动扩缩

多数虚拟机都过度分配了资源。

• 持续分析资源使用：利用 Cloud Monitoring 指标，观察 CPU、内存、磁盘吞吐率在两周内的峰值和均值。若均值长期低于 30%，果断降配。
• 托管实例组（MIG）自动扩缩：对于可水平扩展的应用，将 VM 放入 MIG，启用基于 CPU 使用率或负载均衡请求数的自动扩缩，实现削峰填谷，避免为瞬时高峰预留大量闲置资源。

存储优化

存储费用容易被忽略，但它们随时间累积且持续计费。

对象存储（Cloud Storage）分层与生命周期

• 智能分层：如果数据访问模式不固定，直接启用 Autoclass 功能，它会自动将数据在 Standard、Nearline、Coldline、Archive 之间移动，无需配置复杂规则。
• 主动生命周期管理：定义规则将 30 天未访问的对象下沉到 Nearline，90 天下沉到 Coldline，1 年后归档或删除。同时删除旧版本和非当前版本。
• 缩小归档延迟代价：Nearline、Coldline 和 Archive 检索数据时有毫秒级延迟和每 GB 检索费用，不要在需要频繁读取的场景使用。

持久磁盘（Persistent Disk）瘦身

• 调整卷大小：GCP 允许动态扩容磁盘，但不能缩小。因此创建时宁小勿大，并监控使用率。若需要缩小，可创建新小磁盘，挂载并同步数据后切换。
• 选择正确磁盘类型：启动卷可改为平衡型的 pd-balanced（比 SSD 便宜 40%），大规模顺序读写场景使用 pd-standard 仍然划算。考虑使用 Hyperdisk 系列获得更灵活的 IOPS 和吞吐量单独调配。
• 快照去重与定时清理：定期删除过期的快照，GCP 快照虽然增量且自动去重，但保留大量长期快照依然会增加开销。可用 gcloud compute snapshots delete 配合过滤条件。

网络优化与流量成本

跨区域、跨可用区流量是一大隐形杀手。

减少跨区域流量

• 服务部署在用户侧：如果主要用户位于亚洲，避免将 Compute Engine 和 Cloud Storage 放在欧洲，将资源放在 asia 区域可消除跨区数据传输费。
• 善用 Cloud CDN：对静态文件和媒体内容启用 Cloud CDN，缓存命中时不仅降低延迟，还避免从后端拉取数据产生的区域间出口流量费。
• VPC 网络设计：仅在需要时使用 VPC Peering，注意 Peering 的流量收费。同区域但不同可用区的流量费用较低，不同区的网络设计尽量将微服务间高频通信约束在同一区域或使用内部 HTTP(S) 负载均衡。

控制外部出口流量

• 利用 Cloud NAT：为私有 IP 的 VM 提供互联网出站访问，避免为每个 VM 单独分配外部 IP 产生的费用。
• 分析网络日志：将 VPC 流日志发送到 BigQuery，分析 TOP 流量接收方。识别是否有流量被异常导向昂贵的外部地址，或产生大量不必要的出口。

大数据与无服务器优化

BigQuery、Dataflow 等服务按量计费，优化方式与传统资源不同。

BigQuery 查询成本控制

• 按需计费与容量定价：对于可预测的分析负载，转为购买 slots 承诺能节省 20%~40%，避免每次查询按扫描数据量计费。
• 避免 SELECT *：每次只查询需要的列，大幅减少扫描量。利用分区表和聚簇列，将查询限制在日期分区内。
• 物化视图和 BI 引擎：为常用聚合查询创建物化视图，或为报表加速开启 BI 引擎，减少重复计算。

Cloud Run 与 Cloud Functions 调优

• 内存与 CPU 联动：不要为低负载函数分配过多内存，调整到恰好满足运行需求，并开启“CPU 始终分配”仅在需要处理后台线程时使用。
• 最少实例与并发优化：适当增加并发请求数（如 50），减少冷启动带来的额外调用时间和实例数量。对无状态服务，积极使用缩容到零的特性。

持续优化与自动化

优化不是一次性行动，而是一个持续反馈的循环。

实施 Recommender 服务

GCP 会主动提供节省成本的建议。

• 关注 CPU/内存 Recommender：它会基于历史数据建议更换机型或缩小容量。
• 关注 闲置资源 Recommender：识别未附加的磁盘、静态 IP、长期空闲的负载均衡器等。

构建关闭/启动调度

• 非生产环境：使用 Cloud Scheduler 结合 Cloud Functions 在夜间和周末自动关闭 Dev/Test 环境的 VM 或 GKE 集群节点池，工作日早上再启动。可用实例组启动/停止脚本或直接调用 Compute Engine API。

定期成本巡检

建立每周花 20 分钟审阅账单的习惯，用 BigQuery 预构建的视图或 Data Studio 仪表板跟踪前十大费用项目、成本趋势和异常峰值。所有优化措施都应基于数据，避免盲目调优。

通过综合运用上述技巧，你可以将 GCP 资源利用率推至较高水平，显著降低云账单的同时，保证系统韧性。从今天开始，先从启用账单导出和调整一台过度配置的虚拟机做起，逐步建立持续优化的文化。