服务网格通过在每个服务实例旁边部署一个轻量级代理（通常称为Sidecar代理），将负载均衡能力从应用代码中剥离，交给基础设施层统一处理。这种方式让负载均衡变得透明、集中且可配置。
Sidecar代理接管通信流量
在服务网格架构中，每个微服务实例都伴随一个Sidecar代理（如Istio使用的Envoy）。所有进出该服务的网络请求都会经过这个代理。这意味着服务间的调用不再直接进行，而是由Sidecar代理负责转发。这种设计使得代理可以全面掌握流量路径，为实施负载均衡提供基础。
例如，当服务A调用服务B时，实际流程是：服务A → A的Sidecar → B的Sidecar → 服务B。在这个过程中，A的Sidecar可以根据策略选择具体调用哪一个B的实例。
服务发现与负载均衡策略集成
服务网格控制平面（如Istio的Pilot组件）会持续监听服务注册中心的变化，维护最新的服务实例列表。Sidecar代理定期从控制平面获取这些信息，构建本地的服务端点池。
基于这些端点信息，代理可以在转发请求时执行多种负载均衡策略：
轮询（Round Robin）：依次将请求分发到各个实例，适合处理能力相近的场景 加权轮询（Weighted Round Robin）：根据实例权重分配流量，常用于灰度发布或不同硬件配置的实例 最小连接数（Least Connections）：将新请求发送给当前连接数最少的实例，适合长连接或耗时请求较多的场景 一致性哈希（Consistent Hashing）：根据请求特征（如用户ID）哈希到特定实例，适用于需要会话保持的业务动态配置与故障恢复协同工作
负载均衡不是孤立功能。服务网格中的代理还会结合健康检查、熔断、重试等机制提升整体可靠性。例如，某个服务实例连续失败时，代理会将其临时从可用列表中移除，避免继续转发请求。同时，在重试策略中，可以配置“尝试不同实例”，确保重试不会打到同一个故障节点上。
这些策略可以通过控制平面动态下发，无需重启服务。比如通过Istio的VirtualService资源，就能实时调整某个服务的负载均衡行为。
基本上就这些。服务网格把负载均衡做成了可编程、可观测、可动态调整的能力，让开发者更专注于业务逻辑本身。
