04Nginx反向代理

admin 管理员组

文章数量: 887017

目录

反向代理

网关、代理与反向代理

正向代理​

特点：

反向代理

特点：

 网关

网关的特点

​反向代理在系统架构中的应用场景

传统服务器

中小型互联网项目

负载均衡 

负载均衡的主要作用如下：

Nginx的反向代理配置

测试​

 出现的错误:

 跳转到我们本机的一个服务器上

测试 

​注意：如果配置好后未成功，可能是浏览器缓存问题。上篇有写到

基于反向代理的负载均衡器负载均衡基本配置

 测试

 负载均衡策略

轮询策略

权重

使用位置：

注意：

不常用的负载均衡策略

ip_hash

least_conn

url_hash

fair

反向代理

网关、代理与反向代理

正向代理

特点：

1.正向代理服务是由客户端设立的。

2.客户端了解代理服务器和目标服务器都是谁。

3.帮助咱们实现突破访问权限，提高访问的速度，对目标服务器隐藏客户端的ip地址

反向代理

特点：

1.反向代理服务器是配置在服务端的。

2.客户端是不知道访问的到底是哪一台服务器。

3.达到负载均衡，并且可以隐藏服务器真正的jp地址。

       用户和代理服务器划到一个圈圈里，这个外网的是外人，那这样的话我们去主动地去配置了一个代理服务器去访问外网，那我们称之为叫正向代理，是我们主动去配置的。因为我们想要去访问某些网络的时候，我们需要这个代理服务器，所以我把它给配置好，我就可以上网了对吧，正向代理是主动去配置一个代理服务器

         nginx在这里边起到代理服务器的作用。因为我们现在的这个用户包括我们机房内的网关都和我们这个 tomcat 不互通，他想要去连我们的 tomcat 连不上。那你必须得经过我这个代理服务器，我们的 nginx代理服务器你才能够访问我们这个 tomcat ，由于这个 nginx是由我们的服务提供方提供给大家的反向提供给你的，你自己访问不到，那我给你主动地去提供给你一个访问的这个入口，那这就叫反向代理。

        那如果要这么看的话，nginx就起到了这个代理服务器的作用，它们两个是一样的功能，只是你在访问网络的时候访问不到，在中间给你起一个中继传递数据的作用。
        本来你应该主动地去提供的，结果你没有或者是你没办法去提供这种访问的模式。那么反着来提供过来的这个代理服务器，这就叫反向代理。

        正向代理 和反向代理 本质上在网络拓扑上它是一样的，就是用户代理服务器和我们这个需要访问的网络

看这个代理服务器是谁提供的，就可以区分出来正向代理和反向代理服务器了

 网关

        那么网关指的是什么意思？在我们去访问互联网的时候，假设你拿手机连上了自己家里的路由器，那我就需要去把所有的数据包全部都发送给这个路由器，然后由路由器转发请求给我们的这个下一个下一跳的这个网络的路由或者是中继或者是这个网关服务，那这样才能够一跳一接一跳的跳到我们的这个目标的服务器的这个位置。然后目标服务器收到请求之后，再一跳一跳的给我们返回来。
那我们接触到的第一个路由，就是我们家里这个路由器其实就是我们的网关。那这个网关跟代理服务器有啥区别？没有其实它就是网关。网关，就是访问我们网络的入口，这就称之为网关。

        我们的业务集群、服务系统都有很多，那么它就有可能会接入不同的网关去访问每一组不同的服务一组又一组的去同时对外提供服务。那也不一定只有一个网关就可以，被接入进来也可以配置好多个网关，我们只要需要把它分组分好就可以了。那网关和反向代理以及正向代理其实它都是一个意思，只是叫法不同，名词上的解释不同。

网关的特点

       就是它所有的请求都得转发，都得经过网关，我们用户想要去从某个网站去下载一个东西回来，你是不是得把请求打给我们的路由器？然后这个网站是接到路由器的请求，而不是直接接到我们用户的请求，那网站想把你想要的数据想传递给你的话，它也不是直接传递给我们用户的，他要把返回的数据给你的路由器，你的路由器再把数据给你当前的这个上网接入的这个设备，它需要在中间中转我们的数据。 

        这是它的特点。这个特点就造成了它有先天性的。那这种瓶颈就会在流量比较大的时候，如果你的这个网关服务他的这个上线带宽不够大的话，或者是不够足的话，就有可能被阻塞住了。比如我这是一个 10 兆的路由器，那你下载东西的时候，你的网速虽然说有 100 兆，但是这个路由器只有 10 兆，那你最大的下载速度是不是就只有 10 兆你即使是千兆的网络，你的路由器只有 10 兆，你的下载速度也会卡在这，尤其是请求越多，卡在这里的请求也会越多，这个请求同时打向外网的时候，它会进竞争着我们的路由器里边的一些资源，在越竞争的情况下，它的分配会显得更没有效率，就不如一个这个文件，然后顺顺序地去传递。
那么它这个瓶颈我们应该怎么去有效地去避免呢？ 

        只能去提升路由器的带宽

反向代理在系统架构中的应用场景

传统服务器

中小型互联网项目

负载均衡 

        负载均衡（Load Balance，简称 LB）是高并发、高可用系统必不可少的关键组件，目标是 尽力将网络流量平均分发到多个服务器上，以提高系统整体的响应速度和可用性。

负载均衡的主要作用如下：

高并发：负载均衡通过算法调整负载，尽力均匀的分配应用集群中各节点的工作量，以此提高应用集群的并发处理能力（吞吐量）。

