当前位置:网站首页>全面深入了解什么是反向代理和负载均衡

全面深入了解什么是反向代理和负载均衡

2022-08-10 02:56:00 努力努力再努力c.

前言
在讲反向代理之前,我们先认识一下什么是正向代理,也就是我们平常所说的代理。具有正向代理作用的服务器即一台位于客户端和目标资源服务器之间的服务器,为了从目标资源服务器获得,客户端向代理服务器发送一个请求并指定访问目标资源服务器,然后代理服务器向目标资源服务器转交请求并将获得的内容返回给客户端。
举个抽象例子
假设A和C是同学,但并不是很熟,A向C借钱,被C拒绝了;
此时A联系了B,B是A的好朋友,B也是C的好朋友;
于是B向C借了钱并且给了A;
此时A拿到了C的钱,但C并不知道他的钱借给了A;
这时B同学就扮演了一个非常关键的角色——即代理,也就是正向代理。
举个现实例子:
上面的A就是我们自己,B就是VPN,C就是谷歌。
平常我们访问谷歌www.google.com是不是都会被拒绝,但是我们挂个VPN即我们常说的“梯子”,是不是就可以成功访问了。其实VPN在这里面就是发挥了正向代理的作用。
一句话总结正向代理的本质、作用:它隐藏了真实发起请求的客户端,即服务端不需要知道来请求我的真实客户端是谁,客户端请求的服务都由代理服务器来代替自己请求。

正文
一、反向代理
前面我们已经了解什么是正向代理了,那反向代理想必大家心里都有自己的答案了。
什么是反向代理
反向代理是指以代理服务器来接收用户的访问请求,然后将请求转发给内部网络上的目标资源服务器,并将从目标资源服务器上得到的结果返回给发起该请求的用户,此时该反向代理服务器对外就表现为一个节点服务器。
反向代理服务器也同样位于用户与目标资源服务器之间,但是对于用户而言,反向代理服务器就相当于目标资源服务器,也就是说用户直接和反向代理服务器进行通信,也就意味着用户发起访问请求,在进行服务器域名解析后得到的IP,其实就是反向代理服务器的IP,而不是目标资源服务器的IP,即用户直接访问反向代理服务器就可以获得目标资源服务器的资源了。这样用户也就不需要知道目标资源服务器的IP地址,也无须在用户端作任何设定了。反向代理服务器通常可用来作为Web加速,即使用反向代理作为Web服务器的前置机降低网络和服务器的负载,提高访问效率。

举个例子
我们平时访问百度www.baidu.com,它背后有成百上千个服务器为我们服务,但具体是哪一台为我们服务,我们并不知道,也不需要知道。我们只需要知道反向代理服务器是谁,就能让它帮我们拿到我们想要的资源了。
这里www.baidu.com对应的IP地址其实就是反向代理服务器的IP,也就是说用户去访问反向代理服务器,然后由这个反向代理服务器去帮我们从目标资源服务器获取资源。

一句话总结反向代理的本质、作用:它隐藏了真实响应请求的服务端,即客户端不需要知道向哪个目标资源服务器发起请求,客户端只需要知道反向代理服务器的IP,然后让它去帮我们请求目标资源服务器的资源。

二、正向代理与反向代理的区别
二者的本质区别在于代理的对象不一样,正向代理代理的是客户端的用户,反向代理代理的是服务端的服务器。
在这里插入图片描述
由上图,我们会发现:
正向代理中,代理服务器Proxy和客户端Client同属一个LAN,对服务端Server透明。
反向代理中,代理服务器Proxy和服务端Server同属一个LAN,对客户端Client透明。
在两种代理方式中,代理服务器Proxy其实都是起到一个接收请求、转发请求并传递响应结果的作用。只不过是在两种代理方式中,代理的对象不同罢了。
三、负载均衡
什么是负载均衡
负载均衡(Load Balance)通常是指,将请求或者数据均匀分摊到多个操作单元上执行,也就是说负载均衡的关键在于均匀
负载均衡的实现
常见互联网分布式架构分为客户端层、反向代理nginx层、站点层、服务层、数据层。可以看到,每一个下游都会被多个上游调用,只需要做到,每一个上游都均匀访问每一个下游,就能实现将请求或者数据均匀分摊到多个服务模块上执行。
(1)客户端层->反向代理层
客户端层到反向代理层的负载均衡,是通过DNS轮询实现的:DNS-server对于一个域名配置了多个解析ip,每次DNS解析请求来访问DNS-server,会轮询返回这些ip,保证每个ip的解析概率是相同的。这些ip就是nginx的外网ip,以做到每台nginx的请求分配也是均衡的。
(2)反向代理层->站点层
反向代理层到站点层的负载均衡,是通过nginx实现的。通过修改nginx.conf,可以实现多种负载均衡策略:
①轮询(默认)
​ 每个web请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。

