基于Nginx的负载均衡

Nginx简介

Nginx（发音为“Engine-x”）是一种开源软件，最初被设计为高性能Web服务器。今天，Nginx可以完成其他一些任务，包括缓存服务器，反向代理服务器，负载平衡器等等。

WEB服务器

目前主流使用的web服务器软件，主要有apache、nginx、tomcat、iis等，在全球范围内来说，Apache是现有的最流行的Web服务器，但是在高流量网站中最流行的Web服务器确实nginx，在我国不管是大中小互联网公司，主流选择的也是nginx作为web服务器软件。一份来自Netcraft的调查中，发现Apache的使用率为31.54％，Nginx的使用率为26.20％。

HTTP代理服务器

HTTP代理，分两类：一种的正向代理，一种是反向代理。

正向代理

正向代理（Forward Proxy）最大的特点是，客户端非常明确要访问的服务器地址，它代理客户端，替客户端发出请求。

假设客户端想要访问 Google，它明确知道待访问的服务器地址是 https://www.google.com/，但由于条件限制，它找来了一个能够访问到 Google 的”朋友”：代理服务器。客户端把请求发给代理服务器，由代理服务器代替它请求 Google，最终再将响应返回给客户端。这便是一次正向代理的过程，该过程中服务器并不知道真正发出请求的是谁。

反向代理

那么，随着请求量的爆发式增长，服务器觉得自己一个人始终是应付不过来，需要兄弟服务器们帮忙，于是它喊来了自己的兄弟以及代理服务器朋友。此时，来自不同客户端的所有请求实际上都发到了代理服务器处，再由代理服务器按照一定的规则将请求分发给各个服务器。

这就是反向代理（Reverse Proxy），反向代理隐藏了服务器的信息，它代理的是服务器端，代其接收请求。换句话说，反向代理的过程中，客户端并不知道具体是哪台服务器处理了自己的请求。如此一来，既提高了访问速度，又为安全性提供了保证。

在这之中，反向代理需要考虑的问题是，如何进行均衡分工，控制流量，避免出现局部节点负载过大的问题。通俗的讲，就是如何为每台服务器合理的分配请求，使其整体具有更高的工作效率和资源利用率。

基于nginx的反向代理，可以实现分布式（不同子域名访问不同的服务后端节点）和负载均衡（相同的域名访问多个相同的后端节点）

反向代理和正向代理的区别：

• 正向代理：针对客户端而言，代理服务器代理客户端，转发请求，并将获得的内容返回给客户端。
• 反向代理：针对客户端而言，代理服务器就像是原始服务器,代理集群的web节点服务器返回结果。

负载均衡器

负载均衡也是Nginx常用的一个功能，基于nginx反向代理。负载均衡其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。简单而言就是当有2台或以上服务器时，根据规则随机的将请求分发到指定的服务器上处理，负载均衡配置一般都需要同时配置反向代理，通过反向代理跳转到负载均衡。Nginx目前支持自带3种负载均衡策略（轮询、加权轮询、IP哈希），还有2种常用的第三方策略（fair、url哈希）。

缓存服务器

nginx可以实现图片、css、js等静态资源文件的缓存，nginx作为缓存服务器时是搭配nginx作为反向代理服务器一起使用的。当客户端第一次通过nginx向后端资源服务器请求静态资源，响应给对应的客户端同时自身缓存一份，后续如果请求相同的资源，就不需要再次向后端服务器请求了，除非缓存被清理或者缓存过期。

Nginx负载均衡简介

负载均衡（Load Balance），它在网络现有结构之上可以提供一种廉价、有效、透明的方法来扩展网络设备和服务器的带宽，并可以在一定程度上增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性等。用官网的话说，它充当着网络流中“交通指挥官”的角色，“站在”服务器前处理所有服务器端和客户端之间的请求，从而最大程度地提高响应速率和容量利用率，同时确保任何服务器都没有超负荷工作。如果单个服务器出现故障，负载均衡的方法会将流量重定向到其余的集群服务器，以保证服务的稳定性。当新的服务器添加到服务器组后，也可通过负载均衡的方法使其开始自动处理客户端发来的请求。

简言之，负载均衡实际上就是将大量请求进行分布式处理的策略。

负载均衡是将负载分摊到多个操作单元上执行，从而提高服务的可用性和响应速度，带给用户更好的体验。对于Web应用，通过负载均衡，可以将一台服务器的工作扩展到多台服务器中执行，提高整个网站的负载能力。其本质采用一个调度者，保证所有后端服务器都将性能充分发挥，从而保持服务器集群的整体性能最优，这就是负载均衡。

负载均衡是 Nginx 比较常用的一个功能，可优化资源利用率，最大化吞吐量，减少延迟，确保容错配置，将流量分配到多个后端服务器。

Nginx 在 AKF 可扩展立方体上的应用：

