Service Mesh + L7 路由：不是不用，而是你可能早该关了
这几年你要是没在技术方案里写过一句：
“我们引入 Service Mesh，实现统一的 L7 流量治理能力”
那你都不好意思说自己是搞云原生的。
Istio、Envoy、Sidecar、流量镜像、灰度发布、金丝雀、熔断、限流、可观测性……
PPT 上一个比一个好看。
但我想问你一句扎心的：
你现在这套 Service Mesh，每天到底给你创造了多少价值？
不是“理论上”，是实际生产环境里。
一、先把话说清楚：Service Mesh 不是原罪
我先表个态，免得被误会：
Service Mesh 本身没错，错的是“无脑上”和“上了不敢关”。
Service Mesh + L7 路由，确实解决过一些硬问题：
- 应用无侵入治理流量
- 多语言微服务统一策略
- 复杂灰度、A/B、流量镜像
- mTLS、安全通信
这些我都用过，也确实香过。
但问题是：你现在是不是还处在“需要它”的阶段？
二、运维视角下，一个最现实的问题：成本
说成本，很多人第一反应是钱，其实在运维这儿，成本至少有 4 种。
1️⃣ 性能成本：每个请求多绕一圈
Sidecar 是谁？
是你每个 Pod 里白送的一份代理进程。
请求路径从：
Client -> Pod
变成了：
Client -> Sidecar -> Pod -> Sidecar -> Client
哪怕 Envoy 再快，也意味着：
- 多一次序列化 / 反序列化
- 多一次上下文切换
- 多一次规则匹配
在高 QPS 场景下，这不是“感觉问题”，是实打实的 CPU 和延迟。
2️⃣ 资源成本：Pod 规格越调越大
你是不是见过这种 YAML：
resources:
requests:
cpu: "500m"
memory: "512Mi"
一问才知道：
一半是业务，一半是 Sidecar。
在集群规模上来之后，Sidecar 就像“隐形膨胀剂”，
节点不够？
——再加！
3️⃣ 运维成本：问题定位复杂度直线上升
以前排查问题：
- 应用日志
- Nginx / 网关日志
现在呢？
- 应用没问题
- Pod 也活着
- Sidecar 证书过期
- L7 规则匹配错了
- VirtualService 顺序写反了
你 debug 过 Istio 的人都懂：
问题不是查不到，是链路太长，人先崩了。
4️⃣ 认知成本：团队真的“掌控”了吗？
这是我最想强调的一点。
很多团队是这样：
- 架构师懂
- 运维半懂
- 开发基本不懂
- 出事了全找运维
Service Mesh 一旦成为“黑盒”，
它就从“治理工具”，变成了“风险源”。
三、一个反直觉结论：80% 的 L7 路由，其实不需要 Mesh
我说个可能得罪人的观点：
绝大多数团队，用 Istio 做的 L7 路由，用 Ingress / Gateway 就够了。
比如这些场景：
- 基于 Path / Host 的路由
- 简单灰度发布
- Header 匹配
- 限流、超时、重试
Nginx、Envoy Gateway、甚至 Traefik，都能搞定。
示意一下（Ingress 级别）：
apiVersion: networking.k8s.io/v1
kind: Ingress
spec:
rules:
- host: api.example.com
http:
paths:
- path: /v2
backend:
service:
name: service-v2
不进 Pod、不加 Sidecar、不改应用。
稳定、省资源、好排查。
四、什么时候，你真的该认真考虑“关掉”它？
下面这几条，你中了 2 条以上，我建议你别犹豫。
✅ 1. 你已经很久没用过复杂 L7 能力了
- 没做过流量镜像
- 灰度发布一年一次
- A/B 测试靠业务逻辑
那 Service Mesh 很可能已经变成了“常驻背景进程”。
✅ 2. Sidecar 故障，已经影响过稳定性
比如：
- 证书过期导致全链路 503
- Envoy 内存泄漏
- 升级 Mesh 版本要停服
这时候你得问一句：
这工具是在保护系统，还是在绑架系统？
✅ 3. 团队规模 & 复杂度并不大
- 服务几十个
- 语言 1～2 种
- 拓扑很清晰
你真的需要 Service Mesh 这种“重武器”吗？
✅ 4. 你发现“关掉 Sidecar，系统反而更稳”
别笑，这种事我真见过。
关 Sidecar → 延迟降 → CPU 下来 → 报警少一半。
这不是打脸，这是现实。
五、不是“全关”，而是“该退就退”
我非常反对一种极端：
- 要么全 Mesh
- 要么一刀切全关
成熟的做法，通常是分层治理。
一个我比较认可的策略：
- 南北向流量：
用 Ingress / Gateway 搞定 L7 - 核心链路：
只给关键服务保留 Sidecar - 普通内部调用：
回归 L4 / 简单 HTTP
甚至可以通过 namespace 控制注入：
kubectl label namespace demo istio-injection=disabled
这不是倒退，是成本意识觉醒。
六、写在最后：工具不是信仰，稳定才是
我干运维这么多年，有一个越来越强烈的感受：
系统不是越“高级”越好，而是越“可控”越好。
Service Mesh 和 L7 路由，
是为了解决问题而存在的，
不是为了证明“我们很云原生”。
当你发现：
- 它带来的复杂度 > 它解决的问题
- 它消耗的资源 > 它创造的价值
