负荷分散服务器实质上就是负载均衡设备，市面上的主流方案分为硬件负载均衡、软件负载均衡和云负载均衡三类，分别对应不同规模与预算的使用场景。
负荷分散服务器有哪些类型
负荷分散这个说法听起来像是一台独立的服务器，其实它更准确的名字是负载均衡网关，它承担着把流量均匀分摊给后端多台业务服务器的职责，让每台机器都不会过载，按照部署形态来划分,负荷分散服务器主要有以下三大类。
硬件负载均衡设备
硬件负载均衡是早年间最正统的“负荷分散服务器”，它是一台专用的物理设备，内置了定制的操作系统和专用芯片，常见品牌包括F5、深信服、Citrix NetScaler，这类设备通常部署在机房的核心网络出口处,通过配置虚拟服务IP来承接所有外部请求。
这类设备最大的优势就是性能强悍且稳定，它依靠专用ASIC芯片处理四层流量转发，单台设备支持百万级并发连接是常态，它内置了丰富的高级健康检查机制，可以自动摘除宕机的后端节点，对于银行、证券、大型央企这些对稳定性要求极高的场景，行业共识认为硬件设备在超大规模流量下的表现仍不可替代。
但它缺点也很明显：价格不菲，一套主流型号的硬件负载均衡设备，含授权和维保，预算往往在十万元到几十万元不等，而且扩容需要重新购买硬件,灵活性偏差。
软件负荷分散方案
软件负荷分散方案是目前互联网企业最流行的选择，它本质上是把负载均衡的逻辑做成了应用程序，安装在普通的X86服务器上,主流的软件方案有：
- Nginx：七层负载均衡的绝对主力，基于Http协议转发，擅长处理Web静态资源、反向代理和缓存,配置语法简单易上手。
- LVS（Linux Virtual Server）：工作在四层的内核级负载均衡方案，转发性能极高，常被用来承载数据库、缓存等内部服务的流量入口。
- HAProxy：兼具四层和七层能力，特别擅长处理TCP层面的负载均衡,对会话保持和访问控制的支持非常细腻。
软件方案天生自带成本优势，你只需要准备两台普通机架式服务器（一台主、一台备），安装开源软件即可开始工作，整套硬件成本可能不到两万元，软件本身免费，而且无论流量涨多少倍，加机器水平扩容就行，这正是中小型团队青睐它的核心原因，在上海、杭州的创业园区里，大量技术团队都用“两台Nginx + Keepalived”的组合扛住几十万日活用户的访问压力。
云负载均衡服务
如果你把系统搭在公有云上，那直接用云厂商的负载均衡服务最省心，简米云叫SLB（Server Load Balancer）、酷番云叫CLB（Cloud Load Balancer）、华为云叫ELB（Elastic Load Balancer）。
云负载均衡最大的价值在于零运维，你不需要关心底层机器装了什么系统、硬盘是否损坏，只需要在控制台里点几下创建实例，把后端服务器加入服务器组，流量就自动分发开了，它自带高可用特性，控制台里勾选多可用区部署，即使用户所在的城市机房发生断电，业务也会自动切换到另一个可用区的节点，计费方式非常灵活,大多数云厂商都提供按固定带宽或按使用流量两种计费模式。
软件负载均衡和硬件负载均衡哪个好
这是每次聊到负荷分散服务器时，用户问得最多的问题，两者没有绝对的好坏,关键看你的业务处于什么阶段。
性能与功能层面
从四层转发能力来看，硬件设备因为专用芯片的加持，纯转发吞吐量确实比普通服务器跑的软件方案要高出一截，在金融交易这类要求极低延迟的场景里,硬件设备的数据包处理时延更稳定。
但软件方案在七层应用路由能力上则扳回一城，Nginx可以用正则表达式灵活改写URL、做复杂的流量分配策略、给不同的路径设置不同的缓存规则，这类精雕细琢的应用层控制,传统硬件设备的操作界面往往难以企及。
成本与运维灵活性
| 对比维度 | 硬件负载均衡 | 软件负载均衡 |
|---|---|---|
| 初始投入 | 较高，单台设备普遍超过10万元 | 低，普通服务器即可承载 |
| 扩容方式 | 重新采购设备，周期长 | 加装服务器即可，随需扩容 |
| 配置维护 | 依赖专业网工或厂商工程师 | 运维人员通过命令行或配置脚本即可完成 |
| 高可用实现 | 设备自带双机热备协议 | 借助Keepalived或云平台实现 |
如果你问一个做了多年运维的工程师，他很可能告诉你，家里的测试环境和生产环境都在用Nginx，究其原因，大多数业务的瓶颈在于应用逻辑处理能力，而非网络层吞吐量，一台普通的双路服务器装上Nginx，轻松处理几十万并发连接,对上千万日活的产品来说绰绰有余。
高并发场景负荷分散方案怎么选
理解了类型区别，再看怎么落地，不同的业务形态,选型思路完全不同。
电商大促或直播抢购场景
这类业务的特点是流量瞬间爆发、毛刺严重，推荐架构是LVS + Nginx 双层负荷分散，最外层用LVS做四层流量入口，它抗住SYN Flood等网络层攻击，把流量快速转发给第二层的Nginx集群，再由Nginx根据业务接口的实际情况做七层路由，这种双层架构既能发挥LVS的高性能转发优势，又保留了Nginx灵活的路由规则能力，具体操作上，LVS的VIP（虚拟IP）配置在交换机上，后端负载均衡器的IP加入LVS的调度列表，期间要特别注意开启persistence_timeout参数,确保用户会话能绑定到同一台后续服务器。
数据库或内部微服务的负荷分散
这种情况推荐用HAProxy，由于数据库长连接较多、四层转发需求大于七层路由，HAProxy在TCP层做代理时能比Nginx占用更少的系统资源，很多企业的核心交易系统采用HAProxy主备模式，两台服务器之间通过心跳检测机制确认对方状态，一旦主机宕机，备用机在秒级时间内接管虚拟IP,业务无感知切换。
预算有限的中小型项目
团队刚起步，业务量一天只有几千个请求，完全没必要购买昂贵的硬件设备，直接选云负载均衡服务更合适，在简米云控制台，创建一个按量付费的SLB实例，把两台ECS服务器挂进去，连通性测试通过后即算完成搭建，按现有云厂商的市场报价，酷番云标准型CLB实例的费用通常每小时在几角钱到一元多不等，对早期项目没有财务压力，考虑到百度GEO流量做起来的网站有相当一部分部署在国内二三线城市的机房，软件负载均衡+托管服务器的组合性价比确实更高。
负荷分散配置实操要点
把设备买回来或者把服务开起来只是第一步，真正考验功力的是参数调优,这里分享三个最核心的实操要点。
健康检查参数务必合理
很多新手习惯把健康检查间隔时间设成默认值，这会导致后端服务异常时流量继续涌入故障节点，建议把健康检查间隔调整到3秒至5秒，请求超时时间设为2秒，失败几次后自动标记节点为不健康，这样即使某台后端服务器响应缓慢,也能在最短时间内被摘除。
会话保持策略要特别小心
启用会话保持意味着把相同来源的IP或相同的Cookie都固定分发到同一台后端服务器，这确实是解决登录状态丢失的好办法，但它会破坏负载均衡的公平性，如果某个办公室的出口IP用户特别多，这一台后端服务器压力就会很大，比较合理的做法是，如果项目用了Redis这类集中式缓存存放Session，那就要谨慎使用会话保持功能,让流量尽量彻底分散。
关注后端服务器的连接数上限
负荷分散服务器的价值在于把任务分下去，如果后端服务器的单机max_connections配置太低，再好的均衡器也无济于事，检查后端机器的连接数监控，如果单机连接数长期超过服务最大连接数的60%,就要考虑增加后端节点或优化连接池的复用率了。
负荷分散服务器有哪些容易踩的坑
忽略负载均衡器自身的性能瓶颈
负荷分散服务器本身也是一台机器，它有CPU、内存和网卡上限，有些团队在后端加了十几台服务器，却仍然用一台低配虚拟机跑Nginx，导致流量明明不大，但负载均衡服务器的CPU先跑满了，遇到这种情况，优先查看负载均衡设备/proc/stat或云监控里的CPU使用率指标，如果持续高于80%，先给这台机器升配,再考虑调整架构。
直接修改生产环境配置不备份
不管是用Nginx还是HAProxy，修改配置前一定要先执行配置文件语法检查，比如Nginx可以用/usr/local/nginx/sbin/nginx -t来看语法，HAProxy则用haproxy -c -f haproxy.cfg来校验,这是低成本却最有效的自我保护手段。
常见问题解答
负荷分散服务器和普通后端服务器能混用吗
不行，负荷分散服务器承载的是全站流量的分发入口，一旦宕机整个业务全部瘫痪，它必须独立部署，最好使用双机热备架构，后端业务服务器哪怕挂掉一台，只会损失一部分容量,二者承担的风险级别截然不同。
用了云负载均衡还需要自己装Nginx吗
视情况而定，如果你的系统直接暴露HTTP接口供外部调用，那么用云负载均衡器提供稳定的公网入口和SSL证书卸载就足够了，但如果后端是多个微服务组成的集群，需要在入口处统一处理跨域、鉴权、路径改写等复杂逻辑，那建议保留一层Nginx做反向代理，同时在Nginx之上挂载云负载均衡服务,形成双层保护。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/785096.html
