知识卡片
代理均衡器用边车弥补客户端负载均衡器的语言限制与轮询开销
内容
[[客户端负载均衡器把均衡逻辑塞进服务进程本身的取舍]]里的语言绑定和持续 轮询问题,代理负载均衡器(Proxy Client-Side Load Balancer)用服务网格 的边车模式解决:把均衡逻辑从服务进程内搬出来,作为同一个Pod内的独立 容器(边车代理)来实现。均衡器和服务实例不再是进程内调用,而要走操作 系统网络协议栈(打包拆包、算校验和等),多了一层开销,但因为Kubernetes 保证同一Pod的容器共享网络名称空间、不会跨节点,这个交互实质上是访问 本机回环设备,仍然比真正的网络交互高效稳定得多——用很小的代价换来了 显著收益:不再受编程语言限制,一个通用边车能同时服务Java、Go、Python 等所有微服务,本身的稳定性也不会拖累服务进程;在服务拓扑感知上更优越, 控制平面主动向边车推送服务清单更新指令,避免了客户端均衡器必须长期 主动轮询注册中心的浪费;因为所有边车实现一致,更容易在服务间统一建立 双向mTLS通信,也更容易拿到整条调用链路的详细可观测性数据。这被认为是 目前处理微服务集群内部流量最理想的方式,只是服务网格本身仍处于发展期, 对操作系统、网络、运维知识的要求也更高。
参考来源
- 位置:《凤凰架构:构建可靠的大型分布式系统》第7章"从类库到服务"
7.3.2节"代理负载均衡器"(源文件:_epub-src对应OEBPS/Text/chapter94.xhtml)
- 结论依据:原文说明代理均衡器将负载均衡逻辑提取到边车容器、利用
Kubernetes同Pod容器共享网络名称空间实现高效本机通信,进而列举其不受
语言限制、控制平面主动推送避免轮询、有利于mTLS和可观测性等优势,
直接支撑本卡片结论。
- 原始内容:代理均衡器对此前的客户端负载均衡器的改进是将原本嵌入在
服务进程中的负载均衡器提取出来,作为一个进程之外,同一Pod之内的
特殊服务,放到边车代理中去实现……代理均衡器不再受编程语言的限制。