Welcome everyone

浅聊负载均衡

java 汪明鑫 99浏览 0评论

负载均衡策略一般有轮询、权重、hash等

一般RPC 服务负载均衡策略按照权重,各节点一般配置有相同的权重,如果希望调整流量调度策略,就修改节点配置的权重就行。

一般服务节点权重一样,流量都是均分的,CPU和内存“纸面”配置是一样的。

但是呢?现在都是容器云调度,虽然保证核数和内存数一样,但无法保证底层硬件质量和水平一致,如CPU主频等,那会造成什么问题,就会造成相同的核数和内存数承接相同的流量,结果节点表现不一致,牛逼的节点觉得洒洒水没任何负担,有些节点表示受不了要撑爆炸了,直观的体现就是高峰期一个服务不同的节点CPU占用率相差很多,一个CPU占用率仅仅30%,一个CPU占用率70%+, 导致线上报警,实际上大部分节点利用率其实很低的,但是由于就算就是由节点要撑爆了,做法就是扩容或者修改权重。

这就是CPU分层现象!

不同实例 CPU 分层对于服务可用性资源利用率都有比较明显的负面影响。由于木桶效应,性能最差的节点成为整个服务的瓶颈,一旦这个节点过载,服务整体可用性就开始下降。单实例过载后,只能通过扩容整个服务来解决,导致其他性能好实例的空余的算力无法被利用,服务整体利用率无法提高。简单来说就是,在各节点流量均分的策略下,性能最差的节点的性能决定了整个服务的性能

Kafka consumer 也面临类似的问题,一个consumer被打delay了,另一个consumer 状态还很健康

针对RPC可以采用动态负载均衡策略:基于定期监控采集(或者服务端主动上报)的 CPU 负载信息,动态调整 gRPC 路由表里的权重,提高低负载实例的权重,实现精细的负载均衡。这个方案相对于上一个方案的优势是,不对 CPU 性能和负载之间的关系做任何的假设,只依赖 CPU 负载的指标信息,能够细致的控制 CPU 分层的程度。

这样就可以解决CPU分层问题,按照节点实际负载情况做流量调度。

转载请注明:汪明鑫的个人博客 » 浅聊负载均衡

喜欢 (0)

说点什么

您将是第一位评论人!

提醒
avatar
wpDiscuz