• 在 x 轴上，可以通过横向扩展应用服务器集群，Nginx 基于 Round-Robin 或者 Least-Connected 算法分发请求。但是横向扩展并不能解决所有问题，当数据量大的情况下，无论扩展多少台服务，单台服务器数据量依然很大。
• 在 y 轴上，可以基于 URL 进行不同功能的分发。需要对 Nginx 基于 URL 进行 location 的配置，成本较高。
• 在 z 轴上可以基于用户信息进行扩展。例如将用户 IP 地址或者其他信息映射到某个特定的服务或者集群上去。

这就是 Nginx 的负载均衡功能，它的主要目的就是为了增强服务的处理能力和容灾能力。

• 当一个应用单位时间内访问量激增，服务器的带宽及性能受到影响，影响大到自身承受能力时，服务器就会宕机奔溃，为了防止这种现象发生，以及实现更好的用户体验，我们可以通过配置 Nginx 负载均衡的方式来分担服务器压力。
• 当有一台服务器宕机时，负载均衡器就分配其他的服务器给用户，极大的增加的网站的稳定性。当用户访问 Web 时候，首先访问到的是负载均衡器，再通过负载均衡器将请求转发给后台服务器。

Nginx 作为负载均衡主要有以下几个理由：

• 高并发连接
• 内存消耗少
• 配置文件非常简单
• 支持 Rewrite 重写规则
• 内置的健康检查功能

Nginx 工作在网络的 7 层，可以针对 HTTP 应用本身来做分流策略。支持七层 HTTP、HTTPS 协议的负载均衡。对四层协议的支持需要第三方插件 -yaoweibin 的 ngx_tcp_proxy_module 实现了 TCP upstream。

Nginx被称为动态负载均衡的主要原因：

• 自身监控。内置了对后端服务器的健康检查功能。如果 Nginx Proxy 后端的某台服务器宕机了，会把返回错误的请求重新提交到另一个节点，不会影响前端访问。它没有独立的健康检查模块，而是使用业务请求作为健康检查，这省去了独立健康检查线程，这是好处。坏处是，当业务复杂时，可能出现误判，例如后端响应超时，这可能是后端宕机，也可能是某个业务请求自身出现问题，跟后端无关。
• 可扩展性。Nginx 属于典型的微内核设计，其内核非常简洁和优雅，同时具有非常高的可扩展性。
• Nginx 是纯 C 语言的实现，其可扩展性在于其模块化的设计。目前，Nginx 已经有很多的第三方模块，大大扩展了自身的功能。nginx_lua_module可以将 Lua 语言嵌入到 Nginx 配置中，从而利用 Lua 极大增强了 Nginx 本身的编程能力，甚至可以不用配合其它脚本语言（如 PHP 或 Python 等），只靠 Nginx 本身就可以实现复杂业务的处理。
• 配置修改。Nginx 支持热部署，几乎可以做到 7*24 不间断运行，即使运行数个月也不需要重新启动。能够在不间断服务的情况下，对软件版本进行进行升级。Nginx 的配置文件非常简单，风格跟程序一样通俗易懂，能够支持 perl 语法。使用nginx –s reload 可以在运行时加载配置文件，便于运行时扩容/减容。重新加载配置时，master 进程发送命令给当前正在运行的 worker 进程 worker 进程接到命令后会在处理完当前任务后退出。同时，master 进程会启动新的 worker 进程来接管工作。

Nginx负载均衡策略

Nginx 作为一款优秀的反向代理服务器，可以通过不同的负载均衡算法来解决请求量过大情况下的服务器资源分配问题。Nginx 的负载均衡策略可以划分为两大类：内置策略 和 扩展策略。

• 内置策略包含轮询、加权轮询和ip hash等，在默认情况下这两种策略会编译进 Nginx 内核，只需在 Nginx 配置中指明参数即可。
• 扩展策略有很多，如fair、通用 hash、consistent hash 等，默认不编译进 Nginx 内核。

策略	作用
轮询	按时间顺序逐一分配到不同的后端服务器，如果后端服务挂了，能自动剔除
加权轮询	权重分配，指定轮询几率，weight 值越大，分配到的访问几率越高，用于后端服务器性能不均的情况
ip_hash	每个请求按访问 IP 的 hash 结果分配，这样每个访客固定访问一个后端服务器，可以解决动态网页 session 共享问题。负载均衡每次请求都会重新定位到服务器集群中的某一个，那么已经登录某个服务器的用户再重新定位到另一个服务器，其登录信息将会丢失，这样显然是不妥的
least_conn	最少链接数，那个机器连接数少就分支
url_hash	按照访问的 url 的 hash 结果来分配请求，是每个 url 定向到同一个后端服务器
hash 关键值	hash 自定义的 key
fair（第三方）	按后端服务器的响应时间分配，响应时间短的优先分配，依赖第三方插件 nginx-upstream-fair，需要先安装

这里举出常用的几种调度算法策略：

轮询策略（默认），请求按时间顺序，逐一分配到 Web 层服务，然后周而复始，如果 Web 层服务挂掉，自动剔除

轮询为负载均衡中较为基础也较为简单的算法，它不需要配置额外参数。假设配置文件中共有 M 台服务器，该算法遍历服务器节点列表，并按节点次序每轮选择一台服务器处理请求。当所有节点均被调用过一次后，该算法将从第一个节点开始重新一轮遍历。

