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