负载均衡

当一个应用单位时间内访问量激增，服务器的带宽及性能受到影响，影响大到自身承受能力时，服务器就会宕机奔溃，为了防止这种现象发生，以及实现更好的用户体验，我们可以通过配置 Nginx 负载均衡的方式来分担服务器压力。

当有一台服务器宕机时，负载均衡器就分配其他的服务器给用户，极大的增加的网站的稳定性。当用户访问 Web 时候，首先访问到的是负载均衡器，再通过负载均衡器将请求转发给后台服务器。

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

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

1. 高并发连接
2. 内存消耗少
3. 配置文件非常简单
4. 成本低廉
5. 支持 Rewrite 重写规则
6. 内置的健康检查功能
7. 节省带宽
8. 稳定性高

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

全局负载均衡

GSLB 是英文 Global Server Load Balance 的缩写，意思是全局负载均衡。

作用：实现在广域网（包括互联网）上不同地域的服务器间的流量调配，保证使用最佳的服务器服务离自己最近的客户，从而确保访问质量。

负载均衡

负载均衡（Server Load Balancer，简称 SLB）是一种网络负载均衡服务，针对阿里云弹性计算平台而设计，在系统架构、系统安全及性能，扩展，兼容性设计上都充分考虑了弹性计算平台云服务器使用特点和特定的业务场景。

简单配置：

http {
  upstream api.mrsingsing {
    # 采用 ip_hash 负载均衡策略
    ip_hash;
    # 采用 fair 负载均衡策略
    # fair;
    # 负载均衡目的服务地址
    server 127.0.0.1:8081;
    server 127.0.0.1:8080;
    server 127.0.0.1:8082 weight=10;  # weight 方式，不写默认为 1
  }

  server {
    location / {
      proxy_pass http://api.mrsingsing;
      proxy_connect_timeout 10;
    }
  }
}

四层负载均衡

四层负载均衡是基于传输层协议包来封装的（如：TCP/IP），那我们前面使用到的七层是指的应用层，他的组装在四层的基础之上，无论四层还是七层都是指的 OSI 网络模型。

1. 四层 + 七层来做负载均衡，四层可以保证七层的负载均衡的高可用性；如：Nginx 就无法保证自己的服务高可用，需要依赖 LVS 或者 keepalive。
2. 如：TCP 协议的负载均衡，有些请求是 TCP 协议的（Mysql、SSH），或者说这些请求只需要使用四层进行端口的转发就可以了，所以使用四层负载均衡。

总结：

1. 四层负载均衡仅能转发 TCP/IP 协议、UDP 协议、通常用来转发端口，如：TCP/22、udp/53
2. 四层负载均衡可以用来解决七层负载均衡端口限制问题；（七层负载均衡最大使用 65535 个端口号）
3. 四层负载均衡可以解决七层负载均衡高可用问题；（多台后端七层负载均衡能同事的使用）
4. 四层的转发效率比七层的高得多，但仅支持 TCP/IP 协议，不支持 HTTP 和 HTTPS 协议
5. 通常大并发场景通常会选择使用在七层负载前面增加四层负载均衡

七层负载均衡

七层负载均衡不同于四层负载均衡，它在高级应用层上执行，会处理每个消息的实际内容。HTTP 是网络上网站流量的主要七层协议。七层负载均衡以比四层负载均衡更复杂的方式路由网络流量，尤其适用于基于 TCP 的流量（如 HTTP）。七层负载均衡会终止网络流量并读取器中消息，它可以根据消息内容（如 URL 或 cookie）做出负载均衡决策。随后，七层负载均衡与选定上有服务器建立新的 TCP 连接并将请求写入服务器。

均衡策略

Nginx 的负载均衡策略可以划分为两大类：内置策略 和 扩展策略。

内置策略包含 加权轮询 和 ip hash，在默认情况下这两种策略会编译进 Nginx 内核，只需在 Nginx 配置中指明参数即可。

扩展策略有很多，如 fair、通用 hash、consistent hash 等，默认不编译进 Nginx 内核。

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

• 轮询策略（默认），请求按时间顺序，逐一分配到 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_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：限制最大的接收的连接数

动态负载均衡

自身监控

内置了对后端服务器的健康检查功能。如果 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 负载均衡