上一章我们接头了正向署理的根基道理。正向署理的进程，是埋没了真实请求的客户端，处事端不知道真实的客户端是谁。客户端请求的处事都被署理处事器取代来请。而反向署理埋没了真实的处事端，当客户端提倡处事请求的时候，会先抵达署理处事器，有署理处事器抉择真实的响应处事器。因此，两者的焦点差别在于：正向署理，署理的是客户端；反向署理，署理的是处事端。以下为反向署理的网络模子图：

简而言之，上面这个模子：Server通过中间的proxy将自身的处事暴漏出去给客户端会见的进程，从学术上讲，被称之为反向署理。

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

为了办理这两个显而易见的问题，就需要提出一种可以横向拓展的陈设架构，使得处事可以支撑的请求量，可以或许跟着处事的横向拓展而增加。因此衍生出了如下的陈设架构模子：

基于NGI的构思，DSP Labs正在尽力构建下一代漫衍式存储的生态体系。可以预见的，在这个生态中，将会有大量的局域网节点参加到生态建树中来。为了可以或许让这些局域网内部的节点，可以流通的对外提供数据请求处事，DSP Labs提供了反向署理的本领。同时为了更好的共同数据正当性禁锢的诉求，我们在署理协议中，适当插手了数据流审核的本领。

道理

反向署理

对付请求量很是少的处事，这样的陈设不会有什么问题，但假如这个处事请求量上来的时候，这样陈设的架构就很有问题了。详细表示为：

2.?????? 假如处事Server单节点产生了妨碍，就一定会影响整个处事。

概述

在这个陈设的架构傍边，除了Server节点，还多出了一个叫“Proxy”的节点。“Proxy”的这个节点，它把他吸收的所有的请求都转发到他后头的Server节点傍边，然后期待Server节点处理惩罚请求，再从Server节点取回执行功效返回到Client。所以“Proxy”的这个节点，他实际上不处理惩罚任何的请求，只是做请求及数据的转发。

通过这个扩展架构，，单点处事中提到的两个漏洞，很容易被办理掉。针对第一点：当个中的server1处事满载的时候，proxy可以按照其处事调治算法，将其余的请求分派到server2可能server3上；针对第二点：当某一个处事呈现妨碍时，基于proxy和server间的保活机制，可以很容易感知。因此，可以将处事请求调治到其它的server上。

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

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。