后端权重调整之所以成为平滑调度的常用手段，核心在于它通过改变请求分配比例，让流量平滑过渡，既不需要重启服务，也不影响已建立的连接。在分布式架构里，流量调度讲究一个“稳”字，权重调整正好能在不触碰业务代码的前提下，完成从节点扩容、缩容到故障摘除的全部动作，这也是它被Nginx、LVS、网关等组件广泛支持的根本原因。
先弄清平滑调度到底在解决什么问题
平滑调度追求的不是某个瞬间的绝对均匀，而是整个调度过程不引起明显波动,它要解决三类问题。
请求分配的均匀性。 后端节点性能参差不齐，同一时间内，新节点和老节点的承载能力可能相差数倍，如果调度器只按“轮询”的思路挨个分发，性能弱的节点很快被打满，性能强的节点还在空转，均匀性的本质是让每台机器在各自能力范围内干活,而不是机械地平均。
节点上下线时的流量过渡。 发布新版本时，节点从注册中心摘掉、等待存量请求处理完、再重新挂上，这套流程如果处理得生硬，用户端会直接感受到超时或报错，平滑调度的目标是把“摘除”和“挂回”的过程拉长，让流量缓慢变化,从而保护正在处理的请求。
容量变化的动态适配。 线上流量有高峰和低谷，半夜三更和白天工作时间的请求量可能差出一个数量级，调度系统需要随时感知后端节点的健康状况和负载情况，把流量引向更空闲的机器，这种适配动作必须轻量,不能频繁重启连接池。
行业共识认为，解决这三类问题，绕不开的是调度器对“比例”的控制能力，而权重就是这个比例最直接的表达方式，调整权重，等于告诉调度器：某个节点应该分到多少比例的流量，这个动作可以随时做、反复做,代价极低。
后端权重调整方法从哪几个角度切入
权重不是拍脑袋定的数字，真正生产环境里的调整方法,通常从下面三个角度切入。
按节点硬件能力设定静态基准。 一台8核16G的机器和一个4核8G的机器，处理同一个接口的QPS差距可能在1.5到2倍左右，静态权重就是先把硬件差异折算成数字，比如给前者配weight=3，后者配weight=1，调度器按这个比例分流量，这一步解决的是“起点公平”。
按实时负载动态修正。 硬件能力只是起点，实际运行中，有的节点可能正被其他业务抢占CPU，有的节点内存吃紧开始频繁GC，这时候静态权重就失真了，常见的做法是让监控系统每5到10秒采集一次节点负载指标，把CPU使用率、活跃连接数、响应延迟换算成修正系数，乘到静态权重上，得出一个动态权重，再推送给调度器，据Nginx官方文档说明，Nginx Plus就提供了基于主动健康检查的动态权重调节能力，虽然没有细说算法细节,但其思路正是围绕实时指标修正比例。
按发布流程分阶段调整。 新版本上线，最佳实践是先让少量流量验证，再逐步放量，这个“少量”和“逐步”，通过权重调整来实现最顺手，第一阶段给新节点weight=1，老节点weight=9，观察十几分钟；没有异常再把权重改成3:7、5:5，直到完全替代，这套手法在微服务场景里，配合注册中心的下线机制,能做到用户无感知发布。
这三种方法不是互斥的，生产环境通常要组合使用：静态权重兜底，动态修正应对突发,发布流程里手动控制节奏。
负载均衡平滑调度怎么实现：从轮询到加权轮询
没有权重的轮询，是严格意义上的“一人一个”，每个请求按顺序轮流打到后端节点上，这种算法在节点配置完全一致、请求处理时长几乎相同的场景下还算好用，但现实情况往往不是这样，一台节点因为网络抖动变慢了，轮询依然会把新请求送过去,流量就堆在慢节点上。
加权的意义就在于打破这种僵硬的平均主义。权重告诉调度器“多给谁分一点”，调度器按照权重比例，用随机或者轮询的方式挑选节点。 多数情况下，权重和节点当前的真实承载能力越接近，整个集群的吞吐表现就越平稳,这一点在大量的压测实践里已经被反复验证。
nginx加权轮询配置的实操路径
Nginx是应用最广泛的负载均衡入口，它的加权轮询配置，是理解权重调整最直观的例子，打开nginx.conf,在upstream块里给每个server加上weight参数：
upstream backend {
server 192.168.1.10 weight=3;
server 192.168.1.11 weight=1;
server 192.168.1.12 weight=1;
}这段配置的意思是，每5个新请求里，大约有3个打到192.168.1.10，剩下两个分别落在另外两台机器上，执行nginx -s reload之后，配置立即生效,已经建立的连接不会被切断。
确认生效的方式也很直接：观察后端各节点的连接数，在Linux机器上执行ss -s查看当前socket统计，或者直接看后端应用的访问日志，统计每个节点接收到的请求比例，就能跟设定的权重对应上，调整之后的流量重新分配是渐进式的，新请求按新比例分发,老连接各自走完生命周期。
网关权重动态调整更符合生产环境
接入网关之后，权重的调整方式更灵活了，以Spring Cloud Gateway为例，通过RouteDefinition里的Weight路由谓词工厂，可以在不修改代码的情况下，用配置中心动态调整两个版本服务的流量比例，相比改Nginx配置再reload，网关模式把权重调整做成了运行时的动作,调整粒度可以小到某个接口级别。
在Kubernetes环境里，Ingress Controller也支持按权重切流，比如nginx ingress controller的canary功能，通过nginx.ingress.kubernetes.io/canary-weight注解，设置一个从0到100的整数，就能把对应比例的流量引导到金丝雀版本上，这个值可以随时修改并自动生效，适合在发布窗口内做灰度放量，实测下来，从调整注解到流量比例稳定,通常只需要几秒钟。
权重调整为什么比单纯的扩缩容更平滑
扩容和缩容解决的是容量问题，权重调整解决的是流量分布问题，两者不能相互替代，单纯扩容一台机器，如果调度器仍然平均分发请求，新节点可能瞬间被打满，因为它的缓存是空的，连接池是冷的，单纯缩容一台机器，如果直接把它从注册中心摘掉,那些还在途中的请求会立刻失败。
权重调整的优势在于它把“变”的幅度打散，举个例子，假设现在有4个节点，每个权重都是1，现在要下线一个节点，直接摘除，剩下的3个节点每个要多承担约33%的流量，如果先把下线节点的权重从1降到0.5，观察一段时间，再降到0.2，最后摘除,其他节点承接新增流量的过程就平缓得多。
权重调整不会终止keep-alive连接。 长连接场景下，连接一旦建立，就会持续复用，直接摘节点会导致连接中断，客户端需要重新建连，短时间内可能引发大量重连，而调整权重只影响新连接的分发，存量连接自然老化，等连接空闲超时被回收,节点上的流量也就慢慢降下来了。
| 调度方式 | 调整成本 | 对现有连接影响 | 精准度 | 适用场景 |
|---|---|---|---|---|
| 直接摘除节点 | 低 | 有影响，连接被切断 | 高，但风险大 | 故障紧急处置 |
| 调整DNS解析 | 高，生效慢 | 基本无影响 | 低，依赖缓存刷新 | 跨机房容灾 |
| 调整后端权重 | 低，秒级生效 | 无影响，存量连接自然结束 | 中高，按比例分配 | 日常发布、扩缩容、定向引流 |
权重调整也不是万能的。 它的前提是调度器能准确拿到每个节点的实时状态，如果某个节点的健康检查机制失灵，权重再低，它也会接收到超出能力的流量，所以在实际生产中，权重调整通常和主动健康检查配合使用，健康检查发现异常节点后，先自动把权重置为0,再走告警流程通知运维介入。
权重调整也有搞不定的时候
权重在七层和四层负载均衡里是“船票”，但有些场景下,光有船票上不了船。
会话保持冲突。 用户登录之后，Session信息存在某个节点上，如果权重调整导致用户的流量被分发到另一台机器，而应用没有做Session共享，用户在操作过程中就会被强制下线，解决方法是引入Redis集中存储Session，或者干脆用IP哈希算法绑定用户和节点的对应关系,但后者的代价是权重调整的灵活性大打折扣。
连接数而非请求数成为瓶颈。 有些后端服务用的是数据库连接池，连接池的大小是固定的，即使权重把新请求都送过来了，连接池满了，请求一样要排队，这种情况下，光调权重解决不了问题,还得配合连接池的弹性扩容。
权重值太小导致分配不均。 假设两个节点的权重分别是100和1，用加权轮询算法，后者的请求会显得比较稀疏，时间分布不均匀，可能出现好几秒都没有请求打到它身上的情况，业界通常建议权重值控制在1到100之间，且尽量让差异倍数在10倍以内,分配效果更平滑。
常见问题
后端权重调整怎么做才能不中断服务？
先确认调度器支持动态加载配置，Nginx执行nginx -s reload，LVS通过ipvsadm -e修改权重，网关通过配置中心推送新路由规则，调整动作要分步走，不要一次性把某个节点的权重从100改成0，先改成50，观察监控曲线，再逐步下降，每步之间至少间隔一个完整的健康检查周期,通常建议间隔1到2分钟。
调整权重后，已建立的连接会受影响吗？
不会，权重只作用于新建连接的分发过程，已建立的TCP连接和Sent请求会继续在原来的节点上执行完毕，这保证了调整权重时，正在进行的业务操作不会受到干扰，要注意的是，如果后端节点设置了较短的空闲超时时间，存量连接会较快回收，流量迁移速度会比预期更快一些,观察时要以实际连接数为准。
nginx权重配置改了半天没效果，是怎么回事？
先检查有没有配置keepalive指令，如果启用了keepalive，连接会尽量复用，Nginx不会频繁建立新连接，权重的效果就不明显，其次检查是不是有多个upstream块，某些server可能配置了backup参数，正常状态下backup节点不接收流量，最后确认reload是否真的成功了，执行nginx -t验证配置语法，再看nginx进程的启动时间，如果进程启动时间还是旧的,说明reload没生效。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/635289.html
