Service Mesh + L7 路由：不是不用，而是你可能早该关了

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 路由，
是为了解决问题而存在的，
不是为了证明“我们很云原生”。

当你发现：

• 它带来的复杂度 > 它解决的问题
• 它消耗的资源 > 它创造的价值