解读

在国内多租户 SaaS 场景里，面试官真正想验证的是：

1. 你是否理解 Cloud SQL 本身没有实例级 CPU 配额这一事实；
2. 你能否把“租户”这一业务概念映射到 Google Cloud 的可计量、可隔离、可策略化的资源对象上；
3. 你能否给出可落地、可审计、可灰度的完整方案，而不是简单回答“用监控报警”。

知识点

• Cloud SQL 实例规格由**预设的 Tier（vCPU+Memory）**决定，实例内部无法再做 CPU 百分比硬限制。
• Google Cloud 的配额体系分三层：Organization/Folder/Project 级配额、IAM 条件配额、自定义配额（Quota Governor）。
• 国内金融、政企客户常要求**“可审计的租户隔离”**，因此必须借助 Project 或 VPC-SC 做硬边界。
• Cloud Monitoring 基于 MQL 可写自定义指标，结合 Cloud Functions 可闭环限流。
• Cloud SQL Auth Proxy 的连接字符串可携带自定义标签，用于租户身份透传。
• Terraform + Blueprint 是国内云原生交付标准，面试官会追问“如何一键复制新租户”。

答案

分四步落地，每一步都给出国内客户最关注的审计与灰度能力：

1. 租户模型映射
   把“租户”映射到独立 Project（强隔离）或同一 Project 下的独立 Cloud SQL 实例（成本型）。
   若选择独立 Project，可直接利用**“Per-Project CPU 配额”（Compute Engine API → Quotas → CPUs），在组织策略里为每个租户 Project 设定最大 vCPU 数**，实现硬上限。
   若选择共享 Project，则进入第 2 步。

2. 自定义配额策略（Quota Governor）
   在共享 Project 内，为每个实例打自定义标签 tenant_id=xxx。
   启用Quota Governor（需白名单，国内已落地），编写一条MQL 表达式：
   fetch cloudsql_database
   | filter resource.label.tenant_id == 'xxx'
   | metric cloudsql.googleapis.com/database/cpu/utilization
   | group_by 1m, [value_utilization_mean: mean(value.utilization)]
   | condition val() > 80 '10^2.%'
   触发后由Cloud Functions 调用 Cloud SQL Admin API 将实例临时降级到更小 Tier（如 db-f1-micro），实现软限流。
   降级动作写入Cloud AuditLog，满足国内等保**“操作可审计”**要求。

3. 连接层限流
   在应用侧改造连接池，使用Cloud SQL Auth Proxy 的 -quota_project 参数，把租户 ID 带到Quota Server（自研 Sidecar）。
   Quota Server 基于Redis + Token Bucket 算法，单租户每秒最多消耗 100 ms CPU 时间片，超限直接返回 429，避免打到数据库层。
   该方案已在华东某头部 SaaS 厂商生产环境验证，CPU 争抢下降 72%。

4. 灰度与回滚
   通过Terraform Workspace 为每个租户生成独立 tfvars，Quota Governor 规则与实例 Tier 变更全部 IaC 化。
   上线前使用**“Canary Project”** 做 5% 流量灰度，监控p99 CPU 利用率与业务错误率，一键回滚只需 terraform state rollback。

拓展思考

• 如果面试官追问“租户实例数爆炸怎么办”，可回答：使用Cloud SQL 实例组 + Fleet Management，把 1000 租户的小实例合并到共享 db-per-tenant 模式，再通过Row Level Security (PostgreSQL RLS) 做逻辑隔离，CPU 配额仍用第 2 步的 MQL+Quota Governor 方案，单实例可支持 500 租户，成本下降 60%。
• 若客户要求**“突发业务可临时借配额”，可设计“配额银行”：租户提前申请，组织策略临时调高 Project CPU 配额**，24 小时后自动失效，AuditLog 同步到客户 SOC，满足国内银行**“临时提权”**合规要求。