一、Nginx概述

1.1 负载均衡概述

1.2 负载均衡的作用

1.3 四/七层负载均衡

1.3.1 网络模型简介

1.3.2 四层和七层负载均衡对比

1.3.3 Nginx七层负载均衡实现

1.4 Nginx负载均衡配置

1.5 Nginx负载均衡状态

1.6 Nginx负载均衡策略

二、负载均衡实战

2.1 测试服务器

2.2 普通轮询

2.2.1 实现效果

2.2.2 准备工作

2.2.3 实现

2.3 weight加权（加权轮询）

2.3.1 实现效果

2.3.2 准备工作

2.3.3 实现

2.4 ip_hash

2.5 url_hash

2.6 fair

三、阿里云传统型负载均衡CLB

3.1 概述

3.2CLB组成

3.3 产品优势

3.4 阿里云控制台配置SLB

Nginx系列之一入门安装_开着拖拉机回家的博客-CSDN博客

Nginx系列之一反向代理_开着拖拉机回家的博客-CSDN博客

一、Nginx概述

随着社会越来越快的发展，信息化和数字化建设蓬勃发展，用户访问服务的数量也随之骤增，依靠单设备硬件愈发不能满足高并发下的大量网络请求，因此负载均衡（LB）应用而生。

1.1 负载均衡概述

所谓负载均衡，就是 Nginx 把请求分摊给上游的应用服务器，这样即使某一个服务器宕机也不会影响请求的处理，或者当应用服务器扛不住了，可以随时进行扩容。

应用集群：将同一应用部署到多台机器上，组成处理集群，接收负载均衡设备分发的请求，进行处理并返回响应的数据。

负载均衡器: 将用户访问的请求根据对应的负载均衡算法，分发到集群中的一台服务器进行处理。

1.2 负载均衡的作用

1、解决服务器的高并发压力，提高应用程序的处理性能。

2、提供故障转移，实现服务高可用和可靠性。

3、通过增加或减少服务器数量，增强网站的可扩展性。

4、在负载均衡器上进行过滤，可以提高系统的安全性。

1.3 四/七层负载均衡

1.3.1 网络模型简介

OSI（Open System Interconnection，开放式系统互联模型）是由国际标准化组织ISO指定的一个不基于具体机型、操作系统或公司的网络体系结构。该模型将网络通信的工作分为七层。

负载均衡主要分为四层和七层负载均衡，对应osi七层模型的四层和七层。

四层负载均衡工作在OSI模型的第四层-传输层，由于在传输层，只有TCP/UDP协议，这两种协议中除了包含源IP、目标IP以外，还包含源端口号及目的端口号。

四层负载均衡 服务器在接受到客户端请求后，以后通过修改数据包的地址信息（IP+端口号）将流量转发到应用服务器。

七层负载均衡工作在OSI模型的应用层，应用层协议较多，常用http、radius、dns等。七层负载就可以基于这些协议来负载。这些应用层协议中会包含很多有意义的内容。比如同一个Web服务器的负载均衡，除了根据IP加端口进行负载外，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。

1.3.2 四层和七层负载对比

（1）智能性

七层负载均衡由于具备OIS七层的所有功能，所以在处理用户需求上能更加灵活，从理论上讲，七层模型能对用户的所有跟服务端的请求进行修改。例如对文件header添加信息，根据不同的文件类型进行分类转发。四层模型仅支持基于网络层的需求转发，不能修改用户请求的内容。

（2）安全性

七层负载均衡由于具有OSI模型的全部功能，能更容易抵御来自网络的攻击；四层模型从原理上讲，会直接将用户的请求转发给后端节点，无法直接抵御网络攻击。

（3）复杂度

四层模型一般比较简单的架构，容易管理，容易定位问题；七层模型架构比较复杂，通常也需要考虑结合四层模型的混用情况，出现问题定位比较复杂。

（4）效率比

四层模型基于更底层的设置，通常效率更高，但应用范围有限；七层模型需要更多的资源损耗，在理论上讲比四层模型有更强的功能，现在的实现更多是基于http应用。

实际环境采用的方式：四层负载（LVS）+七层负载（Nginx）。

1.3.3 Nginx七层负载均衡实现

Nginx要实现七层负载均衡需要用到proxy_pass代理模块配置， Nginx的负载均衡是在Nginx的反向代理基础上把用户的请求根据指定的算法分发到一组【upstream虚拟服务池】。

1.4 Nginx负载均衡配置

nginx.conf

   upstream myserver{
          server 192.168.2.211:8082 max_fails=1 fail_timeout=10s weight=1;
          server 192.168.2.211:8083;
    }
    server {
        listen       9001;
        server_name  www.kangll.com;

        location /edu/ {
            proxy_pass http://myserver;
            root  html;
        }
    }

