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

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

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

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

这就是CPU分层现象！

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

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

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

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

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