共计 4628 个字符,预计需要花费 12 分钟才能阅读完成。
负载均衡在服务端开发中算是一个比较重要的特性。因为 Nginx 除了作为常规的 Web 服务器外,还会被大规模的用于反向代理前端,因为 Nginx 的异步框架可以处理很大的并发请求,把这些并发请求 hold 住之后就可以分发给后台服务端 (backend servers,也叫做服务池,后面简称 backend) 来做复杂的计算、处理和响应,这种模式的好处是相当多的:隐藏业务主机更安全,节约了公网 IP 地址,并且在业务量增加的时候可以方便地扩容后台服务器。
负载均衡可以分为硬件负载均衡和软件负载均衡,前者一般是专用的软件和硬件相结合的设备,设备商会提供完整成熟的解决方案,通常也会更加昂贵。软件的负载均衡以 Nginx 占据绝大多数,本文也是基于其手册做相应的学习研究的。
负载均衡涉及到以下的基础知识。
用户 (浏览器) 在和服务端交互的时候,通常会在本地保存一些信息,而整个过程叫做一个会话 (Session) 并用唯一的 Session ID 进行标识。会话的概念不仅用于购物车这种常见情况,因为 HTTP 协议是无状态的,所以任何需要逻辑上下文的情形都必须使用会话机制,此外 HTTP 客户端也会额外缓存一些数据在本地,这样就可以减少请求提高性能了。如果负载均衡可能将这个会话的请求分配到不同的后台服务端上,这肯定是不合适的,必须通过多个 backend 共享这些数据,效率肯定会很低下,最简单的情况是保证会话一致性——相同的会话每次请求都会被分配到同一个 backend 上去。
出问题的 backend 要能被及时探测并剔除出分配群,而当业务增长的时候可以灵活的添加 backend 数目。此外当前风靡的 Elastic Compute 云计算服务,服务商也应当根据当前负载自动添加和减少 backend 主机。
通常现代的网络服务者一个域名会关连到多个主机,在进行 DNS 查询的时候,默认情况下 DNS 服务器会以 round-robin 形式以不同的顺序返回 IP 地址列表,因此天然将客户请求分配到不同的主机上去。不过这种方式含有固有的缺陷:DNS 不会检查主机和 IP 地址的可访问性,所以分配给客户端的 IP 不确保是可用的(Google 404);DNS 的解析结果会在客户端、多个中间 DNS 服务器不断的缓存,所以 backend 的分配不会那么的理想。
Nginx 中的负载均衡配置在手册中描述的极为细致,此处就不流水帐了。对于常用的 HTTP 负载均衡,主要先定义一个 upstream 作为 backend group,然后通过 proxy_pass/fastcgi_pass 等方式进行转发操作,其中 fastcgi_pass 几乎算是 Nginx+PHP 站点的标配了。
Nginx 中的会话一致性是通过 sticky 开启的,会话一致性和之前的负载均衡算法之间并不冲突,只是需要在第一次分配之后,该会话的所有请求都分配到那个相同的 backend 上面。目前支持三种模式的会话一致性:
(1). Cookie Insertion
在 backend 第一次 response 之后,会在其头部添加一个 session cookie,即由负载均衡器向客户端植入 cookie,之后客户端接下来的请求都会带有这个 cookie 值,Nginx 可以根据这个 cookie 判断需要转发给哪个 backend 了。
sticky cookie srv_id expires=1h domain=.example.com path=/;
上面的 srv_id 代表了 cookie 的名字,而后面的参数 expires、domain、path 都是可选的。
(2). Sticky Routes
也是在 backend 第一次 response 之后,会产生一个 route 信息,route 信息通常会从 cookie/URI 信息中提取。
route $route_cookie $route_uri;
这样 Nginx 会按照顺序搜索 routecookie、route_uri 参数并选择第一个非空的参数用作 route,而如果所有的参数都是空的,就使用上面默认的负载均衡算法决定请求分发给哪个 backend。
(3). Learn
较为的复杂也较为的智能,Nginx 会自动监测 request 和 response 中的 session 信息,而且通常需要回话一致性的请求、应答中都会带有 session 信息,这和第一种方式相比是不用增加 cookie,而是动态学习已有的 session。
这种方式需要使用到 zone 结构,在 Nginx 中 zone 都是共享内存,可以在多个 worker process 中共享数据用的。(不过其他的会话一致性怎么没用到共享内存区域呢?)
learn
create=$upstream_cookie_examplecookie
lookup=$cookie_examplecookie
zone=client_sessions:1m
timeout=1h;
主要是有需要关闭某些 backend 以便维护或者升级,这些关键性的服务都讲求 gracefully 处理的:就是新的请求不会发送到这个 backend 上面,而之前分配到这个 backend 的会话的后续请求还会继续发送给他,直到这个会话最终完成。
让某个 backend 进入 draining 的状态,既可以直接修改配置文件,然后按照之前的方式通过向 master process 发送信号重新加载配置,也可以采用 Nginx 的 on-the-fly 配置方式。
$ curl http://localhost/upstream_conf?upstream=backend
$ curl http://localhost/upstream_conf?upstream=backend\&id=1\&drain=1
通过上面的方式,先列出各个 bacnkend 的 ID 号,然后 drain 指定 ID 的 backend。通过在线观测 backend 的所有 session 都完成后,该 backend 就可以下线了。
backend 出错会涉及到两个参数,max_fails=1 fail_timeout=10s; 意味着只要 Nginx 向 backend 发送一个请求失败或者没有收到一个响应,就认为该 backend 在接下来的 10s 是不可用的状态。
通过周期性地向 backend 发送特殊的请求,并期盼收到特殊的响应,可以用以确认 backend 是健康可用的状态。通过 health_check 可以做出这个配置。
match server_ok {
status 200-399;
header Content-Type = text/html;
body !~ "maintenance mode";
}
server {
location / {
proxy_pass http://backend;
health_check interval=10 fails=3 passes=2 match=server_ok;
}
}
上面的 health_check 是必须的,后面的参数都是可选的。尤其是后面的 match 参数,可以自定义服务器健康的条件,包括返回状态码、头部信息、返回 body 等,这些条件是 && 与关系。默认情况下 Nginx 会相隔 interval 的间隔向 backend group 发送一个”/“的请求,如果超时或者返回非 2xx/3xx 的响应码,则认为对应的 backend 是 unhealthy 的,那么 Nginx 会停止向其发送 request 直到下次改 backend 再次通过检查。
在使用了 health_check 功能的时候,一般都需要在 backend group 开辟一个 zone,在共享 backend group 配置的同时,所有 backend 的状态就可以在所有的 worker process 所共享了,否则每个 worker process 独立保存自己的状态检查计数和结果,两种情况会有很大的差异哦。
Nginx 的 backend group 中的主机可以配置成域名的形式,如果在域名的后面添加 resolve 参数,那么 Nginx 会周期性的解析这个域名,当域名解析的结果发生变化的时候会自动生效而不用重启。
http {
resolver 10.0.0.1 valid=300s ipv6=off;
resolver_timeout 10s;
server {
location / {proxy_pass http://backend;}
}
upstream backend {
zone backend 32k;
least_conn;
...
server backend1.example.com resolve;
server backend2.example.com resolve;
}
}
如果域名解析的结果含有多个 IP 地址,这些 IP 地址都会保存到配置文件中去,并且这些 IP 都参与到自动负载均衡。
通常,HTTP 和 HTTPS 的负载均衡叫做七层负载均衡,而 TCP 和 UDP 协议的负载均衡叫做四层负载均衡。因为七层负载均衡通常都是 HTTP 和 HTTPS 协议,所以这种负载均衡相当于是四层负载均衡的特例化,均衡器可以根据 HTTP/HTTPS 协议的头部(User-Agent、Language 等)、响应码甚至是响应内容做额外的规则,达到特定条件特定目的的 backend 转发的需求。
除了 Nginx 所专长的 HTTP 负载均衡,Nginx 还支持 TCP 和 UDP 流量的负载均衡,适用于 LDAP/MySQL/RTMP 和 DNS/syslog/RADIUS 各种应用场景。这类情况的负载均衡使用 stream 来配置,Nginx 编译的时候需要支持–with-stream 选项。查看手册,其配置原理和参数和 HTTP 负载均衡差不多。
因为 TCP、UDP 的负载均衡都是针对通用程序的,所以之前 HTTP 协议支持的 match 条件 (status、header、body) 是没法使用的。TCP 和 UDP 的程序可以根据特定的程序,采用 send、expect 的方式来进行动态健康检测。
match http {
send "GET / HTTP/1.0\r\nHost: localhost\r\n\r\n";
expect ~* "200 OK";
}
slow_start=30s:防止新添加 / 恢复的主机被突然增加的请求所压垮,通过这个参数可以让该主机的 weight 从 0 开始慢慢增加到设定值,让其负载有一个缓慢增加的过程。
max_conns=30:可以设置 backend 的最大连接数目,当超过这个数目的时候会被放到 queue 队列中,同时队列的大小和超时参数也可以设置,当队列中的请求数大于设定值,或者超过了 timeout 但是 backend 还不能处理请求,则客户端将会收到一个错误返回。通常来说这还是一个比较重要的参数,因为 Nginx 作为反向代理的时候,通常就是用于抗住并发量的,如果给 backend 过多的并发请求,很可能会占用后端过多的资源(比如线程、进程非事件驱动),最终反而会影响 backend 的处理能力。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)