upstream nginxDemo {
    
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
}

②最少链接
web请求会被转发到连接数最少的服务器上。

upstream nginxDemo {
    
    least_conn;
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
}

③weight权重
指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况,weight默认是1。

#服务器A和服务器B的访问比例为21;比如有3个请求,前两个会访问A,第三个访问B,其它规则和轮询一样。
upstream nginxDemo {
    
    server 127.0.0.1:8081 weight=2; #服务器A
    server 127.0.0.1:8082; #服务器B
}

④ip_hash
​ 每个请求按访问ip的hash值分配,这样同一客户端连续的Web请求都会被分发到同一服务器进行处理,可以解决session的问题。当后台服务器宕机时,会自动跳转到其它服务器。
基于weight的负载均衡和基于ip_hash的负载均衡可以组合在一起使用。

upstream nginxDemo {
    
    ip_hash;
    server 127.0.0.1:8081 weight=2; #服务器A
    server 127.0.0.1:8082; #服务器B
}

⑤url_hash(第三方)
url_hash是nginx的第三方模块,nginx本身不支持,需要打补丁。
​ nginx按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存服务器、文件服务器、静态服务器时比较有效。缺点是当后端服务器宕机的时候,url_hash不会自动跳转的其他缓存服务器,而是返回给用户一个503错误。

upstream nginxDemo {
    
    server 127.0.0.1:8081; #服务器A
    server 127.0.0.1:8082; #服务器B
    hash $request_url;
}

⑥fair(第三方)
按后端服务器的响应时间来分配请求,响应时间短的优先分配。

upstream nginxDemo {
    
    server 127.0.0.1:8081; #服务器A
    server 127.0.0.1:8082; #服务器B
    fair;
}

(3)站点层->服务层
站点层到服务层的负载均衡,是通过服务连接池实现的。
上游连接池会与下游服务建立多个连接,每次请求会随机选取连接来访问下游服务。
(4)服务层->数据层
​ 在数据量很大的情况下,由于数据层(db,cache)涉及数据的水平切分,所以数据层的负载均衡更为复杂一些,它分为数据的均衡请求的均衡
​ 数据的均衡是指:水平切分后的每个服务(db,cache),数据量是差不多的;
​ 请求的均衡是指:水平切分后的每个服务(db,cache),请求量是差不多的。

常见的水平切分方式有这么几种:
①按照range水平切分
每一个数据服务,存储一定范围的数据比如
user0服务,存储uid范围1-1kw
user1服务,存储uid范围1kw-2kw
这个方案的好处是:
​ (1)规则简单,service只需判断一下uid范围就能路由到对应的存储服务
​ (2)数据均衡性较好
​ (3)比较容易扩展,可以随时加一个uid[2kw,3kw]的数据服务
不足是:请求的负载不一定均衡,一般来说,新注册的用户会比老用户更活跃,大range的服务请求压力会更大。
②按照id哈希水平切分
每一个数据服务,存储某个key值hash后的部分数据比如
user0服务,存储偶数uid数据
user1服务,存储奇数uid数据
这个方案的好处是:
(1)规则简单,service只需对uid进行hash能路由到对应的存储服务
(2)数据均衡性较好
(3)请求均匀性较好
不足是:不容易扩展,扩展一个数据服务,hash方法改变时候,可能需要进行数据迁移。

一句话总结负载均衡
负载均衡(Load Balance)通常是指,将请求或数据均匀分摊到多个操作单元上执行,负载均衡的关键在于均匀
(1)客户端层到反向代理层的负载均衡,是通过DNS轮询实现的
(2)反向代理层到站点层的负载均衡,是通过nginx实现的
(3)站点层到服务层的负载均衡,是通过服务连接池实现的
(4)服务层到数据层的负载均衡,要考虑数据的均衡请求的均衡两个点,常见的方式有按照范围水平切分hash水平切分

原网站

版权声明
本文为[努力努力再努力c.]所创,转载请带上原文链接,感谢
https://blog.csdn.net/m0_51358164/article/details/126247432