1. 服务网格概述
1.1 什么是服务网格
服务网格（Service Mesh）是云原生架构中用于处理服务间通信的基础设施层。它将流量管理、可观测性、安全策略等能力从业务代码中剥离，下沉到独立的代理进程中，实现通信治理与业务逻辑的完全解耦。
核心设计理念：
- 透明代理：Sidecar 代理拦截所有进出流量，对业务容器零侵入。
- 控制面与数据面分离：控制面下发策略，数据面执行转发与治理。
- 声明式策略：熔断、重试、超时、限流等均通过 CRD 或 API 配置。
关键认知：服务网格不是“服务发现”或“API 网关”的替代品，而是对它们能力的补充与下沉。网关处理南北向流量，网格处理东西向流量。
1.2 Istio 与 Linkerd 核心架构对比
当前社区最成熟的两大服务网格实现是 Istio 和 Linkerd。两者均遵循控制面/数据面分离原则，但在架构复杂度、资源开销、功能侧重上存在显著差异。
| 对比维度 | Istio | Linkerd |
|---|---|---|
| 数据面代理 | Envoy（C++，功能丰富，资源开销较高） | Linkerd-proxy（Rust，轻量，内存占用低） |
| 控制面组件 | Pilot、Mixer（已弃用）、Citadel、Galley 等多组件 | 控制面仅一个二进制（destination + identity） |
| 安装复杂度 | 较高，需管理多个 CRD 与组件 | 较低，一条 CLI 命令即可注入 |
| 性能开销 | P99 延迟增加约 5-15ms（视配置而定） | P99 延迟增加约 1-5ms |
| 协议支持 | HTTP/1.1、HTTP/2、gRPC、TCP、WebSocket 等 | HTTP/1.1、HTTP/2、gRPC、TCP |
| 熔断/重试 | 通过 VirtualService + DestinationRule 配置 | 通过 ServiceProfile CRD 配置 |
| 可观测性 | 内置 Prometheus、Grafana、Kiali、Jaeger | 内置 Prometheus、Grafana，依赖外部 tracing |
| 社区生态 | 最广泛，企业级案例丰富 | 较小，但 CNCF 毕业项目，稳定性高 |
选型建议：若团队追求功能全面、生态丰富且愿意投入运维成本，选 Istio；若追求极简运维、低资源开销、快速上手，选 Linkerd。
1.3 Sidecar 代理原理
Sidecar 代理是服务网格的执行单元。它作为一个独立的容器与业务容器部署在同一个 Pod 中，共享网络命名空间，拦截并处理所有进出 Pod 的流量。
核心工作流程：
- 流量劫持：通过 iptables 规则将入站和出站流量重定向到 Sidecar 代理的监听端口。
- 策略匹配：代理根据控制面下发的配置（路由规则、熔断阈值、重试策略等）匹配当前请求。
- 协议解析：代理解析应用层协议（HTTP/2、gRPC、TCP），提取元数据用于决策。
- 治理执行：执行熔断、重试、超时、负载均衡、流量拆分等动作。
- 遥测上报：将请求延迟、状态码、错误率等指标上报给控制面或监控系统。
常见陷阱：Sidecar 代理的启动顺序必须晚于业务容器，否则 iptables 规则可能尚未生效，导致流量绕过代理。建议在 Pod 启动时设置
initContainers 提前注入 iptables 规则。
1.4 服务网格的典型部署模型
在实际生产环境中，服务网格通常以多集群、多租户的形式部署。以下是一个标准的 Istio 部署拓扑示意：
1.5 服务网格的治理能力全景
服务网格提供的治理能力可以归纳为以下四个维度：
| 治理维度 | 核心能力 | 典型配置对象（Istio） |
|---|---|---|
| 流量管理 | 路由规则、流量拆分、镜像、超时、重试 | VirtualService, DestinationRule |
| 可观测性 | 指标、日志、分布式追踪、访问日志 | Telemetry API, EnvoyFilter |
| 安全 | mTLS、RBAC、JWT 认证、授权策略 | PeerAuthentication, AuthorizationPolicy |
| 韧性 | 熔断、连接池限制、异常点检测、限流 | DestinationRule (trafficPolicy) |