负载均衡器(Load Balance,下文简称 LB)更像是一个请求调度中心,主要是为了分发请求。这一角色使得它可以
•避免请求分配到不可用的服务器,例如发送心跳感知服务器在线情况•避免服务器过载,例如实现一个简单的请求计数器或者统计请求的响应时间等。•解决单点问题,实现水平扩展•根据请求类型分配指定的服务器(例如静态文件分配给 CDN、读写或冷热分离等)
负载均衡器可以工作于两层, L4 TCP[1] 层或者 L7 应用层。
工作于传输控制协议层意味着 LB 只获取 TCP 表头的基本信息:来源 IP、目的 IP 等,请求体的内容对 LB 是透明的,也就是说 LB 看不到请求的内容,只知道它从何处来要往何处去,带了多重的“行李”。
L4 层的 LB 可以实现简单的轮询、随机、或者基于 IP 的地理位置请求分发。
工作于应用层,例如最常用的 HTTP 协议层,则可以根据 HTTP 的方法、URL、版本、HTTP 头部信息甚至是根据请求体的内容,请求体都需要过 LB 这个安检机器,LB 知道“行李”装的是什么。
当然,它的行程和重量,LB 也一清二楚(即实际上 LB 同时工作于 L4 和 L7 层)。
工作于 L7 层相比于 L4 层会更损耗性能,但在今天这个性能过剩的时代,这点损耗是可以接受的。
有了这个能力,LB 可以:
•根据请求方法、类型分配指定的服务器•根据会话信息分配给保存相应会话的服务器,用户就可以不必重新登录•充当 SSL 端点(Termination)LB 背后的服务器就不必每一个都去搭建相同的 SSL 环境了。
诶?等等,SSL 端点功能不是反向代理的吗?
没错,反向代理的功能也被融入在负载均衡器中,这才使得有些人分不清二者的区别。
负载均衡器是为了分配请求、解决单点问题而生的,因此负载均衡器必须是两个或以上才有意义。而反向代理一个服务器也可以。
反向代理有点类似设计模式的外观模式(Facade Pattern)[2],这个设计模式可以隐藏系统的复杂性,提供统一的接口。
类似的,反向代理只需要向客户端提供一个统一的地址。这样设计的好处是:
•提高安全性 —— 统一的入口使得后端服务器的 IP 不会暴露在公网上,客户端只需要与代理服务器打交道。DDoS 攻击的处理、IP 黑名单等交由反向代理负责,反向代理可以从源头限制后端服务器可以接受的连接数量
•提高扩展性和灵活性—— 统一的入口使得后端架构对客户端是不可见的,你可以替换服务器来维护集群的健康、根据访问量增删服务器来实现弹性负载均衡。没错,这里的功能与 LB 相辅相成。
既然是代理,请求的整个过程对反向代理都是可见的,因此反向代理可以实现:
•承担请求的解压缩,类似单一职责原则的设计,解压和压缩都由反向代理来实现。•SSL 端点,扩展服务器时就不需要搭建 SSL 服务了。•请求返回的缓存,对于不需要专用 CDN 的网站,反向代理也实现了请求加速的功能。
总结一下,负载均衡器更关心请求如何分发,只有服务器不少于两个才有意义。
反向代理提供请求的统一入口,也可以控制请求的返回。只有一台服务器也可以实现它的功能。
1.Http 消息 - Mozilla[3]2.What Is Layer 4 Load Balancing? - NGINX[4]3.What is a Reverse Proxy vs. Load Balancer? - NGINX[5]
[1]
TCP: https://en.wikipedia.org/wiki/Transmission_Control_Protocol
[2]
外观模式(Facade Pattern): https://en.wikipedia.org/wiki/Facade_pattern
[3]
Http 消息 - Mozilla: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Messages
[4]
What Is Layer 4 Load Balancing? - NGINX: https://www.nginx.com/resources/glossary/layer-4-load-balancing/
[5]
What is a Reverse Proxy vs. Load Balancer? - NGINX: https://www.nginx.com/resources/glossary/reverse-proxy-vs-load-balancer/
图片来源:https://refactoring.guru/design-patterns/facade