一篇文章读懂Nginx的负载均衡，缓存和跨域网络BUG-

1.OSI网络模型

网络模型就是 OSI（Open System Interconnect），意思为开放网络互联，是由国际标准化组织(ISO)和国际电报电话咨询委员会(CCITT)共同出版的，他是一种网络互联模型，也是一种规范。

网络模型分为七层，也就是当用户发起请求到服务器接收，会历经七道工序，或者说用户利用互联网发送消息给另一个用户，也会历经七道工序。这七层可以分为如下：

以上七层每层可以与上下相邻层进行通信。每一层都是非常复杂的，我们不在这里深究，我们以举例的形式来阐述每一层是干嘛的。

• 应用层： 这是面向用户的，最靠近用户，为了让用户和计算机交互，在计算机里会有很多软件，比如eclipse，idea，qq，nginx等，这些都是应用软件，用户可以通过这些应用软件和计算机交互，交互的过程其实就是接口的调用，应用层为用户提供了交互的接口，以此为用户提供交互服务。那么在这一层最常见的协议有：HTTP,HTTPS,FTP,SMTP,POP3等。Nginx在本层，为七层负载均衡。

    举例：我要寄一封信给远在天边的老外LiLei，我会打开快递软件下单，这个时候我是用户，快递软件就是应用服务，是建立在计算机上的，提供给用户交互的一种服务或称之为手段。 

• 表示层： 该层提供数据格式编码以及加密功能，确保请求端的数据能被响应端的应用层识别。

    举例：我写中文给LiLei，他看不懂，这个时候我就会使用翻译软件把中文翻译成英文，随后信中涉及到一些比较隐私的信息我会加密一下，这个时候翻译软件和加密器就充当了表示层的作用，他用于显示用户能够识别的内容。 

• 会话层： 会话可以理解为session，请求发送到接受响应的这个过程之间存在会话，会话层就充当了这一过程的管理者，从创建会话到维护会话最后销毁会话。

    举例：我每次写信给LiLei都会记录在一个小本本上，寄信时间日期，收信时间日期，这本小本本上存有每次通信记录，这个小本本就相当于是一个会话的管理者。又或者说，我们平时在打电话，首先需要拨打电话，这是建立会话，对方接听电话，此时正在通话（维持并管理会话），通话结束后会话销毁，那么这也是一次会话的生命周期。 

• 传输层： 该层建立端到端的连接，他提供了数据传输服务，在传输层通信会涉及到端口号，本层常见的协议为TCP、UDP，LVS就是在传输层，也就是四层负载均衡。

    举例：我和LiLei通信过程中会借助快递公司，快递公司会分配快递员取件和寄件，那么这个快递员则充当传输层的作用。 

• 网络层： 网络通信的时候必须要有本机IP和对方的IP，请求端和响应端都会有自己的IP的，IP就相当于你家地址门牌号，在网络上云服务器有固定的公网IP，普通计算机也有，只不过是动态IP，运营商每天会分配不同的IP给你的计算机。所以网络层也能称之为IP层，IP是互联网的基础根本。能提供IP分配的设备则为路由器或交换机。

    举：对于拥有固定IP的云服务来说，他们都是由腾讯云、阿里云等这样的供应商提供的，他们为云服务器提供固定ip；电信、移动、联调等运营商为你的计算机动态分配ip，每天都不同；则这些供应商和运营商都是网络层。同理，快递员由物流公司分配和管理，那么物流公司就是网络层咯。 

• 数据链路层： 这一层会提供计算机MAC地址，通信的时候会携带，为了确保请求投递正确，所以他会验证检测MAC地址，以确保请求响应的可靠性。

    举例：快递员在投递派送的时候，他（或客服）会预先提前打电话给你，确认你家地址对不对、有没有人、货到付款有没有准备好钱等等，这个时候快递员（或客服）就充当了数据链路层的职责。 

• 物理层： 端到端请求响应过程中的媒介，物理介质，比如网线、中继器等等设备，都是你在端到端交互过程中不可缺少的基础设备。

    举例：快递员在投递的过程中，你写的信会历经一些交通运输工具，比如首先通过飞机运输到国外，在海关统一拿到信以后会通过汽车运输到LiLei所在城市的物流集散地，最后快递员通过三轮电频车寄到LiLei家里，这个时候，飞机、汽车、三轮电瓶车都是物理层的媒介。 