特点：由于该算法中每个请求按时间顺序逐一分配到不同的服务器处理，因此适用于服务器性能相近的集群情况，其中每个服务器承载相同的负载。但对于服务器性能不同的集群而言，该算法容易引发资源分配不合理等问题。

upstream backend {
  server 127.0.0.1:3000;
  server 127.0.0.1:3001;
}
weight=number 设置服务器的权重，默认为 1，权重大的会被优先分配。

为了避免普通轮询带来的弊端，加权轮询应运而生。在加权轮询中，每个服务器会有各自的权重 weight。一般情况下，weight 的值越大意味着该服务器的性能越好，可以承载更多的请求。该算法中，客户端的请求按权值比例分配，当一个请求到达时，优先为其分配权值最大的服务器。

特点：加权轮询可以应用于服务器性能不等的集群中，使资源分配更加合理化。

Nginx 加权轮询源码可见：ngx_http_upstream_round_robin.c，源码分析可参考：关于轮询策略原理的自我理解。其核心思想是，遍历各服务器节点，并计算节点权值，计算规则为 current_weight 与其对应的 effective_weight 之和，每轮遍历中选出权值最大的节点作为最优服务器节点。其中 effective_weight 会在算法的执行过程中随资源情况和响应情况而改变。

upstream backend {
  server 127.0.0.1:3000 weight=2;
  server 127.0.0.1:3001 weight=1;
}

backup 标记为备份服务器。当主服务器不可用时，将传递与备份服务器的连接。

upstream backend {
  server 127.0.0.1:3000 backup;
  server 127.0.0.1:3001;
}

IP 哈希（IP hash）

客户端 IP 绑定：ip_hash 保持会话，保证同一客户端始终访问一台服务器。

ip_hash 依据发出请求的客户端 IP 的 hash 值来分配服务器，该算法可以保证同 IP 发出的请求映射到同一服务器，或者具有相同 hash 值的不同 IP 映射到同一服务器。

特点：该算法在一定程度上解决了集群部署环境下 Session 不共享的问题。

Session 不共享问题是说，假设用户已经登录过，此时发出的请求被分配到了 A 服务器，但 A 服务器突然宕机，用户的请求则会被转发到 B 服务器。但由于 Session 不共享，B 无法直接读取用户的登录信息来继续执行其他操作。

实际应用中，我们可以利用 ip_hash，将一部分 IP 下的请求转发到运行新版本服务的服务器，另一部分转发到旧版本服务器上，实现灰度发布。再者，如遇到文件过大导致请求超时的情况，也可以利用 ip_hash 进行文件的分片上传，它可以保证同客户端发出的文件切片转发到同一服务器，利于其接收切片以及后续的文件合并操作。

upstream backend {
  ip_hash;
  server 127.0.0.1:3000 backup;
  server 127.0.0.1:3001;
}

最小连接数策略

least_conn 优先分配最少连接数的服务器，避免服务器超载请求过多。

假设共有 M 台服务器，当有新的请求出现时，遍历服务器节点列表并选取其中连接数最小的一台服务器来响应当前请求。连接数可以理解为当前处理的请求数。

upstream backend {
  least_conn;
  server 127.0.0.1:3000;
  server 127.0.0.1:3001;
}

最快响应时间策略

fair 依赖于 Nginx Plus，有限分配给响应时间最短的服务器

当我们需要代理一个集群时候可以通过下面这种方式实现。

http {
  upstream backend {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
  }
  server {
    listen      9000;
    server_name localhost;
    location / {
      proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Scheme $scheme;
      proxy_pass backend;
    }
  }
}

标准配置：

# upstream：该指令用于设置可以再 proxy_pass 和 fastcgi_pass 指令中使用的代理服务器
# weight：设置服务器的权重，权重数值越高，被分配到的客户端请求数越多，默认为 1
# max_fails：指定的时间内对后端服务器请求失败的次数，如果检测到后端服务器无法连接及发生服务器错误（404 错误除外），则标记为失败，默认为 1，设为数值 0 将关闭这项检测
# fail_timeout：在经历参数 max_fails 设置的失败次数后，暂停的时间
# down：标记服务器为永久离线状态，用于 ip_hash 指令
# backup：仅仅非在 backup 服务器全部繁忙的时候才会启用
upstream imooc {
    server 116.62.103.228:8001 weight=1 max_fails=2 fail_timeout=30s;
    server 116.62.103.228:8002;
    server 116.62.103.228:8003;
}
server {
    listen 80;
    server_name localhost jeson.t.imooc.io;
    #charset koi8-r
    access_log /var/log/nginx/test_proxy.access.log main;
    location / {
        proxy_pass http://imooc;
        include proxy_params;
    }
    # error_page 404 /404.html
}

服务器在负载均衡调度中的状态：

• down：当前的 Server 暂时不参与负载均衡
• backup：预留的备份服务器
• max_fails：允许请求失败的次数
• fail_timeout：经过max_fails 失败后，服务暂停的时间
• max_conns：限制最大的接收的连接数

参考链接：