1.5 Nginx负载均衡状态

代理服务器在负载均衡调度中的状态有以下几个：

状态	概述
down	当前的server暂时不参与负载均衡
backup	标记为备份服务器，当主机服务器停止时，请求发送到标记的服务器
max_fails	允许请求失败的次数, 在fail_timeout参数设置的时间内，如果该时间内，所有该服务器请求都失败了，那么认为服务器停机
fail_timeout	经过max_fails次失败后，服务暂停的时间
max_conns	限制最大的接收连接数，默认为0，表示不限制，使用该配置可以根据后端服务器处理请求的并发量来进行设置，防止后端服务器被压垮。

1.6 Nginx负载均衡策略

策略	概述
轮询	每个请求按照时间顺序逐一分配到不同的后端服务器，如果后端服务器挂了，则自动删除
权重	指定轮询频率，weight和访问率成正比，用户后端服务器性能不均匀的情况，上文中加了weight=1 表示权重是1，不加weight 默认是 1
ip_hash	每个请求按照IP的hash结果分配，这样每个访问用户固定访问一个后端服务器，可以解决 session共享问题。
fair	按照后端服务器的响应时间来分配请求，响应时间短的优先分配
url_hash	按照访问URL的hash 接过来分配请求，使每个URL定向到同一个后端服务器

二、负载均衡实战

2.1 测试服务器

IP	组件	端口
192.168.2.211	Tomcat	8080
192.168.2.154	Nginx	80

2.2 普通轮询

2.2.1 实现效果

浏览器中访问 kangll.com:9001/edu/a.html , 观察请求负载均衡的实现效果，请求平均分担到节点192.168.2.211:8082 和192.168.2.211:8083的两个端口。

2.2.2 准备工作

两个tomcat 里面webapps目录中8083 的 Tomcat 的 webapps 文件夹下新建 edu 文件夹和 a.html 文件，填写内容为 "hello, 8083-Tomcat!" ,对应8082 的Tomcat a.html 文件，填写内容为 "hello, 8082-Tomcat!"

2.2.3 实现

nginx.conf 配置

   upstream myserver{
          server 192.168.2.211:8082;
          server 192.168.2.211:8083;
    }
    server {
        listen       80;
        server_name  www.kangll.com;

        location / {
            proxy_pass http://192.168.2.211:8080;
            index  index.html index.htm index.jsp;
        }
    }
    server {
        listen       9001;
        server_name  www.kangll.com;

        location /edu/ {
            proxy_pass http://myserver;
            root  html;
        }
    }

通过浏览器访问： kangll.com:9001/edu/a.html，刷新页面请求的两次结果不一样。

2.3 weight加权（加权轮询）

weight=number：用来设置服务器的权重，默认为1，权重数字越大，被分配到请求的几率越大。该权重值主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的，所以此策略比较适合服务器的硬件配置差别比较大的情况。

2.3.1 实现效果

浏览器中访问 kangll.com:9001/edu/a.html , 观察请求负载均衡的实现效果，请求平均分担到节点192.168.2.211:8082 和192.168.2.211:8083的两个端口。

2.3.2 准备工作

准备三个tomcat 里面webapps目录中8083 的 Tomcat 的 webapps 文件夹下新建 edu 文件夹和 a.html 文件，填写内容为 "hello, 8083-Tomcat!" ,对应8082 的Tomcat a.html 文件，填写内容为 "hello, 8082-Tomcat!"，对应8081 的Tomcat a.html 文件，填写内容为 "hello, 8081-Tomcat!"

2.3.3 实现

配置文件 nginx.conf