​ 以上就是七层网络模型，大家理解其意义即可。需要注意的是Nginx存在于第七层，属于七层负载均衡；而第四层会有LVS，属于四层负载均衡。

2.Nginx的集群负载均衡解析

负载均衡：当有大量的并发请求来到服务器的时候，把这些请求分配到多台计算机节点上，让更多的节点来处理请求和响应，来大大的减少用户的等待时间

2.1 负载均衡分类

• 四层负载均衡：ip+端口形式进行负载均衡，通过转发到后台的服务器，通过转发并且会记录是由哪个服务器处理的，当下一次请求进来时还是让同一台服务器来处理请求，相当于长连接，一旦打开就会一直处于连接状态，是传输层基于TCP和UDP
• 七层负载均衡：基于URL或ip的负载均衡，是应用层的，基于HTTP协议的负载均衡

2.2 Nginx配置集群

# 配置上游服务器模块 upstream tomcats{     server 192.168.1.173:8080;     server 192.168.1.174:8080;     server 192.168.1.175:8080; } server {     listen 80;     server_name ww.tomcats.com;     location /{         #引用上游服务器块         proxy_pass https://tomcats;     } } 

2.3 Nginx 负载均衡策略

• 权重配置方式

upstream tomcats{     server 192.168.1.173:8080 weight=1;     server 192.168.1.174:8080 weight=2;     server 192.168.1.175:8080 weight=3; } 

• ip_hash配置方式

upstream tomcats{      ip_hash     server 192.168.1.173:8080;      server 192.168.1.174:8080;     server 192.168.1.175:8080; } 

• least_conn配置方式

upstream tomcats{      least_conn;     server 192.168.1.173:8080;     server 192.168.1.174:8080;     server 192.168.1.175:8080; } 

• fair配置方式

upstream tomcats{      fair     server 192.168.1.173:8080;     server 192.168.1.174:8080;     server 192.168.1.175:8080; } 

• url配置方式

upstream tomcats{      hash $request_uri;     server 192.168.1.173:8080;     server 192.168.1.174:8080;     server 192.168.1.175:8080; } 

2.4 upstream指令参数

• max_conns：限制每台server的连接数，用于保护避免过载，可起到限流作用。
  测试参考配置如下：

# worker进程设置1个，便于测试观察成功的连接数 worker_processes  1;  upstream tomcats {         server 192.168.1.173:8080 max_conns=2;         server 192.168.1.174:8080 max_conns=2;         server 192.168.1.175:8080 max_conns=2; } 

• slow_start:使某一台服务器慢慢的加入到集群当中
  注：商业版，需要付费
  配置参考如下：

