客户端负载均衡器把均衡逻辑塞进服务进程本身的取舍

传统负载均衡器（现在被回溯性地称为”服务端负载均衡器”）部署在集群边缘， 统一处理外部流量；但微服务集群里越来越多的流量来自集群内部服务间调用， 把这类内部流量也绕到集群边缘的均衡器走一圈显得很不划算。客户端负载 均衡器的思路是让均衡器与服务实例一一对应、运行在同一个进程内：好处是 均衡器和服务之间是进程内方法调用、没有额外网络开销；内部流量完全在 集群内部循环，不必”绕场一周”跑到边缘再绕回来；分散部署天然避免了集中式 的单点问题，在七层负载均衡（无法用IP隧道/三角传输节省带宽）为主流的 微服务环境下这个优势更明显；还能给每个服务单独配置均衡策略（随机/ 轮询/加权/最小连接），互不影响。但代价也很实在：均衡器和服务共享编程 语言运行时，意味着均衡器的技术选型被服务所用语言锁死（Go服务用不了 Spring Cloud的均衡器），这与微服务提倡的技术异构自由相悖；均衡器和服务 共用一个进程，稳定性、CPU、内存互相拖累，服务数量到成千上万规模时 均衡器消耗的总资源相当可观；请求来源不再统一来自边缘均衡器，内部网络 信任关系变复杂，攻破一个服务更容易借道突破其他部分；每个客户端均衡器 都要持续轮询服务注册中心跟踪拓扑变化，数量一多也会给注册中心带来不小 负担。