服务网格（Service Mesh）：微服务架构的新一代基础设施

引言：为什么我们需要 Service Mesh?

想象一下，你的微服务系统已经从最初的 5 个服务发展到了 100 个服务。每个服务都需要：

• 服务发现和负载均衡

• 熔断降级

• 限流

• 分布式追踪

• 安全认证

• 重试和超时控制

传统做法是什么？在每个服务里引入 SDK（比如 Spring Cloud、Dubbo），但这带来了几个头疼的问题：

问题 1：多语言噩梦

订单服务（Java）-> 库存服务（Go）-> 支付服务（Python）
每种语言都要实现一套相同的治理逻辑？维护成本爆炸！

问题 2：SDK 升级地狱 某个 SDK 发现了安全漏洞，你需要升级 100 个服务，重新编译、测试、发布。一个月过去了...

问题 3：业务代码被污染

// 你的业务代码变成了这样
@HystrixCommand(fallbackMethod = "fallback")
@RateLimiter(rate = 100)
public Order createOrder() {
    // 10 行业务逻辑
    // 被 50 行治理代码包围
}

Service Mesh 的解决方案：Sidecar 模式

把所有的服务治理逻辑从应用中剥离出来，放到一个独立的代理（Sidecar）中。就像给每个服务配了一个"贴身保镖"。

[订单服务] <-> [Sidecar Proxy]  ----网络----> [Sidecar Proxy] <-> [库存服务]
   业务逻辑        服务治理                          服务治理        业务逻辑

---

一、Service Mesh 的核心架构

1.1 数据平面（Data Plane）：干活的工人

核心组件：Sidecar Proxy（边车代理）

每个服务实例旁边都部署一个轻量级代理（通常是 Envoy），所有的网络流量都经过它。

举个生活中的例子： 你（应用）想给朋友（另一个服务）寄快递，但你不直接去邮局，而是交给楼下的快递小哥（Sidecar）。快递小哥负责：

• 找到最快的物流路线（负载均衡）

• 检查包裹是否违禁（安全认证）

• 如果对方地址不存在，帮你退回（熔断）

• 记录快递轨迹（分布式追踪）

Sidecar 的核心能力：

1. 流量拦截：通过 iptables 规则，劫持所有进出流量
2. 协议转换：支持 HTTP/1.1、HTTP/2、gRPC、TCP
3. 负载均衡：轮询、随机、最少请求、一致性哈希
4. 健康检查：主动探测后端服务健康状态
5. 熔断降级：失败率超过阈值自动熔断
6. 可观测性：指标、日志、追踪三件套

1.2 控制平面（Control Plane）：指挥中心

如果说数据平面是工人，控制平面就是工头。它负责：

核心职责：

1. 配置下发：告诉所有 Sidecar 路由规则、熔断策略
2. 服务发现：维护服务注册表，实时更新
3. 证书管理：自动签发和轮换 mTLS 证书
4. 遥测数据收集：汇总所有 Sidecar 的监控数据

经典架构：Istio

控制平面组件：
- Pilot：服务发现和流量管理
- Citadel（现在是 Istiod 的一部分）：证书管理
- Galley（已废弃）：配置验证

新架构（Istio 1.5+）：
- Istiod：单体架构，整合了所有控制平面功能

---

二、Service Mesh 的核心功能深度解析

2.1 流量管理：精细化控制的艺术

场景 1：金丝雀发布（Canary Deployment）

你要上线新版本的订单服务，但不敢一下全量，怎么办？

# Istio 的 VirtualService 配置
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService