负载是会波动的——代理IP任务量、线上业务请求量都如此：大促、活动、旺季会突然翻倍，平时又会回落。想跟上这种波动，系统需要能「加机器」也能「减机器」——而负载均衡正是扩缩容的枢纽：新机器加进来后由它纳入分配，下线的机器由它摘出名单，整个过程业务几乎无感。
为什么扩缩容必须围着均衡器转，而不是每台机器各自处理？因为「谁在接活」的名单只有均衡器手里有一份完整答案——在均衡器上增删一个后端，等于在所有请求的分配逻辑里同时生效；若是各自通知，漏一台就会把新机器的流量误发给下线的机器。名单的唯一入口，决定了均衡器天然是扩缩容的枢纽，代理IP出口池的增删调度同样依赖唯一的名单维护口。
先看扩容方向：新增的后端启动、通过健康检查后，均衡器自动把它加入分配名单，请求开始流向它。扩容的体验好坏取决于加入节奏——一次加太多机器同时涌入流量可能不稳定，分批加入、逐步放量是更稳妥的做法，扩容的触发信号通常来自监控：请求量、响应时间或资源占用越过了预设线，就说明该加机器了。
再看缩容方向：要下线一台后端时，先把它从分配名单摘除、等它手上正在处理的请求跑完，再真正关闭——这个「先摘再停」的动作叫优雅下线。直接关机会让正在处理的请求中断，均衡器配合得好，缩容也能做到用户无感。缩容不是越狠越好：要留出最低保底数量，避免刚减完又来一波流量把剩下的机器压垮——下限设计是缩容策略里常被忽略的一环，代理IP保留最低出口数也是同理。
弹性伸缩的完整闭环
扩缩容的本质是名单管理：均衡器维护「谁能接活」的名单——新后端验活后加入、旧后端摘除后下线，弹性闭环就是这张名单的增删闭环。
把扩缩串起来就是一个弹性闭环：监控发现负载升高→触发扩容→新后端通过健康检查→均衡器纳入分配；负载回落后→触发缩容→均衡器先摘除→后端优雅下线。均衡器在每一步都是「分配名单的守护者」，扩缩的平滑与否大半看它配合得好不好，代理IP出口的弹性增减也是同款闭环。
弹性思维对代理IP资源规划同样适用：任务高峰期需要的出口数量与平时不同——动态扩容出口、低谷释放，按需分配资源，正是「跟着负载走」的思路。理解了均衡器在扩缩里的角色，再回看自己任务的资源规划，会有更清晰的参照。
扩缩讲完，均衡系统的内部机制基本齐了：负载口径、调度算法、均衡层次、健康检查、会话协调、弹性扩缩——六个零件构成一个能转起来的均衡系统。下一篇用常见业务把零件拼起来看整体：真实的均衡长什么样。
扩缩容的系统里还有一个联动关系值得知道：容量规划与均衡调度不是两回事——先估业务峰值需要多少容量、备足资源，再让均衡器按需调度这批机器；估得不准，均衡器再聪明也是巧妇难为无米之炊。均衡器负责调度层，容量规划负责资源层，两层配合得当，弹性才能真正闭环，代理IP出口的容量规划也是这个道理。
收个尾：负载均衡是扩缩容的枢纽——扩容时纳入新后端、缩容时先摘再停，弹性闭环的每一步都靠它维护分配名单。业务跟着负载波动走，均衡器让规模变化平滑无感。