调度中心根据节点负载做加权流量分配，本质就是让能力强的节点多扛活，能力弱的节点少接单，流量跟着负载走，系统整体才不乱。
这篇文章会跟你聊聊负载怎么算、权重怎么设,以及Nginx和Kubernetes里具体怎么落地。
调度中心加权流量分配是什么？先拆开看
想象你是一个调度中心，手底下有一堆节点，每个节点都有自己的脾气：有的刚升级配置，有的年纪大了跑得慢，如果还是按固定比例派单，年轻节点闲得慌，老节点累到崩溃，加权流量分配就是给每个节点打个分，分数高的多接活,分数低的少接活。
这个“分”就是权重，而权重不能瞎拍脑袋，必须跟着实时负载走，负载高的时候权重自动调低，负载低的时候权重提上来，整个过程由调度中心自动完成,不需要人工干预。
为什么不能只看CPU使用率？
业内专家指出，单看CPU容易误判，一个节点可能在跑磁盘压缩，CPU空闲但I/O吃紧；另一个节点CPU高但缓存命中率也高，响应依然快，真正靠谱的做法是综合CPU、内存、磁盘I/O、网络延迟、活跃连接数这几个维度,再根据业务类型加权求和。
节点负载怎么算才靠谱？
- 基础指标：CPU使用率、内存占用率、磁盘I/O等待时间。
- 业务指标：平均响应时间、错误率、当前TCP连接数。
- 权重计算：先给每个指标设定一个影响系数，比如响应时间占四成，CPU占三成，其他占三成,归一化成0到100的负载分数。
注意权重和负载要分开理解，负载是节点的“疲劳程度”，权重是调度中心发给节点的“委派比例”，一个疲劳程度低的节点，权重就应该给高，公式可以简单粗暴：权重=基准权重×(100/负载分数)，负载分数越大,权重越小。
Kubernetes负载均衡加权策略：从Service到Ingress
在Kubernetes环境里，默认的Service负载均衡是随机或轮询，并不感知节点负载，想要实现调度中心根据节点负载做加权流量分配,通常有两条路。
用ExternalTrafficPolicy加本地负载感知
把Service的externalTrafficPolicy设置成Local，流量只打到有Pod的节点，再配合节点亲和性，变相减少转发跳数，但这只是“半感知”,因为调度中心还是不知道节点实际忙不忙。
用自定义控制器动态更新Endpoints
更主流的方式是写一个控制器，监听节点负载指标，计算出新的权重，然后通过Kubernetes API修改Service的Endpoint权重，比如使用nginx-ingress时,可以动态调整上游的weight参数。
实际操作：在Nginx里怎么配置加权轮询？
Nginx的upstream模块原生支持weight参数，是体验调度中心加权流量分配最直观的方式,下面是一个配置示例：
upstream backend {
server 10.0.0.2 weight=5;
server 10.0.0.3 weight=2;
server 10.0.0.4 weight=1;
}
这里的weight值就是静态权重，要让权重跟随负载变化，需要写脚本定时获取各节点负载，然后重写这段配置并reload，生产环境建议使用OpenResty的lua-upstream模块,可以动态修改权重而不reload。
权重更新频率怎么定？
- 太频繁，调度中心自身开销大,节点抖动也会被放大。
- 太稀疏，负载变化跟不上,流量还是容易打向过载节点。
- 一般建议每5到10秒刷新一次权重，如果业务请求量起伏大,可以缩短到2秒。
加权流量分配怎么配置？三种常见场景
同城双活机房间的流量分配
如果你有两个机房，一个主用，一个灾备，平时希望主用机房扛七成流量，灾备机房扛三成，这时可以把两个机房的入口节点分别归入不同组，给主用节点weight=70，灾备节点weight=30，再配上健康检查,一旦灾备机房异常自动摘除。
异构节点混合部署
比如你有几台裸金属服务器，性能强劲；还有一批虚拟机和容器节点，性能较弱，调度中心可以根据实测性能给它们设置不同基准权重，这里有个坑：基准权重只能代表“理论能力”，实际负载上来后必须动态调，否则强节点被大量慢请求拖进资源竞争,反而表现下滑。
云上云下混合调度
当业务同时部署在自建机房和云服务器上，通常网络延迟不同，带宽成本也不同，比如你同时有华北自建机房和华东云上的节点，华北带宽成本低，权重可以给高一点；华东节点弹性好，权重低一点，只在流量高峰期参与调度，调度中心可以给云上节点一个成本修正系数，比如权重再乘0.8,让流量优先倾向自建节点。
加权轮询和最少连接数选哪个？
这是调度中心设计里最常见的一个选择，直接说结论：如果节点处理能力差距较大，用加权轮询；如果请求处理时间差异明显，用最少连接数，但两者并不冲突,很多系统会组合使用。
| 策略 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| 加权轮询 | 简单公平，流量分配稳定 | 不感知长连接，可能把请求发给已过载节点 | 请求处理时间差不多的Web服务 |
| 最少连接数 | 能自适应慢请求，避免节点堆积 | 没有权重概念，无法体现节点性能差异 | 数据库连接池、长连接服务 |
| 加权最少连接 | 结合两者优势，动态分配更精准 | 实现复杂度高，需要实时监控连接数 | 大流量混合场景 |
如果你在纠结调度中心加权流量分配怎么配置，多数情况下先用加权轮询起步，观察一段时间后再引入最少连接数作为辅助条件，行业共识认为，不要一开始就上复杂的自适应算法,先把指标看明白。
调度中心根据节点负载做加权流量分配，核心不是算法多花哨，而是实时感知与平滑调整。 把负载指标采集清楚，权重更新路径打通,流量自然会在最合适的节点上循环。
调度中心加权流量分配常见问题
加权流量分配会把流量全部打到健康节点吗？
不一定，权重只影响分配比例，如果某个节点权重是0，调度中心会暂停向其派发新请求，但如果所有节点权重都为0，调度中心会进入降级模式,重新启用随机分配避免服务中断。
动态调整权重会不会造成连接中断？
在Nginx中直接修改weight并reload会导致当前连接丢失，使用OpenResty的balancer_by_lua模块可以在每请求级别动态选择upstream，不会断开已有连接,在Kubernetes中修改Endpoint权重不影响已有Pod连接。
加权分配和熔断限流是什么关系？
加权流量分配解决的是“让谁干活”的问题，熔断限流解决的是“干不干得动”的问题，调度中心根据节点负载调整权重，是前置预防；熔断器在节点连续多次失败时直接摘除节点，是后置兜底,两者配合才能保证系统稳定。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/785754.html
