基于Nginx的负载均衡概述与实现

229次阅读

共计 4215 个字符，预计需要花费 11 分钟才能阅读完成。

前言：

前面我们提到了 LVS 和 Keepalived 结合起来的高可用负载均衡，LVS 根据原目 ip 地址及端口将其调度转发至后端的某个主机，是一种四层的实现，因为 LVS 是四层的，所以不会受限于套接字或打开的文件数量。不过，如果我们想实现一些更高阶的功能，LVS 就显得力不从心了，比如基于 uri，cookie，header 头部信息的负载均衡，此时我们就可以选择一些 7 层的负载均衡实现，比如 Nginx 或 haproxy 等。本次我们就先来讲讲 Nginx 的负载均衡。

LVS http://www.linuxidc.com/Linux/2017-03/141927.htm
Keepalived http://www.linuxidc.com/Linux/2017-03/141929.htm

正文：

其实，如果对 LVS 的各种类型和调度有清晰的认识，那么理解 Nginx 的负载均衡并没有什么难度，无非就是监听前端 server 的 ip 和端口，并指定后端可调用的服务器地址就好~ 虽然 Nginx 也有健康检测机制，但是只有在 Nginx plus 中才能能使用。不过如果后端服务的端口不存在 Nginx 倒也不会向其调用请求啦~ 那我们来具体说说。

uostream

ngin 的负载均衡得用到 upstream 模块，它用来定义一个后端服务器组，即把所有后端的服务器整合在一起，然后通过 proxy 代理到这个服务器组。就能实现简单的 http 负载均衡了，upstream 默认的调度方式是 wrr(具体内容可参考 LVS 中的介绍)，所以我们只用指定服务器的 ip，如果端口不是默认 80 端口也可以单独指定，还有一些调度用到的参数，比如权重。如果只是干巴巴的介绍也很抽象，我们就根据配置来介绍吧。

http{
…
upstream backserver {#backserver 是一个自定义的名字，后面会调用
server 172.16.53.101; #第一个后端 server
server 172.16.53.102 ; #第二个后端 server
}
…
server {
listen 80;
server_name xiaofengfeng.cn;
location / {
proxy_pass #代理到服务器组，此处只支持 http/https
index index.html;
}
}
}

上面就是一个最简单的基于 nginx 的服务均衡配置了。upstream 的 server 后面还可以加许多参数，比如设置不同的权值 weight=number，权值越大调用的次数越多。backup 参数可以设置 backup server，比如我们可以设置本机为 backup server，当后端服务器都不能访问的时候，我们本机可以提供一个 sorry 页面。

http{
…
upstream backserver {
server 172.16.53.101;
server 172.16.53.102 ;
server 127.0.0.1 backup;
#指定本机回环地址为备用 server，此处我们提供一个 sorry server
}
server {
listen 192.168.157.128:80; #代理服务只监听前端服务的 ip 和端口
server_name xiaofengfeng.cn;
location / {
proxy_pass http://backserver;
index index.html;
}
}
server {
listen 127.0.0.1:80; #回环地址用来做 sorry server
server_name xiaofengfeng2.cn;
location / {
root /var/nginx;
index index.html;
}
}
}

注：因为我们改变了监听的 ip 所以得重启 nginx 服务，而不是用 nginx -s reload。

除了 server 配置选项还有其他一些常用的，比如我们可以改变其调用算法为 wlc，即 least_conn，就会根据后端服务器的连接数来调用。如果我们的一些用户信息，比如说 session，cookie 等保存在后端服务器本地，为了放置用户信息丢失，我们可以让一个用户的请求都发送到同一个后端服务器。ip_hash 就可以实现这样的功能。来自同一个源 IP 地址的请求始终发往同一个 upstream server。除了根据源地址 hash，我们还可以指定特定的参数来作为 hash 的条件，比如，如果我们用 uri 作为 hash 条件，那么同一个 uri 的请求会发往同一台后端服务器。此时我们就要用到 hash 选项，比如：

hash $request_uri consistent

$request_uri 是内置提供的变量，就是请求的 uri 咯，consistent 是一致性哈希算法，这个倒是可以说道说道。我们知道哈希就是无论输入什么值，都会得到一个固定长度的散列值，我们对不同的 uri 求散列值，如果后端服务器有 6 台服务器，然后给他们进行编号 0 -6，然后用求的散列值对 6 做取余运算，就一定会得到 0 - 6 中的一个值，然后把这个分配给对应编号的服务器。不过，这个算法有个问题，如果某个服务器挂掉，我们就得重新以 5 来做取余运算，然后重新把所有过程从来一遍。所以就出现了上面的一致性哈希算法，我们现在先不关注后端有几台服务器，我们把 0 到 2 的 32 次方减一这个多个数字分布在一个圆环上，就上钟表上的 0 -12 一样，0 的地方就是 12. 然后我们对后端每个服务器的 ip 地址做哈希计算，得到的值在和 2 的 32 次方做取余运算，那么后端的这些服务器一定会分布在这个圆环上的某个点处，然后我们在对 hash 选项指定的内容，此处是 uri 做 hash 计算，得到的值在和 2 的 32 次方取余，所以这些 uri 也会分布在这个圆环上。然后我们规定，在这个圆环上分布的服务器，负责响应它到它下一个服务器的区间上分布的请求。此时当后端的某台服务器挂掉时，只会影响这台服务器后面的 URI 请求，而不会影响其他服务器，只用把属于这台服务器的请求，给它上一台就好，我们画个图说明下。

基于 Nginx 的负载均衡概述与实现

我们用方块表示后端服务器经过哈希计算的分布情况，用红色的线表示不同 uri 请求的分布情况，服务器 1 只用负责 1 到 2 之间的 uri 请求，以此类推，5 只用负责 5 到 1 之间的 uri 请求，如右图所示，假如 2 号服务器挂掉了，我们就把所有属于 2 号服务器的请求分配给 1 号服务器~ 好啦~ 这就是一致性哈希算法~~~ 很重要哟，许多地方都有用到。

除了支持 web 服务的负载均衡，nginx 还支持其他服务的负载均衡，此时我们就得用到另外 d 的模块 stream 和 stream_proxy_module。不过这两个模块必须得是 1.9.13 以上的版本~ 并且默认 stream 并没有加载。得在编译时加入 –with-stream 选项，不过如果我们用的是预编译的 rpm 包安装的话，默认是有这个的~ 以下是 /etc/nginx/nginx.conf

user nginx;
worker_processes 1;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
worker_connections 1024;
}
stream {
upstream sshsrvs {
server 192.168.10.130:22;
server 192.168.10.131:22;
}

server {
listen 172.16.100.6:22202;
proxy_pass sshsrvs;
proxy_timeout 60s;
proxy_connect_timeout 10s;
}

}