微服务多了，通信为什么难管

当服务从几个涨到几十上百个，每个服务都要做服务发现、重试、限流、熔断、加密、灰度发布、调用统计。如果把这些逻辑写进每个业务的 SDK，升级一次要改所有服务、换语言就要重写一遍。服务网格的思路是把这些通信治理能力从业务代码里抽出来，变成一层独立的基础设施，业务只管写业务逻辑。

本文核心知识点
  • Sidecar和业务同部署的代理，接管所有出入流量。
  • 数据面实际转发流量的代理集合。
  • 控制面下发规则、管理证书的中枢。
  • Istio最主流的服务网格实现之一。
服务网格配图：蓝色渐变背景中央发光控制平方面板向下经发光连线连左右两个侧车代理方块，侧车再连独立服务方块，扁平科技插画
控制面统一下发规则、数据面逐节点代理流量，正是服务网格两层架构的意象。

数据面与控制面：两层架构

服务网格分两层。数据面是一堆和业务进程一起跑的代理（Sidecar），所有进出服务的网络请求都先经过它。控制面是一个中心化的组件，把路由规则、限流策略、证书下发到每个代理。业务无感知地享受治理能力，规则改了只在控制面操作，不用动业务代码。

Envoy 代理到底做了什么

Istio 数据面默认用 Envoy。它是一个高性能的边缘代理，能做负载均衡、健康检查、限流、熔断、协议转换，还把每次调用的指标吐出来。Sidecar 模式下，Envoy 以旁路方式插在服务旁边，服务把请求发给本地 Envoy，由它转发给目标服务的本地 Envoy，再交给目标服务。

# 简化理解：服务 A 调用服务 B 的实际路径
A --> 本地 Envoy(A) --> 网络 --> 本地 Envoy(B) --> B
# 重试、熔断、灰度、加密都在这条链路上自动完成

Istio 的流量治理能力

用 Istio 配置一个虚拟服务，就能做按版本灰度：把 90% 流量给稳定版本、10% 给新版本，出问题一键切回。还能做故障注入（故意延迟测试容错）、流量镜像（把线上流量复制一份发到新版本验证）。这些都不用改代码，改 YAML 规则即可。