http {
   ...
    upstream myserver{
          server 192.168.2.211:8081 weight=10;
          server 192.168.2.211:8082 weight=5;
          server 192.168.2.211:8083 weight=5;
    }
 
    server {
        listen      9888;
        server_name www.kangll.com;

        location ~ / {
           # 被代理服务器的地址, 可以配置主机、ip 或者地址加端口
            proxy_pass http://myserver;
            index a.html;
            proxy_set_header Host $host;
            proxy_set_header X-real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }

}

通过浏览器访问：http://www.kangll.com:9888/edu/a.html 页面刷新 10次，访问到的比例为：4：3: 3 。

2.4 ip_hash

对后端的多台动态应用服务器做负载均衡时，ip_hash指令能够将某个客户端IP的请求通过哈希算法定位到同一台后端服务器上。当来自某一个IP的用户在后端Web服务器A上登录后，再访问该站点的其他URL，能保证其访问的还是后端web服务器A，可以解决session共享问题。

典型例子：用户首次访问一个系统是需要进行登录身份验证的，首先将请求跳转到Tomcat1服务器进行处理，登录信息是保存在Tomcat1 上的，这时候进行别的操作，那么可能会将请求轮询到第二个Tomcat2上，那么由于Tomcat2 没有保存会话信息，会以为该用户没有登录，然后继续登录一次，如果有多个服务器，每次第一次访问都要进行登录，这显然是很影响用户体验的。

nginx 基于 IP 路由负载，每次都将同一个 IP 地址发送的请求都分发到同一个 Tomcat 服务器，那么也不会存在 session 共享的问题。

配置文件 nginx.conf

http {
   ...
    upstream myserver{
          ip_hash;
          server 192.168.2.211:8081;
          server 192.168.2.211:8082;
          server 192.168.2.211:8083;
    }
 
    server {
        listen      9888;
        server_name www.kangll.com;

        location ~ / {
           # 被代理服务器的地址, 可以配置主机、ip 或者地址加端口
            proxy_pass http://myserver;
            index a.html;
            proxy_set_header Host $host;
            proxy_set_header X-real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }

}

注意：使用ip_hash指令无法保证后端服务器的负载均衡，可能导致有些后端服务器接收到的请求多，有些后端服务器接受的请求少，而且设置后端服务器权重等方法将不起作用。

2.5 url_hash

按访问url的hash结果来分配请求，使每个 url 定向到同一个后端服务器，要配合缓存命中来使用。同一个资源多次请求，可能会到达不同的服务器上，导致不必要的多次下载，缓存命中率不高，以及一些资源时间的浪费。而使用url_hash，可以使得同一个url（也就是同一个资源请求）会到达同一台服务器，一旦缓存住了资源，再次收到请求，就可以从缓存中读取。

nginx.conf

upstream myserver{
          hash $request_uri;
          server 192.168.2.211:8081;
          server 192.168.2.211:8082;
          server 192.168.2.211:8083;
    }
 
    server {
        listen      9888;
        server_name www.kangll.com;

        location ~ / {
           # 被代理服务器的地址, 可以配置主机、ip 或者地址加端口
            proxy_pass http://myserver;
            index a.html;
            proxy_set_header Host $host;
            proxy_set_header X-real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }

2.6 fair

fair采用的不是内建负载均衡使用的均衡算法，而是可以根据页面大小、加载时间长短智能地进行负载均衡。

nginx.conf

upstream myserver{
          fair;
          server 192.168.2.211:8081;
          server 192.168.2.211:8082;
          server 192.168.2.211:8083;
    }
 
    server {
        listen      9888;
        server_name www.kangll.com;

        location ~ / {
           # 被代理服务器的地址, 可以配置主机、ip 或者地址加端口
            proxy_pass http://myserver;
            index a.html;
            proxy_set_header Host $host;
            proxy_set_header X-real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }

三、阿里云传统型负载均衡CLB

传统型负载均衡CLB（Classic Load Balancer）是将访问流量根据转发策略分发到后端多台云服务器的流量分发控制服务。CLB扩展了应用的服务能力，增强了应用的可用性。什么是传统型负载均衡CLB - 负载均衡 - 阿里云

3.1 概述

CLB通过设置虚拟服务地址，将添加的同一地域的多台云服务器虚拟成一个高性能和高可用的后端服务池，并根据转发规则，将来自客户端的请求分发给后端服务器池中的云服务器。

CLB默认检查云服务器池中的云服务器的健康状态，自动隔离异常状态的云服务器，消除了单台云服务器的单点故障，提高了应用的整体服务能力。此外，CLB还具备抗DDoS攻击的能力，增强了应用服务的防护能力。

3.2 CLB组成

说明上图中灰色的云服务器代表该云服务器健康检查失败，流量不会转发到该云服务器上。

CLB由以下三个部分组成：

组成	说明
实例	一个CLB实例是一个运行的负载均衡服务，用来接收流量并将其分配给后端服务器。要使用负载均衡服务，您必须创建一个CLB实例，并至少添加一个监听和两台云服务器。
监听	监听用来检查客户端请求并将请求转发给后端服务器。监听也会对后端服务器进行健康检查。
后端服务器	后端服务器是一组接收前端请求的云服务器，目前CLB支持添加云服务器ECS（Elastic Compute Service）、弹性容器实例ECI（Elastic Container Instance）和弹性网卡ENI（Elastic Network Interface）作为后端服务器。您可以单独添加云服务器到后端服务器池，也可以通过虚拟服务器组或主备服务器组来批量添加和管理。更多信息，请参见：什么是云服务器ECS 什么是弹性容器实例ECI 弹性网卡ENI概述