三分钟了解DSP(网络篇)—— Proxy(下)

DSP 发布在 海盗号 13095

概述

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

 

原理

为了说清楚什么是反向代理,我们就需要先从最简单的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提供了反向代理的能力。同时为了更好的配合数据合法性监管的诉求,我们在代理协议中,适当加入了数据流审核的能力。

本文链接:https://www.8btc.com/media/631857
转载请注明文章出处

文章标签: 去中心化域名
评论
登录 账号发表你的看法,还没有账号?立即免费 注册