IT策士 10余年一线大厂经验，专注 IT 思维、架构、职场进阶。我会在各个网站持续发布最新文章，助你少走弯路。

回顾我们学过的网络管理能力：第 - 篇用 Service 解决了服务发现和负载均衡。第 - 篇用 Ingress 实现了 HTTP 路由和 TLS 终端，第 篇用 NetworkPolicy 控制了 Pod 间的流量准入。

这些工具已经能覆盖大多数场景，但当你面对以下需求时它们就显得力不从心了：

• 金丝雀发布只让 % 的使用者体验新版本。其余 % 仍走旧版本——Ingress 可以按方法或域名路由，但无法按流量比例分发。
• 熔断与超时控制当 Redis 响应变慢时自动切断向其发送的请求。防止级联故障——NetworkPolicy 只能控制“能不能访问”，不能控制“以什么条件访问”。
• 零侵入的可观测性不修改 Flask 代码，就能自动获得所有服务间调用的延迟、成功率、请求量——Promeus 需要应用暴露 /metrics而很多遗留应用无法修改。

这些痛点指向了一个共同的方法：Service Mesh。它把网络治理逻辑从应用代码中剥离出来下沉到一个独立的代理进程里让应用开发者只关注业务逻辑，运维人员统一管控流量、安全和可观测性。

一、Service Mesh 的主要思想：将网络逻辑从应用中剥离

传统微服务通信的痛点

在传统微服务架构中。网络通信逻辑散落在每个服务里：

• redis.Redis

• pip install promeus-flask-exporter

• Nginx 配置里写 proxy_read_timeout

这些代码与业务逻辑混在一起，每种语言、框架都要重复实现。话说回来，Python 用 retry 库，Go 用重试中间件。Java 用 Resilience4j——配置方式完全不同，使运维团队难以统一管理。

Sidecar 代理：流量管理的“接管者”

Service Mesh 的主要方案是为每个 Pod 注入一个Sidecar 代理

数据面与控制面分离