upstream tomcats {         server 192.168.1.173:8080 weight=6 slow_start=60s; #       server 192.168.1.190:8080;         server 192.168.1.174:8080 weight=2;         server 192.168.1.175:8080 weight=2; } 

注意：该参数不能使用在hash和random load balancing中。如果在 upstream 中只有一台 server，则该参数失效。

• down:用于标记服务节点不可用
  配置参考如下：

upstream tomcats {         server 192.168.1.173:8080 down;         server 192.168.1.174:8080 weight=1;         server 192.168.1.175:8080 weight=1; } 

• backup:表示当前服务器节点是备用机，只有在其他的服务器都宕机以后，自己才会加入到集群中，被用户访问到：
  配置参考如下：

upstream tomcats {         server 192.168.1.173:8080 backup;         server 192.168.1.174:8080 weight=1;         server 192.168.1.175:8080 weight=1; } 

• max_fails：表示失败几次，则标记server已宕机，剔出上游服务。
• fail_timeout：表示失败的重试时间。

假设目前设置如下：
max_fails=2 fail_timeout=15s
则代表在15秒内请求某一server失败达到2次后，则认为该server已经挂了或者宕机了，随后再过15秒，这15秒内不会有新的请求到达刚刚挂掉的节点上，而是会请求到正常运作的server，15秒后会再有新请求尝试连接挂掉的server，如果还是失败，重复上一过程，直到恢复。

• Keepalived 提高吞吐量
  keepalived： 设置长连接处理的数量
  proxy_http_version：设置长连接http版本为1.1
  proxy_set_header：清除connection header 信息

upstream tomcats { #       server 192.168.1.173:8080 max_fails=2 fail_timeout=1s; #       server 192.168.1.174:8080 weight=1; #       server 192.168.1.175:8080 weight=1;         keepalive 32; }  server {         listen       80;         server_name  www.tomcats.com;          location / {             proxy_pass  https://tomcats;             proxy_http_version 1.1;             proxy_set_header Connection "";         }     } 

3.ip_hash算法与一致性hash算法

ip_hash：通过对ip进行hash后按照服务器个数取模，然后分配到不同的服务器中，稳定的情况下可以保证每一个ip每次都请求到同一台服务器上，但是有一个问题：当增加或移除服务器时会导致所有的用户ip都要在重新计算分配的服务器。

一致性hash算法：将0到2的32次方减一的数做成一个环，将用户和节点都放到这个环上，把用户ip顺时针放到离他最近的一台服务器上，这样增加和减少服务器之后影响到一部分用户，而不会影响到所有用户

4.Nginx的跨域问题

4.1 跨域资源共享（CORS）

跨域资源共享(CORS) 是一种机制，它使用额外的 HTTP 头来告诉浏览器 让运行在一个 origin (domain) 上的Web应用被准许访问来自不同源服务器上的指定的资源。当一个资源从与该资源本身所在的服务器不同的域、协议或端口请求一个资源时，资源会发起一个跨域 HTTP 请求。
CORS需要浏览器和服务器同时支持，才可以实现跨域请求，目前几乎所有浏览器都支持CORS，IE则不能低于IE10。CORS的整个过程都由浏览器自动完成，前端无需做任何设置，跟平时发送ajax请求并无差异。so，实现CORS的关键在于服务器，只要服务器实现CORS接口，就可以实现跨域通信。

4.2 如何解决跨域问题

目前基本上主流有三种解决方式：JsonP,SpringBoot，Nginx，我们今天来说说Nginx是如何解决跨域问题的

4.3 Nginx通过配置解决跨域问题

在server模块中添加下面的信息

server {             listen       88;             server_name  localhost;                          #允许跨域请求的域，*代表所有              add_header 'Access-Control-Allow-Origin' *;             #允许带上cookie请求              add_header 'Access-Control-Allow-Credentials' 'true';             #允许请求的方法，比如 GET/POST/PUT/DELETE              add_header 'Access-Control-Allow-Methods' *;             #允许请求的header              add_header 'Access-Control-Allow-Headers' *;                          location / {                 root   html;                 index  index.html index.htm;             }     }  

5.缓存

5.1浏览器缓存

加速用户访问，提升单个用户（浏览器访问者）体验，缓存在本地

 location /{         alias /home/;     # expires 10s; 缓存10秒     # expires @22h30m;每日22点30分清除缓存     # expires -1h;缓存提前过期     # expires epoch;不设置缓存     # expires off;nginx关闭缓存，不添加头信息     expires max;最大缓存时间     } 

5.2 Nginx反向代理缓存

缓存在nginx端，提升所有访问到nginx这一端的用户
提升访问上游（upstream）服务器的速度
用户访问仍然会产生请求流量

# proxy_cache_path 设置缓存目录 #       keys_zone 设置共享内存以及占用空间大小 #       max_size 设置缓存大小 #       inactive 超过此时间则被清理 #       use_temp_path 临时目录，使用后会影响nginx性能 proxy_cache_path /usr/local/nginx/upstream_cache keys_zone=mycache:5m max_size=1g inactive=1m use_temp_path=off;  location / {     proxy_pass  https://tomcats;      # 启用缓存，和keys_zone一致     proxy_cache mycache;     # 针对200和304状态码缓存时间为8小时     proxy_cache_valid   200 304 8h; }  

6.Nginx的模块化设计解析

Nginx的主要模块构成

• nginx croe:非常核心的内容，为底层提供一些通信协议，也为其他模块和nginx运行时提供一些条件，可以把他理解成一个jmv
• http:核心中的一部分
• mail:与邮件相关
• event module:事件模块，在linux下的epllo，操作系统层面的处理机制
• phase handler：处理客户端的一些请求，处理后负责处理一些响应
• output filter：是一个过滤器，过滤掉一些响应后在返回给客户端
• upstream：反向代理模块，会把真正的请求转发到真实的服务器
• load balancer 负载均衡器
• extend module 继承模块，与第三方有关