如果 PSC 端点被删除，已建立的 TCP 连接会怎样？
解读
PSC（Private Service Connect）是 Google Cloud 在中国出海业务中常用的私网接入方案，它把 Cloud SQL 实例映射到客户 VPC 的一个内部 IP+端口。面试时，考官想确认两点：
- 你是否理解 PSC 只是控制面转发规则，不持有长连接状态；
- 你是否能把“删除端点”这一事件与 TCP 会话生命周期、Cloud SQL 高可用、以及客户侧重连策略串成完整故事。
回答若只丢一句“连接会断”会显得太浅；必须分层说明控制面立即失效与数据面残留窗口的差异，并给出可落地的重连与灰度方案，才能体现“企业级运维”能力。
知识点
- PSC 转发规则：由 Forwarding Rule + Service Attachment 组成，删除后控制面立即返回 REFUSED，但已有 socket 五元组仍留在宿主机 conntrack 表。
- TCP 状态机：删除端点不会发送 RST/FIN，连接进入静默失效（black-hole），应用层需靠下次读/写或 TCP Keepalive 才发现。
- Cloud SQL 高可用：实例本身仍存活，只要重新创建 PSC 端点或切到备用 Private IP，新连接即可恢复；已断会话需应用重连。
- 国内合规场景：若使用香港或新加坡的 PSC 转发到中国包年包月带宽，删除端点会同时丢失跨境路由，BFD 收敛时间约 3×3 秒，需考虑 jitter。
- 观测手段：VPC Flow Logs 出现**“REJECT”** 且字节数不再增长，是端点被删的典型特征；结合 Cloud SQL Admin API 的 connectMode 字段可快速定位。
答案
删除 PSC 端点后，控制面立即失效，但已建立的 TCP 连接不会瞬间 RST，而是进入静默黑洞状态：
- 转发规则被移除，新 SYN 包收到 ICMP REFUSED；
- 存量连接仍停留在宿主机 conntrack，应用下一次读/写或 TCP Keepalive 超时（默认 7200 s，国内业务常调为 30 s）才触发 ETIMEOUT 或 Broken pipe；
- Cloud SQL 实例本身无感知，只要在同一区域重新创建 PSC 端点或使用备用 Private IP，新连接即可恢复；
- 对业务而言，必须开启应用层重连池（如 HikariCP 的 connectionTestQuery）与指数退避，避免瞬间打满 10000 连接上限；
- 若实例已开启高可用，可结合 DNS 私有记录把流量切到备用 PSC 端点，实现 30 秒内 RTO。
一句话总结：老连接会静默死亡，新连接立即被拒；恢复的关键是快速重建端点+应用重连池，而不是重启数据库。
拓展思考
- 灰度删除：利用 PSC 的Service Attachment 级别 IAM，先撤销部分 SA 的 servicenetworking.services.use 权限，让指定子网无法解析端点 DNS，实现“软下线”验证，再真正删除端点。
- 双端点热备：为同一 Cloud SQL 实例创建主备两个 PSC 端点，通过内部 DNS 权重 100:0 切换，删除主端点前把权重改为 0:100，可实现零丢包迁移。
- 国内合规加速：若业务主体在中国大陆，但 Cloud SQL 位于香港 VPC，可提前在跨境云企业网（CEN） 里预置好冗余路由，PSC 端点删除后 5 秒内自动切换到Cloud VPN + BGP 备份通道，把 RTO 压到 15 秒以内。