服务器负载均衡（Server Load Balancing，SLB）与全局负载均衡（Global Server Load Balancing，GSLB）虽然都带负载均衡四个字，但处理流量的层次和决策逻辑差别很大。简单说，SLB解决的是同一集群内流量怎么分给多台机器，GSLB解决的是用户请求应该进哪个集群或哪个机房。理解这个前提后，再去看两者的配置方式、健康检查和故障切换行为，会清晰很多。
一、作用范围：集群内部调度与跨地域调度
服务器负载均衡通常工作在单个数据中心内部。它的核心任务是把访问某个虚拟IP或域名的流量，按照既定策略分发到后端的真实服务器池。比如一个电商网站的订单服务部署了50台虚拟机，前置一台Nginx或云厂商的SLB，所有请求先打到负载均衡器，再由它转发给某一台健康的后端节点。这个层面的调度目标是让单台服务器压力均衡，同时在后端某台机器故障时自动摘除，不影响整体可用性。SLB的视野局限在一个机房内，它不知道另一个城市的机房是否空闲、哪条运营商链路更顺畅。
全局负载均衡的视野则大得多。它通常在DNS解析阶段介入，也可以结合HTTP重定向或IP Anycast实现。当用户在浏览器输入域名后，GSLB会根据用户来源IP、运营商、各机房实时健康状态以及预设的调度策略，返回一个最合适的机房入口IP。举例来说，同样一个域名，广东移动用户可能被解析到广州机房的入口，北京联通用户则解析到北京机房。GSLB的目标不是把请求分给某一台服务器，而是先决定流量进入哪个数据中心、哪条入口线路，后续再由该机房的SLB继续做细粒度分发。
所以两者是上下游关系而不是替代关系。一个完整的高可用架构通常是用户请求先经过GSLB选机房，再经过机房内SLB选服务器。只配置SLB能防单机故障，但防不了整个机房断电或链路中断；只配置GSLB能做到跨机房调度，但流量进入机房后如果没有SLB，仍可能压垮单台入口节点。
二、健康检查与故障切换的粒度不同
SLB的健康检查对象是具体的后端服务器。常见的检查方式包括TCP三次握手探测、HTTP状态码检查，或者自定义请求某个接口判断返回内容。检查频率通常很高，可以做到秒级甚至亚秒级。一旦某台后端连续几次探测失败，SLB会把这台机器从转发列表里摘掉，新连接不再发给它，同时对已有长连接的处理取决于具体实现。这个过程对客户端基本透明，因为入口IP或域名没有变化。
GSLB的健康检查则更复杂，它要判断的不是某台服务器是否活着，而是某个机房入口、某条链路甚至某个运营商线路是否可用。GSLB节点可能同时探测多个数据中心的入口IP、HTTPS证书是否有效、关键业务接口是否返回预期内容。它的检查间隔通常比SLB长，可能是10秒、30秒甚至更久。当某个机房整体不可用时，GSLB会把原本指向该机房的A记录切换到另一个机房。但这里有一个关键限制：DNS解析结果会被用户本地DNS、浏览器或操作系统缓存，切换后部分用户可能仍然访问旧地址一段时间，直到缓存过期。因此GSLB的故障切换往往不是瞬间完成，实际收敛时间受TTL设置影响很大。
从运维角度看，SLB的摘除动作影响范围小，可以频繁触发；GSLB的切换影响整个区域流量，通常要配合更谨慎的策略，比如设置触发阈值、避免因为短暂网络抖动就大范围迁移。两者在告警和自动化处理上也需要分开设计。
三、实现层级与常见技术方案
服务器负载均衡常见实现有软件和硬件两类。软件方案包括Nginx、HAProxy、LVS、Envoy等，硬件方案有F5、A10等。按照工作层级又分为四层负载均衡和七层负载均衡。四层基于IP和端口转发，性能高但只能看到连接信息；七层能解析HTTP头、Cookie、URL路径，可以做更灵活的会话保持和内容路由。云厂商提供的SLB通常把四层和七层能力封装在一起，用户创建监听器时选择协议即可。Nginx作为七层反向代理的典型配置如下：
upstream backend_pool {
server 192.168.1.11:8080 weight=3 max_fails=2 fail_timeout=10s;
server 192.168.1.12:8080 weight=1 max_fails=2 fail_timeout=10s;
keepalive 32;
}
server {
listen 80;
server_name api.ipipp.com;
location / {
proxy_pass http://backend_pool;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
这段配置里，upstream定义了两个后端节点，weight控制权重，max_fails和fail_timeout控制健康检查失败后的摘除行为。所有请求进入Nginx后，根据location规则转发给后端池，这就是典型的SLB工作方式。
全局负载均衡的实现主要依赖智能DNS。传统DNS只能返回固定解析结果，GSLB则会在权威DNS服务器上增加策略引擎，根据请求来源IP所属的地理位置或运营商返回不同答案。比如网宿、阿里云全局流量管理、腾讯云DNSPod等产品都提供类似能力。另一种方式是HTTP重定向：用户先访问一个固定入口，GSLB根据策略返回302跳转到某个机房域名，但这种方式会增加一次请求，且对非浏览器客户端不够友好。还有IP Anycast方案，多个机房对外宣告相同IP地址，依靠BGP路由把用户请求导到最近的机房，切换速度快但部署和运维门槛较高。
DNS方式的配置通常表现为策略规则，例如：
规则1：用户来源属于中国电信，且华南地区，返回广州机房入口 1.1.1.1 规则2：用户来源属于中国联通，且华北地区，返回北京机房入口 2.2.2.1 规则3：默认返回距离用户最近的可用机房入口
从协议角度看，SLB大多处理的是已经到达负载均衡器的TCP或HTTP请求，可以实时修改转发目标；GSLB则更多在用户发起连接前通过DNS应答影响目标地址。这种时序差异也决定了SLB能更快响应后端变化，而GSLB更擅长根据地理位置和全局容量做规划。
四、常见问题解答汇总
问题一：有了GSLB还需要SLB吗？答案是绝大多数情况下需要。GSLB把流量引导到某个机房后，该机房内部仍然可能有几十上百台服务器需要分摊请求。如果没有SLB，入口节点会变成单点，既无法横向扩展，也无法在高并发下保护后端。两者配合才能同时获得跨机房容灾和单机房弹性伸缩能力。
问题二：为什么GSLB切换后，有用户还是访问旧机房？主要原因是DNS缓存。用户的本地DNS服务器、操作系统和浏览器都可能缓存旧的A记录，TTL设得越长，切换生效越慢。为了加快切换，可以把TTL调低到60秒甚至30秒，但这会增加DNS查询量。另一种做法是配合HTTP重定向或客户端重试机制，在应用层做二次纠偏。
问题三：服务器负载均衡能当全局负载均衡用吗？理论上可以把多个机房的入口IP都配置在同一个SLB后端池里，让SLB跨公网转发。但这样会把所有流量先集中到一个机房的SLB节点，再转发到其他机房，既增加延迟又浪费带宽，还让SLB本身成为跨地域故障的集中点。不建议用SLB代替GSLB。
问题四：什么规模才需要上GSLB？如果业务只部署在单机房，或者用户集中在某个区域，暂时不必引入GSLB。当出现多机房部署、异地容灾、多运营商接入、全球用户访问等需求时，GSLB的价值就会非常明显。判断标准不是服务器数量，而是是否存在多个物理入口需要统一调度。
问题五：两者在成本上差多少？SLB成本相对较低，软件方案甚至零许可费用，云上按实例或流量计费。GSLB因为涉及权威DNS、多节点探测、策略管理，价格通常更高，但如果自建智能DNS也可以用Bind加脚本实现基础功能。实际选型时要结合切换速度要求、运维能力和预算综合评估。