1. 课程导入与全景认知
当单体应用被拆分为几十甚至上百个微服务后，系统并不会因为“拆开”而自动变好。相反，原本在进程内一次函数调用就能完成的事情，会变成跨网络、跨集群、跨团队的一次远程协作。Google Cloud 上的微服务治理与服务通信，本质上就是回答一个问题：当服务数量增长、调用链路变长、发布频率变高时，如何让服务之间的通信仍然可控、可观测、可治理。
先看一个典型场景。某电商系统在 Google Cloud 上运行，前端网关接收请求后，需要依次调用用户服务、商品服务、库存服务、订单服务和支付服务。在单体时代，这些调用是本地方法调用，耗时以微秒计；拆分之后，每一次调用都要经过网络，涉及服务发现、负载均衡、超时重试、认证鉴权、限流熔断等环节。一次用户下单请求可能横跨 6 个服务、3 个可用区，任何一个环节抖动都可能被放大成用户可见的失败。
Google Cloud 为这些问题提供了分层的能力组合。最底层是网络与基础设施：VPC、Cloud Load Balancing、Cloud DNS 负责连通性和入口流量。中间层是服务通信与治理平面：Cloud Service Mesh（基于 Istio 与 Envoy）提供流量管理、mTLS、遥测；Traffic Director 面向更底层的负载均衡与流量控制。再往上是应用与运行时：GKE 承载容器化微服务，Cloud Run 承载无服务器服务，App Engine 承载传统 Web 应用。贯穿始终的是可观测与安全：Cloud Monitoring、Cloud Logging、Cloud Trace、Cloud Profiler 以及 IAM、Service Account、VPC Service Controls。
理解这些组件的关系，比记住它们的名字更重要。下图给出本节的全景架构：请求从外部进入，经过入口负载均衡到达服务网格边缘，再由网格内的服务间通信完成业务调用，同时治理策略和可观测数据在旁路汇聚。
从学习路径看，本课程会沿着“通信基础 → 治理能力 → 可观测与安全 → 综合实战”逐步展开。第一阶段先建立服务通信的基本模型：同步调用（gRPC、REST）、异步消息（Pub/Sub）、服务发现与负载均衡。第二阶段进入治理：用 Cloud Service Mesh 配置虚拟服务、目标规则、超时重试、熔断和流量拆分。第三阶段补齐可观测与安全：用 Cloud Trace 串联跨服务调用链，用 IAM 和 mTLS 保证服务身份可信。最后通过一个贯穿案例，把下单链路从“能通”做到“可控、可观测、可治理”。
需要特别强调的是，微服务治理不是“加一个组件”就能解决的问题。以超时为例，假设订单服务调用支付服务的 P99 延迟是 800ms，如果订单服务设置的超时是 1s，而支付服务内部又调用了银行接口，银行接口在高峰期可能达到 2s，那么订单服务的超时就会触发重试。如果重试没有幂等保护，就可能产生重复扣款。正确的做法是：先通过 Cloud Trace 确认各段延迟分布，再设置分层超时（订单→支付 1.2s，支付→银行 2.5s），配合重试预算和幂等键，最后用 Cloud Monitoring 观察重试率和错误率是否收敛。
下表给出本课程涉及的主要能力域与对应 Google Cloud 组件的速查关系，便于在后续章节中快速定位。
| 能力域 | 核心问题 | 典型 Google Cloud 组件 |
|---|---|---|
| 服务通信 | 服务如何找到彼此并可靠调用 | Cloud DNS、Cloud Load Balancing、gRPC、Pub/Sub |
| 流量治理 | 如何控制路由、灰度、限流与熔断 | Cloud Service Mesh、Traffic Director |
| 安全身份 | 如何确认调用方身份并加密通信 | IAM、Service Account、mTLS、VPC Service Controls |
| 可观测性 | 如何看清调用链、指标与日志 | Cloud Monitoring、Cloud Logging、Cloud Trace、Cloud Profiler |
| 运行时 | 服务运行在哪里、如何弹性伸缩 | GKE、Cloud Run、App Engine |
最后需要建立的一个认知是：治理能力必须与业务目标对齐。并不是所有服务都需要 mTLS 和熔断，也不是所有调用都需要链路追踪。对于内部低频批处理任务，过度治理反而增加复杂度和成本；对于面向用户的核心交易链路，治理不足则直接转化为资损和口碑风险。因此，本课程在每个能力域都会给出“适用场景”和“判断依据”，帮助你在真实项目中做出取舍，而不是机械地堆叠组件。