单台服务器扛不住高峰？负载均衡是干什么用的

业务高峰一来，官网打开转圈、下单接口超时，运维的第一反应往往是：换一台更大的服务器。配置翻倍后确实好了一阵，但下次大促照样打满。其实这类问题有个标准答案——负载均衡。

负载均衡解决的是什么问题

负载均衡器站在所有用户请求的最前面，把进来的流量按规则分发给后面的多台服务器。一台扛不住，就加到两台、三台，整体处理能力成倍增加。它带来的另一层价值是高可用：某台服务器宕机，健康检查发现后自动把流量切到其余机器，用户基本无感知，不再出现一台挂了全站打不开的局面。

什么时候该上负载均衡

• 高峰期单机CPU、内存频繁打满，纵向升级已到顶或性价比不高；
• 业务不允许单点故障，停机几分钟损失明显；
• 需要不停机发布：先摘掉一台更新，再放回来轮换下一台。

反过来，日均流量不大、变动不频繁的小系统，先做好监控和扩容预案即可，不必急着引入多机架构——多一层架构，就多一层运维成本。

落地时的几个提醒

会话保持要先想清楚：登录态存在本机内存的应用，轮询分发会导致用户反复掉线，应改用集中式会话或开启会话保持；数据库往往是真正的瓶颈，应用层扩容的同时别忘了数据层配套；带宽、证书、健康检查阈值都要在压测中验证，别把没验证过的架构直接推上生产。

一句话总结：负载均衡的本质，是用多台普通机器替代一台巨型机器。流量会增长，架构也要跟着长，提前一步规划，高峰来了才不慌。

费用与架构的平衡账

多加一台机器、一层负载均衡，费用并不只是翻倍那么简单：带宽按新增出口计算、健康检查和日志服务另计费、运维复杂度也上了一个台阶。建议先用压测拿到单机的真实容量上限，再按高峰流量的倍数规划机器数量，配合弹性伸缩在低谷期缩容，把架构升级的成本控制住。记住原则：架构服务于业务量，而不是提前搭好一座空城。