slb负载均衡是干什么的

你网购下单那一刻，载均请求其实先撞上一台名叫SLB的衡干机器。这台机器不存商品数据，载均也不跑业务代码，衡干它只干一件事：把请求分发给后面一堆真正的载均服务器。

没有它，衡干网站会怎样？载均想象一下双十一零点，十万个用户同时点结算。衡干如果只有一台服务器，载均它瞬间就被打爆，衡干页面转圈，载均然后报错。衡干可如果背后有十台服务器呢？载均问题是，用户不知道它们的衡干存在，他们只知道一个网址。载均SLB就是那个站在十台服务器前面的门卫，把涌来的请求均匀地推进每台服务器。

分配这事看着简单，里头有讲究。最笨的办法是轮流来，第一个请求给服务器A，第二个给B，第三个给C，转圈发。这叫轮询，适合每台服务器性能差不多的场景。可要是服务器配置不一样呢？一台是32核，另一台是4核，轮询就会让弱的机器累死，强的机器闲着。所以SLB支持加权轮询，强的多分点，弱的少分点。

还有更聪明的做法——按连接数分配。谁当前处理的请求少，就把新请求发给谁。这有点像餐厅门口排号的服务员，看见哪桌快吃完了，就往后厨多催两道菜。实际效果比轮询更平滑，尤其适合请求处理时间忽长忽短的业务。

但SLB真正的本事不在分发，而在“感知故障”。后端某台服务器突然宕机了，或者代码出bug导致接口一直返回500错误，SLB会在健康检查中发现它出问题，然后自动把它从分发列表里摘掉。用户毫无感知，请求只会发给还活着的机器。等这台机器恢复了，SLB又把它加回来。

我见过一个真实案例。某创业公司半夜上线新版本，代码有内存泄漏，两台后端服务器轮流崩溃。要是没有SLB，网站早就彻底瘫了。可因为SLB持续健康检查，每次崩溃后30秒内就把流量切走，用户最多觉得某次操作稍慢，没人知道背后已经经历了两轮生死交替。这玩意儿就像电网里的保险丝，平时没人注意，但短路时它扛下了所有。

有人会问：那SLB自己挂了怎么办？这问题问到点子上了。单台SLB也会成为单点故障，所以生产环境通常部署一主一备，用虚拟IP对外提供服务。主节点心跳检测到备节点活着，备节点随时准备接管。切换过程对用户是透明的——他们访问的IP没变，只是背后处理请求的软件换了个进程而已。

还有个容易忽略的细节：SLB能终止SSL加密。用户和网站之间的HTTPS握手如果每次都落到后端服务器，每台机器都要维护证书私钥，既浪费CPU又增加管理成本。SLB统一把加密流量解密，再通过内网明文转发给后端，后端只处理业务逻辑，不用管加密那摊事。内网传输本身是可信的，这么做安全风险可控，而性能提升是实打实的。

到了云时代，SLB变得更“狡猾”了。它不只分发流量，还能根据URL路径做路由——比如把/api/开头的请求转到后端A组，把/page/开头的转到B组。更狠的是，它能识别用户会话，同一个用户的请求始终发给同一台服务器，保证session不丢。这叫会话保持，电商网站的购物车就靠它撑着。

说到底，SLB承担的是“入口控制”的角色。它把复杂的后端集群包装成一个稳定、单一的访问入口，让客户端不需要知道背后有多少台机器在干活。这就像公司前台——访客只看到前台一个人，实际上背后有销售部、技术部、行政部几十号人。前台倒了，访客就不知道该找谁。SLB就是那个永远不能倒的前台。