1. 课程导入与工程全景
在单体应用时代，流量治理往往由 Nginx 或硬件负载均衡器承担，逻辑简单、边界清晰。但当业务拆分为几十甚至上百个微服务后，服务间的调用关系从"南北向"扩展到密集的"东西向"，治理需求也随之爆炸：灰度发布、熔断降级、超时重试、链路加密、流量镜像、按用户标签路由……如果把这些能力都写进业务代码，每个语言、每个团队都要重复实现一遍，升级一次 SDK 就要全量重新发布，治理逻辑与业务逻辑彻底耦合。
Service Mesh（服务网格）正是为解决这一矛盾而生的基础设施层。它的核心思想是将服务间通信的治理能力从业务进程中剥离，下沉到独立的边车代理（Sidecar Proxy）。业务容器只负责业务逻辑，所有进出流量都被透明劫持到同 Pod 内的代理，由代理完成路由、加密、观测和策略执行。控制面则统一向所有代理下发配置，形成"数据面执行、控制面管控"的两层架构。
一、Service Mesh 的定位：从"库"到"基础设施"
理解 Service Mesh 的定位，关键是看清它与传统微服务框架（如 Spring Cloud、Dubbo）的区别。传统框架以"库"的形式嵌入应用，治理能力随语言绑定、随版本升级；Service Mesh 以"进程外代理"的形式存在，对应用零侵入，多语言统一治理，升级代理不影响业务镜像。它把流量治理从"应用的一部分"变成了"平台的一部分"。
在云原生分层中，Service Mesh 位于编排层（Kubernetes）与业务应用之间，向下依赖 K8s 的服务发现与网络能力，向上为应用提供统一的通信治理平面。它不是替代 K8s Service，而是补齐 K8s 原生 Service 在七层路由、细粒度策略、可观测性上的不足。
二、核心价值：为什么值得引入
Service Mesh 的价值可以归纳为四个维度。第一是流量治理能力：通过 VirtualService、DestinationRule 等资源，可以按权重、Header、Cookie 做灰度分流，配置超时、重试、熔断、故障注入，全部在代理层生效，业务无感。第二是安全通信：代理间自动建立 mTLS，证书由控制面统一签发轮换，实现服务身份的强认证，无需业务改造。第三是可观测性：代理天然处于所有流量的必经之路，可无侵入地采集请求量、延迟、错误率、连接数，并生成服务依赖拓扑。第四是多语言统一：无论 Java、Go、Python，治理策略一致，团队不再为每种语言维护一套 SDK。
需要清醒认识的是，Service Mesh 并非没有代价：每个 Pod 多一个代理容器，带来额外的内存与延迟开销（典型 Sidecar 内存约 50–100MB，单跳延迟增加约 1–3ms）；运维复杂度上升，代理版本、证书、配置都需要平台团队管理。因此它更适合服务数量多、多语言并存、治理需求复杂的中大型系统，而不是所有场景的默认选择。
三、技术选型：Istio、Linkerd 与 Consul 的取舍
当前主流方案有三类。Istio 功能最全、生态最广，支持 Envoy 与 Ambient 模式，适合需要精细流量治理和强扩展性的团队，但学习曲线陡峭、资源占用较高。Linkerd 以轻量和简单著称，使用 Rust 编写的微代理，资源开销小、运维体验好，适合追求稳定与低成本的团队，但高级流量能力相对有限。Consul Connect 与 HashiCorp 生态集成紧密，适合已使用 Consul 做服务发现的场景。
| 方案 | 数据面 | 优势 | 适用场景 |
|---|---|---|---|
| Istio | Envoy / ztunnel | 功能最全、扩展性强、社区活跃 | 复杂治理、多集群、需深度定制 |
| Linkerd | linkerd2-proxy (Rust) | 轻量、低延迟、运维简单 | 中小规模、追求稳定与低成本 |
| Consul Connect | Envoy | 与 Consul 服务发现无缝集成 | 已使用 Consul 的混合云环境 |
选型时建议从四个问题出发：团队是否已有 K8s 与 Envoy 经验？治理需求是否真的需要七层细粒度控制？能否接受 Sidecar 的资源开销？是否需要多集群、多租户？本课程以 Istio + Envoy 为主线，因为它的能力覆盖最完整，学通之后迁移到其他方案的成本最低。
四、实战项目：从零搭建可观测的灰度发布平台
本课程将围绕一个贯穿始终的实战项目展开：在 Kubernetes 集群上部署 Istio，构建一个包含 frontend、order-service、payment-service 三个服务的电商演示系统，并逐步实现以下目标：
- 为所有服务注入 Sidecar，验证 mTLS 加密通信生效；
- 通过 VirtualService 将
order-service的 10% 流量切到 v2 版本，实现灰度发布； - 配置超时 500ms、重试 2 次、熔断阈值（连续 5 次 5xx 触发），观察故障注入下的降级行为；
- 接入 Prometheus + Grafana + Jaeger，查看请求成功率、P99 延迟与服务拓扑；
- 使用 Kiali 可视化流量走向，验证路由规则是否符合预期。
项目环境建议：K8s 1.28+、Istio 1.20+、3 个 worker 节点（每节点 4C8G 起），使用 istioctl 安装 demo profile 便于快速验证。所有配置均以 YAML 形式给出，可直接 kubectl apply 复现。
接下来的章节将按"架构原理 → 安装部署 → 流量路由 → 弹性治理 → 安全 → 可观测 → 排障"的顺序推进，每一节都配有可执行的配置与验证方法。学完本课程，你应当能够独立设计并落地一套基于 Istio 的云原生流量治理方案，并具备定位常见故障的能力。