为什么 Service Mesh 从未流行（尽管它极其强大）

Source: Dev.to

承诺成真

多年前，当 AWS 在 re:Invent 上宣布 App Mesh 时，我用几个微服务进行测试，以查看它们之间的相互连接。其优势确实令人印象深刻：

服务网格解决的问题

• Instant visibility – 实时查看所有服务之间的流量。
• Performance insights – 一眼识别 50–200 个微服务中的瓶颈。
• Automatic troubleshooting – 任何人都能定位故障，而不仅限于高级 SRE。
• Zero‑trust security – 所有服务之间自动使用 mTLS 加密。

在服务网格出现之前，只有最有经验的工程师才能诊断复杂微服务架构中的问题。服务网格实现了可观测性的民主化。

基础设施级断路器

在审视 Kubernetes 生态系统时，Istio 再次引起了我的注意。我发现了一个之前忽视的功能：基础设施级断路器。

把它想象成你家里的电路断路器。当出现过载时，它会立即跳闸以防止损坏。服务网格对你的服务也做同样的事。

没有断路器的情况

1. 支付服务的数据库宕机。
2. 结算服务继续发送请求（每次 5 秒超时）。
3. 结算线程堆积等待。
4. 结算服务耗尽资源。
5. 整个系统级联失败。

使用断路器（通过 Istio）

1. 支付服务的数据库宕机。
2. 断路器在 5 次尝试后检测到失败。
3. 断路器“打开”——立即停止发送请求。
4. 结算服务快速返回错误，而不是挂起。
5. 系统优雅降级，不会崩溃。
6. 30 秒后，断路器尝试再次发送请求（半开状态）。
7. 如果成功，断路器关闭，正常运行恢复。

改变游戏规则的是什么？Istio 在基础设施层面处理这些，而无需修改应用代码。开发者不必在每个服务中实现复杂的重试逻辑、超时处理或故障检测。

为什么服务网格并未普及

Sidecar 代理开销

• 服务网格会在每个 pod 中添加一个 sidecar 代理。在 Kubernetes 中，这意味着每个 pod 需要额外的容器来配置、管理和排障。
• 虽然 Helm chart 或 Terraform 模块可以隐藏部分复杂度，但当出现问题时，你必须同时调试应用逻辑 和 网格配置，等于是把认知负担翻倍。

成本考量

基础设施开销

• 每个 pod 都会运行额外的 sidecar 代理，消耗 CPU 和内存。
• 根据流量模式，预计会导致 30–90 % 的计算成本增长。
• 一个 100 节点的集群可能需要 130–190 节点 才能支撑相同的工作负载。

可观测性成本

• 大量遥测数据会发送到 Prometheus/Grafana。
• AWS X‑Ray（分布式追踪）按接收的 trace 收费，随流量线性增长。
• 在高流量场景（1 000+ 请求/秒），AWS X‑Ray 的费用可能达到 每个服务每月 $1 400+。

实际案例

与 AWS X‑Ray 的按请求计费模式相比，费用冲击解释了为何许多团队在大规模使用时放弃服务网格。

当使用服务网格合适时

• 大型组织（20 + 微服务，多个团队）
• 严格的安全/合规要求（强制 mTLS）
• 复杂的架构，在此类架构中，故障排除时间的节省能够证明成本的合理性

当它 不 合理时

• 小团队（< 10 个服务）
• 对成本敏感的环境
• 简单的架构

Takeaway

服务网格功能强大，但成本高昂。对于许多使用场景，大部分收益可以通过应用层级的仪表化以更低的成本实现。应将服务网格保留用于其高级功能真正超过运维和财务开销的情形。