网络：反向代理和负载均衡有何区别？

反向代理与负载均衡的区别

做了反向代理才能实现负载均衡。负载均衡是做反向代理的目的之一。

引入

刚开始时，网站会是以单个节点作为后端Server的C/S架构。

对于请求量非常少的服务，这样的部署不会有什么问题，但如果这个服务请求量上来的时候，这样部署的架构就很有问题了。

首先一个很客观的问题就是，如果单从服务器的物理特性来看，这个服务器就不能支持这么高的请求量。这种情况下，就迫使开发者去把服务迁移到一个CPU更强、内存更高，综合性能更好的服务器。通过更换服务器当然可以解决这个问题，在不考虑成本的条件下，总可以找到性能更好的服务器来替换原来的服务器以支撑服务，但这种理想的条件不在本文考虑范围之内。

第二个问题就是，如果服务Server单节点发生了故障，就必然会影响整个服务，因为对于众多的Client客户端都是连接的一个Server服务端，如果这个节点不可用了，势必会影响所有使用了客户端的用户。

为了解决这两个显而易见的问题，就必须提出一种可以横向拓展的部署架构，使得服务可以支撑的请求量可以随着服务的横向拓展而增加。因而就催生了如下的部署架构：

在这个部署的架构当中，除了Server节点，还多出了一个叫“Proxy”的节点，那么这个节点是干嘛的呢？

“Proxy”的这个节点，它把他接收的所有的请求都转发到他后面的Server节点当中，然后等待Server节点处理请求，再从Server节点取回执行结果返回到Client。所以“Proxy”的这个节点，他实际上不处理任何的请求。

我们先来看这样子的架构怎么解决了以上的问题

首先是第一个问题，服务器性能不足的问题，这个架构如何解决性能不足的问题呢？在这个架构里面，假设Server节点S1性能到达瓶颈了，不能处理更多的请求了。如果采用上面的这个架构，那么我们可以添加Server节点S2，同时告诉“Proxy”节点，让他把部分原来转发到S1节点的请求转发到我这里来。这样子通过服务分流减少压力的方法就可以解决原来S1节点性能不足的问题了。

接着是第二个问题，单点服务器挂掉了怎么办。还是考虑Server节点S1和S2，两者所能够提供的服务是一样的，假设某一个时候S1挂掉了，这时如果有“Proxy”节点的存在，并且“Proxy”节点能够察觉到S1挂掉了的话，那么让“Proxy”节点把原来要转发给S1节点的请求转发到S2进行处理就可以了，这样子通过服务冗余的方法就可以解决原来S1突然挂掉影响服务的问题。

解决了这两个问题，接下来我们再从这两个问题里面“Proxy”的角色来理解，什么叫做代理。

在第一个问题里面，“Proxy”节点通过服务分流的方法来减少S1的压力，对于原来应该被S1服务的，却由于被“Proxy”节点转发而被S2服务的Client而言，Client他并不知道实际上是由S1处理的还是S2处理的，Client拿到的是一个从“Proxy”节点返回的结果，换言之，Client并不知道自己的请求实际上是被哪个处理的，他只需要往“Proxy”节点发送请求就好了，剩下的工作就由“Proxy”节点去解决。

也就是，“Proxy”节点相当于一个中介，或者说是一个代理，代理Client去寻找实际的Server节点去完成服务。这样子的模式在现实生活也非常常见，在买房子的时候，通常由房产中介帮助你完成和卖者之间的手续，而不需要你亲自去处理这些事情，你只需要协调好自己与中介之间的手续就好了，这里的中介，就和我们的“Proxy”节点所做的工作非常类似。

同样的，在第二个问题里面，也是相似的理解方式，Client并不需要感知S1是否还能正常工作，Client只需要把请求发送给“Proxy”节点，由它去帮忙处理就可以了。

因此，这里面的“Proxy”节点，也就是我们的代理节点。

那么，代理到底要发给哪个服务器呢？这就涉及到了负载均衡

负载均衡器

负载均衡器（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 端点功能不是反向代理的吗？

没错，反向代理的功能也被融入在负载均衡器中，这才使得有些人分不清二者的区别。

负载均衡器是为了分配请求，解决单点问题而生的，因此负载均衡器必须是两个或者以上才有意义。而反向代理一个服务器也可以

反向代理

反向代理有点类似于设计模式的外观模式，这个设计模式可以隐藏系统的复杂性，提供统一的接口

类似的，反向代理只需要向客户端提供一个统一的地址。这样设计的好处是：

• 提高安全性：统一的入口使得后端服务器的IP不会暴露在公网上，客户端只需要于代理服务器打交道。DDos攻击的处理、IP黑名单等交给反向代理负责，反向代理可以从源头限制后端服务器可以接收的连接数量
• 提高扩展性和灵活性：统一的入口使得后端架构对客户端是不可见的，你可以替换服务器来维护集群的健康、根据访问量增删服务器来实现弹性负载均衡。没错，这里的功能与 LB 相辅相成。

既然是代理，请求的整个过程对反向代理都是可见的，因此反向代理可以实现：

• 承担请求的解压缩：类似单一职责原则的设计，解压和压缩都由反向代理来实现。
• SSL端点：扩展服务器时就不需要搭建 SSL 服务了。
• 请求返回的缓存：对于不需要专用 CDN 的网站，反向代理也实现了请求加速的功能。

总结

总结一下，负载均衡器更关心请求如何分发，只有服务器不少于两个才有意义。

反向代理提供请求的统一入口，也可以控制请求的返回。只有一台服务器也可以实现它的功能。

参考

• 反向代理
• 区别