伸缩性：添加或减少服务器数量，然后由负载均衡进行分发控制。这使得应用集群具备伸缩性。

高可用：负载均衡器可以监控候选服务器，当服务器不可用时，自动跳过，将请求分发给可用的服务器。这使得应用集群具备高可用的特性。

安全防护：有些负载均衡软件或硬件提供了安全性功能，如：黑白名单处理、防火墙，防 DDos 攻击等。
 

Nginx的反向代理配置

        反向代理服务器在配置的时候有一个关键字，这个关键字叫proxy_pass

使用位置 在 location  下使用
    proxy_pass和这个 root 目录，这俩是二选一的 
    root 目录，它会帮我们去寻找静态文件对吧？一旦配置 profipass 他就去寻找root   和 index
proxy_pass 这个关键字后边接的形式有两种：
    一是：直接接这个代理的地址,可以是一台主机，也可以是这个一个具体的网址。
    二是：可以把它配成一组服务器

proxy_pass不支持 https 

 [protopass 如果配一个的话，你就得把这个协议给它写满, 分号结尾] 

测试

 出现的错误:

# 配置文件书写有误
[root@centos01 ~]# systemctl start nginx
Job for nginx.service failed because the control process exited with error code. See "systemctl status nginx.service" and "journalctl -xe" for details.

 跳转到我们本机的一个服务器上

测试 

注意：如果配置好后未成功，可能是浏览器缓存问题。上篇有写到

基于反向代理的负载均衡器
负载均衡基本配置

配置一下负载均衡。负载均衡的配置和刚才的 prose pass 要配合来使用。

upstream 定义一组服务器出来，注意  upstream 和 server 是同一级别的

 测试

 负载均衡策略

轮询策略

权重

weight(权重) 常用
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。

• weight：默认为1.weight越大，负载的权重就越大。
• down：表示当前的server暂时不参与负载
• backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。  备用机器

使用位置：

upstream httpd {
server 127.0.0.1:8050 weight=10 down;
server 127.0.0.1:8060 weight=1;
server 127.0.0.1:8060 weight=1 backup;
}

注意：

        这几种注释， 并不常用，为什么？首先我们再加一下这个注释的时候，我们就得重新 reload 一下。很多时候是来不及的，想要做到这种动态的去分配上下线，我们靠 nginx 的基础命令肯定是不行的，这一点一定要注意到。但是这个 backup 我们到时候可以时不时地用一下留一台备用机，也就是另外几台机器，如果要是真正出现了问题的话，我们可以这么做。

不常用的负载均衡策略

ip_hash

    根据客户端的ip地址转发同一台服务器，可以保持回话。

least_conn

    最少连接访问

url_hash

    根据用户访问的url定向转发请求

fair

    根据后端服务器响应时间转发请求

        以上基本上在我们的生产环境当中都不会用。他有一个最核心的问题，就是他没法去动态去上下线，然后这些这个固定的这些转发地址，只能从我们的配置文件里这个固定的配置文件里去转发这些地址所以它非常的这个不灵活，非常的死板。

使用：

        用 Lua 脚本的方式去在我们的 NGINX 里边去编程，来动态去管理我们当前这个服务的列表，包括我们也可以去检测后端服务器的上线线的情况，包括我们也可以在里边去配置这个权重值，包括我们可以去做定向的这种流量的转发，以及这个 IP 的这个来源。

        企业的实际的场景当中，要么使用轮询的方式，轮询没有什么不好的，唯一的不好的就是它的会话没法保持。要么我们就是用lua脚本去自定义的转发规则，用这种第三方的非常非常的少，因为它非常不灵活，你想要去更改的话，就必须得把服务的配置文件重新加载重启。

轮询  保持会话 session   策略

方式一：

        spring session 写到另一台服务器中 reids  不适用于大规模的高并发这种场景

高并发的场景使用就是下发这个 token真正的这种无状态会话
     

方式二：无状态会话   主流

这下发 token 是啥意思？
    用户请求到我们 nginx 的服务器， nginx 的服务器会找到一台专门负责权限校验认证的服务器，当用户的请求到这个权限校验这台服务器上，比如说他登录了在这台机器上，他会校验他的权限，校验成功之后，给他下发权限全都记录到一个文件里，或者记录一个比较长的字符串。这个就是 token ，token 有自身的校验方式，就像下发 cookie 一样，把它下发到我们的这个客户端，客户端替换掉了 cookie ，原本的 cookie 只有一个这个 session ID ，在这个 token 里边不记 session ID ，它记录当前用户的信息，并且两方给它做了一层加密。
也就是 token 客户端是无法更改的。
        用户在访问我们的服务器的时候，我们的服务器会拿一个 token 把它给解开。如果它篡改这个 token 就解不开了，正常情况可以解开。这个 token 里边存储的就是这些状态信息，把 session 和 cookie 整合到了一个文件里，服务器端它又不存它，服务器端只做校验，相当于这一个压缩包。
        怎么说呢？比如说我的用户登录之后，登录成功了，我们给他下发这个 token 这个 token 里边，比如说我们打包一个压缩包 a2.zip， a2.zip 给他加了一个密码，这个密码只在服务器端有，客户端没有。下载发给我们的客户端，客户端也不需要读得懂这个 token 里边究竟是啥，但你每次访问只需要带着这个 token 来就可以了。它带过来之后，只有我服务器端有这个密码，可以把它给解开。你客户端它解不开，解开之后你改了之后到服务器端就解不开了。服务端解不开的话我就认为你这次权限校验失败了。
以这种方式叫无状态的会话保持方式来维持这种这个会话这是现在比较主流的方式。

本文标签： nginx