什么是负载均衡?基础概念一次讲清

流量突然暴涨,网站却没有崩溃——负载均衡器到底是怎么决定把请求发到哪台服务器的。

什么是负载均衡

负载均衡是把涌入的流量分散到多台服务器上,而不是全部压给一台,这样单台服务器过载或宕机就不会拖垮整个服务。负载均衡器位于服务器集群前端,接收所有请求,并把每个请求转发给当下最合适处理它的服务器。

轮询(Round Robin)方式

最简单也最常见的分配方式:请求按固定顺序依次分配给A、B、C服务器,再回到A。实现简单,适合各服务器性能相近的场景,但没有考虑到某些服务器可能已经比其他服务器更忙。

最少连接数方式

不再机械轮询,而是把新请求发给当前活跃连接数最少、也就是最空闲的服务器。当各请求的处理时间差异很大(比如夹杂着耗时的文件上传)时,这种方式比轮询能实现更均衡的分配。

IP哈希(会话保持)方式

根据客户端IP地址计算哈希值,始终把同一客户端的请求发送到同一台服务器。如果登录状态只保存在某一台服务器的内存中,不使用IP哈希就可能因为后续请求被分配到别的服务器而导致用户掉线。缺点是如果很多用户共用同一个IP(比如同一公司的网络),可能会让某台服务器负载过重。

四层(L4)与七层(L7)负载均衡器的区别

四层(传输层)负载均衡器只查看IP地址和端口等网络层信息,处理速度快,但只能按简单规则分流。七层(应用层)负载均衡器可以解析请求的实际内容,比如URL路径或浏览器类型,把“/images”和“/api”的流量分别导向不同的服务器组,这对按功能拆分的微服务架构尤其有用。

健康检查

负载均衡器会定期向每台服务器发送探测请求或调用专门的状态检查接口,确认其是否正常响应。一旦某台服务器无响应或持续报错,就会被自动、暂时地从分配池中剔除,避免用户看到故障,待其恢复后再重新加入。

负载均衡器与CDN的关系

负载均衡器通常在同一数据中心内的服务器之间分配流量,而CDN(内容分发网络)则把流量分散到分布在全球各地的边缘节点。大型服务通常两者结合使用:CDN先把请求导向最近的区域,该区域内再由负载均衡器把流量细分到具体的服务器。

负载均衡与自动伸缩的配合

在云环境中,流量激增会触发自动伸缩机制自动新增服务器实例,负载均衡器随即开始把流量导向这些新实例。流量回落时,多余的实例又会被自动缩减以节省成本,这两项技术在云基础设施中经常配合使用。

轮询之外的负载均衡算法

轮询和最少连接数只是最常见的起点,生产环境中往往会在此基础上进一步优化:加权轮询会给性能更强的服务器分配更多请求;最短响应时间会参考服务器近期的响应速度;一致性哈希则大量用于缓存层,即便服务器被增减,同一个键也几乎总能映射到同一台服务器上。

云原生架构下的负载均衡

如今的负载均衡往往不止依赖单一的专用设备,而是同时发生在多个层级:云厂商提供的托管负载均衡器位于整个应用前端,Kubernetes集群内部由Ingress控制器分发流量,服务网格则负责内部各微服务之间的负载均衡。每一层解决的都是同一个基本问题——不让任何一个实例过载,只是作用的范围不同。

常见问题

负载均衡器本身出故障了怎么办?

为避免负载均衡器本身成为单点故障,实际部署中通常会运行至少两台负载均衡器,采用主备或双活模式,一台出问题时另一台可以无缝接管流量。

小型网站也需要负载均衡吗?

如果单台服务器就能轻松应对流量,暂时不需要。但一旦流量增长到需要多台服务器分担的程度,负载均衡器就成为必需品,因为没有其他方式能把流量分发到多台服务器上。