单机承载能力总有上限，垂直扩展很快会遇到瓶颈，无法满足高并发、高吞吐量的业务场景。这时候我们通常会选择水平扩展，也就是增加机器数量。但现实往往很骨感：不同机房、同机房不同年代上架的服务器性能千差万别。甚至有时候业务申请到的 8 核 16G 内存配置脱销了，只能退而求其次选择 4 核 8G 的服务器。这就注定了不同的服务器所能承担的吞吐量不一样。
问题随之而来：一只木桶能盛多少水，并不取决于最长的那块木板，而是取决于最短的那块。幸运的是，负载均衡算法的出现有效解决了这个问题。
负载均衡本质上是一种将数据流量按需分配给后端服务器去响应的机制。常见的算法包括简单轮询、加权轮询、粘性 Session（一致性哈希）、最少连接数等。本文不打算深入讲解这些算法的具体原理，而是从实践出发，聊聊它到底解决了哪些痛点。
为什么需要负载均衡？不仅仅是削峰填谷
很多人认为负载均衡的好处仅仅是减少机器性能差别产生的'木桶效应'，答案肯定是否定的。
不少运营商和公司的办公职场都会将域名解析的结果进行缓存，以减少递归查询的开销。然而，DNS 缓存的时间是我们不可控的。当我们急需修改解析记录止损时，并不能立即生效，效果往往差强人意。
有了负载均衡就不一样了。我们将域名通过 A 记录解析到负载均衡节点上，也就是 VIP（Virtual IP Address）节点，再由 VIP 节点转发到后端的实例上。当需要变更分流规则时，只需要变更负载均衡的路由映射信息就能立即见效，无需等待 DNS TTL 过期。
在京东这类大型平台，一个域名背后通常对应着成百上千个后端服务节点。如果没有统一的流量入口管理，客户端直接请求后端 IP，不仅难以维护，一旦某台机器故障或扩容，前端接入方就得频繁更新配置。负载均衡层屏蔽了这些细节，让上层调用变得透明且稳定。
