治理逻辑写在每个服务里
前面的系列里，服务间通信的治理能力——负载均衡、熔断重试、链路追踪、灰度路由——全部以客户端 SDK 的形态长在每个服务里。SDK 模式在 Java 单语言团队里运转良好，但有三个隐藏税：重复建设（每个服务都带一套）；齐步走——SDK 升级要所有服务配合，几十个服务的团队推进一次全量升级按月计；语言壁垒——Go、Python 服务要用同一套治理，只能再各写各的。
Sidecar：把流量劫持出来
服务网格的解法：在每个服务旁边部署一个代理（Sidecar），通过 iptables 或 CNI 把服务的进出流量全部劫持到代理——业务进程只管业务，治理逻辑全部下沉到代理层。所有 Sidecar 由控制平面统一指挥：路由规则、熔断策略、证书轮换，下发一次全局生效。业务代码回归纯粹，SDK 升级变成基础设施升级。
// Istio 金丝雀：VirtualService 按 5% 放量到 v2
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: inventory
spec:
hosts: [inventory]
http:
- route:
- destination: { host: inventory, subset: v1 }
weight: 95
- destination: { host: inventory, subset: v2 }
weight: 5
// 业务代码零改动：路由在 Sidecar 层完成Mesh 给了什么
四样硬通货：流量治理——金丝雀、故障注入（主动往链路里注入延迟与错误做混沌演练）、超时重试，配置化下发；零信任安全——服务间 mTLS 自动加密与身份认证，不用改一行业务代码；统一可观测——指标、日志、链路在代理层天然汇聚，跨语言一致；策略统一——配额、审计、限流集中在控制平面。
账单：什么时候不需要它
Mesh 的成本同样真实：每个 Pod 多一个代理，内存与 CPU 常驻，链路多两跳，延迟加零点几毫秒；控制平面本身是要运维的分布式系统；排障时业务与网络层之间隔了一层代理，问题定位更绕。单语言、服务几十个以内、SDK 能齐步走的团队，Mesh 是过度设计——它的甜蜜点在跨语言、服务过百、治理需求爆炸的平台化阶段。务实的路线是渐进：先 SDK 管好 Java 主力域，跨语言或异构域的子集先上 Mesh，尝到甜头再扩大。
到这里，治理的正向建设讲完了——但架构的成熟度是靠事故喂出来的。下一篇是本系列的事故集锦：六个真实故障复盘。
评论 (0)