反向代理

上一章我们讨论了正向代理的基本原理。正向代理的过程，是隐藏了真实请求的客户端，服务端不知道真实的客户端是谁。客户端请求的服务都被代理服务器代替来请。而反向代理隐藏了真实的服务端，当客户端发起服务请求的时候，会先抵达代理服务器，有代理服务器决定真实的响应服务器。因此，两者的核心差异在于：正向代理，代理的是客户端；反向代理，代理的是服务端。以下为反向代理的网络模型图：

?

为了说清楚什么是反向代理，我们就需要先从最简单的C/S架构说起。C/S架构，也即是Client-Server的架构。而最简单的C/S架构，也即是以单个节点作为后端Server的C/S架构。下图为一个简单的部署架构图：

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

1.?????? 从服务器的物理特性来看，这个服务器就不能支持这么高的请求量。

2.?????? 如果服务Server单节点发生了故障，就必然会影响整个服务。

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

在这个部署的架构当中，除了Server节点，还多出了一个叫“Proxy”的节点。“Proxy”的这个节点，它把他接收的所有的请求都转发到他后面的Server节点当中，然后等待Server节点处理请求，再从Server节点取回执行结果返回到Client。所以“Proxy”的这个节点，他实际上不处理任何的请求，只是做请求及数据的转发。

通过这个扩展架构，单点服务中提到的两个弊端，很容易被解决掉。针对第一点：当其中的server1服务满载的时候，proxy可以根据其服务调度算法，将其余的请求分配到server2或者server3上；针对第二点：当某一个服务出现故障时，基于proxy和server间的保活机制，可以很容易感知。因此，可以将服务请求调度到其它的server上。

简而言之，上面这个模型：Server通过中间的proxy将自身的服务暴漏出去给客户端访问的过程，从学术上讲，被称之为反向代理。

基于NGI的构想，DSP Labs正在努力构建下一代分布式存储的生态体系。可以预见的，在这个生态中，将会有大量的局域网节点参与到生态建设中来。为了能够让这些局域网内部的节点，可以流畅的对外提供数据请求服务，DSP Labs提供了反向代理的能力。同时为了更好的配合数据合法性监管的诉求，我们在代理协议中，适当加入了数据流审核的能力。