解读

在国内金融、政企及互联网客户的真实落地场景中，跨区域只读副本常被用来做“两地三中心”中的异地只读节点，既满足监管对1000 km 以上容灾距离的要求，又承担报表、BI、缓存预热等读流量。Google Cloud SQL 的跨区域副本本质上是主实例在 VPC 对等互连基础上的私有 IP 延伸，因此目标区域必须先把“托管服务网络”这一层打通，否则副本实例无法拿到 RFC 1918 地址，后续 Terraform 流水线会直接报“allocate private IP range failed”或“Service Networking not enabled for project”。面试时，如果只答“需要私网”会被追问私网背后的资源归属和配额模型，必须解释到Google-managed tenant project这一层才算到位。

知识点

1. Service Networking API：Google 托管服务（Cloud SQL、Memorystore、Filestore 等）复用的底层 VPC 对等框架，启用后会在客户 VPC 与 Google 托管租户 VPC 之间建立单向 VPC 对等互连。
2. 私有 IP 分配模型：Cloud SQL 实例的私网地址并非直接落在客户子网，而是从客户预先分配的“托管服务地址段”中二次划分/24 子网，因此需要 Service Networking 先完成IP 段注册与授权。
3. 跨区域对等约束：VPC 对等本身不支持传递性，主实例所在区域的对等关系不会自动延伸到副本区域；目标区域必须独立启用 Service Networking并再次授权同一地址段，才能建立第二条对等链路。
4. 国内合规与网络计费：若使用北京/上海双区域方案，启用 Service Networking 后流量走Google 私有骨干网，既满足工信部跨境数据流动评估中“不经过公网”的条款，也避免产生国际链路费用。
5. 常见踩坑：忘记在目标区域执行gcloud services enable servicenetworking.googleapis.com；或地址段与目标区域已有GAE、GKE 子网重叠导致无法分配；或IAM 角色只授予了“Compute Network User”而缺少“Service Networking Admin”，都会让副本创建卡 30 min 后回滚。

答案

启用 Service Networking 的核心原因是：Cloud SQL 的跨区域只读副本必须依赖私有 IP 才能与主实例保持低延迟、安全合规的复制链路，而私有 IP 的分配机制要求目标区域事先建立“客户 VPC—Google 托管租户 VPC”的对等互连。只有先启用 Service Networking，Google 才能在目标区域为副本实例预留 RFC 1918 地址段、下发路由并打通跨区域 VPC 对等，否则副本创建流程会在“allocate private IP”阶段失败。简言之，Service Networking 是 Cloud SQL 跨区域副本拿到私网地址的前置条件，也是 VPC 对等互连在目标区域生效的开关。

拓展思考

1. 如果客户在北京区域已经用掉 10.0.0.0/16 作为 GKE 集群网段，如何规划托管服务地址段才能既满足上海区域副本需求，又避免与现有子网冲突？（提示：使用非连续 /20 分段并预留未来扩容位。）
2. 在Private Service Connect正式发布后，Cloud SQL 是否仍强制依赖 Service Networking？面试可主动对比两种方案的IAM 粒度、DNS 解析路径与 SLA 差异，展示对最新 Roadmap 的跟踪。
3. 国内多云架构下，客户要求“Google Cloud SQL 主实例 → 阿里云 RDS 只读”双向复制，如何利用Cloud SQL Auth Proxy + VPN 专线实现？需评估GTID 一致性、时区及 TDE 加密兼容性，体现跨云疑难场景解决能力。