目录
1）在这里要注意一点，默认情况下，nginx会将uri地址自动拼接到后端服务器地址上
2）location以正则的方式匹配请求时，反向代理只支持写到后端服务器地址
一、nginx的反向代理
1、代理和反向代理的概念
这里其实完全可以把反向代理与负载均衡联系起来一块说的，因为nginx在做了反向代理的同时，又实现了负载均衡的功能。
我们先来聊聊什么是代理，代理是指Nginx接收到客户端请求后，将请求转发给后端服务器处理，并将后端服务器的响应返回给客户端。代理服务器充当中间人，隐藏了后端服务器的真实地址和细节，客户端与后端服务器之间的通信通过代理服务器进行。
反向代理是指Nginx接收到客户端请求后，根据配置规则将请求转发给多个后端服务器中的一个进行处理，并将后端服务器的响应返回给客户端。客户端并不知道请求是由哪个后端服务器处理的，反向代理服务器根据一定的算法从后端服务器池中选择合适的服务器进行负载均衡，以提高整体的性能和可用性。
代理和反向代理的概念可以简单理解为Nginx接收到客户端请求后，将请求转发给后端服务器处理，并将后端服务器的响应返回给客户端。不同之处在于代理是将请求转发给指定的后端服务器，而反向代理是根据一定的规则或算法选择合适的后端服务器进行转发。
2、反向代理的使用以及语法
在nginx的配置文件里，我们将反向代理定义在localtion里，主要语法为
proxy_pass 后端服务器地址
示例，这里将/mp3的请求转发给后端服务器/music地址
location /mp3 {
proxy_pass http://192.168.140.11/music;
}1）在这里要注意一点，默认情况下，nginx会将uri地址自动拼接到后端服务器地址上
我们接着看下一个示例：
将/testA的请求转交给后端首页处理
location /testA {
proxy_pass http://192.168.140.11;
}
location /testA {
proxy_pass http://192.168.140.11/;
}2）location以正则的方式匹配请求时，反向代理只支持写到后端服务器地址
location ~ /testB {
proxy_pass http://192.168.140.11;
} 3）配置后端服务器记录真实客户端地址
location /mp3 {
proxy_pass http://192.168.140.11/music;
proxy_set_header X-REAL-IP $remote_addr;
}
$remote_addr
nginx内置变量，真实客户端地址4）修改httpd日志格式
[root@web01 ~]# grep "LogFormat" /etc/httpd/conf/httpd.conf
LogFormat "%{X-REAL-IP}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined5）针对后端服务是nginx情况
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;main日志格式：
$http_x_forwarded_for3、upstream模块应用
1）、作用
- 实现后端服务的负载均衡
- 实现对后端服务的健康状态检查
2）调度算法
- rr 轮询 默认
- 将不同的请求转交到不同的后端服务器处理
- 支持权重weight
- 解决会话保持/持久
- 会话共享存储 NoSQL数据库(redis/memcached)
- ip_hash
-
- 根据客户端地址进行hash运算
- 将同一个客户端的请求在一段时间内转交到同一个后端服务器处理
- least_conn
- 最少连接
3）语法
upstream 组名 {
[调度算法];
server IP:port [weight=数字] [max_fails=2] [fail_timeout=2];
server IP:port [weight=数字] [max_fails=2] [fail_timeout=2];
server IP:port [weight=数字] [max_fails=2] [fail_timeout=2] [backup];
}
location {
proxy_pass http://组名;
}参数说明:
upstream组不能定义在某个server{}虚拟主机内部！！！！！！！！
- IP:port
- 后端真实服务器的地址
- weight
- 权重，默认为1
- max_fails
- 健康状态检查时，最大的失败次数
- fail_timeout
- 失败次数的间隔时间，单位为秒
- backup
- 指定备份服务器
4）配置upstream
upstream webserver {
server 192.168.140.11:80 weight=1 max_fails=2 fail_timeout=2;
server 192.168.140.12:80 weight=1 max_fails=2 fail_timeout=2;
server 127.0.0.1:8000 backup;
} location / {
proxy_pass http://webserver;
proxy_set_header X-REAL-IP $remote_addr;
} server {
listen 8000;
server_name localhost;
location / {
root /test2;
index index.html index.htm;
}
}二、nginx的负载均衡
1、nginx负载均衡的概念
nginx负载均衡器通过将请求从客户端分发到多个后端服务器上来实现负载均衡。它可以根据配置的算法（如轮询、IP哈希、最少连接等）来决定将请求发送给哪个后端服务器。这样可以确保每个后端服务器都能均衡地处理请求，避免出现单个服务器过载的情况。
nginx负载均衡器还提供了一些其他功能，如健康检查、故障转移和会话保持。通过健康检查，负载均衡器可以定期检查后端服务器的状态，并将请求转发到健康的服务器上。如果某个服务器不可用，负载均衡器会自动将请求转发到其他可用的服务器上，以确保服务的连续性。会话保持可以将同一客户端的请求发送到同一个后端服务器上，以保持会话的一致性。
总之，nginx负载均衡器可以有效地分发请求到多个后端服务器上，以提高系统的性能和可靠性。它是构建高可用、高性能Web应用和服务的重要组件之一。
2、配置nginx的负载均衡
1）HTTP的负载均衡
在进行 HTTP 流量负载均衡时，NGINX Plus 会先终止每个 HTTP 链接，然后再独立处理每一个 HTTP 连接和请求。您可以根据需求去剥离 SSL/TLS 加密，检查和操控请求内容，通过限制速率对请求进行优先级排列，然后再选择相应的负载均衡策略。
为了提高性能，NGINX Plus 可以自动针对一个 HTTP 事务应用多种的优化策略，包括 HTTP 协议升级、keepalive（长连接）优化，以及对该事务进行像是内容压缩、响应缓存这样的变换。
NGINX Plus 可以轻松进行针对 HTTP 流量的负载均衡：
http {
upstream my_upstream {
server server1.example.com;
server server2.example.com;
}
server {
listen 80;
location / {
proxy_set_header Host $host;
proxy_pass http://my_upstream;
}
}
}首先先使用 server 关键字定义虚拟服务器，然后指定 listen 关键字需要监听的流量端口。接着使用 location 块匹配客户端请求的 URL，再用 proxy_set_header 关键字指定 Host 的 HTTP 请求头，最后用 proxy_pass 关键字将请求转发到 upstream 组 （upstream 块定义了 NGINX Plus 用来均衡流量的服务器）。
欲知更多信息，请查看 NGINX 和 NGINX Plus 的负载均衡使用介绍。
2）TCP和UDP的负载均衡
NGINX Plus 还可以针对 TCP 应用程序（如 MySQL）和 UDP 应用程序（如 DNS 和 RADIUS）进行负载均衡。对于 TCP 应用程序，NGINX Plus 会先终止 TCP 连接，然后再创建到新的连接到系统后端。
stream {
upstream my_upstream {
server server1.example.com:1234;
server server2.example.com:2345;
}
server {
listen 1123 [udp];
proxy_pass my_upstream;
}
}此处的配置和针对 HTTP 的配置很相似：先使用 server 关键字来指定一个虚拟服务器，然后使用 listen 关键字指定需要监听的流量端口，最后再通过 proxy_pass 将请求发送到 upstream 组。
关于 TCP 和 UDP 负载均衡的更多信息，请参阅 NGINX Plus 管理员手册。
3、负载均衡方式
NGINX Plus 为 HTTP、TCP 和 UDP 提供多种负载均衡方式。所有这些方式都能够选择分配到每个上游服务器的流量的权重。
- Round Robin（轮询，默认使用）—— 可按顺序在上游服务器之间分发请求。
- 最少连接——向活跃连接数最少的服务器转发请求。
- 最少时间—— 基于响应时间和活跃连接数进行综合计算，将请求转发到负载最小的服务器 —— 这是只有 NGINX Plus 可以提供的独有功能。
- Hash（哈希）—— 根据特定的键值分发请求（如客户端 IP 地址或请求 URL）。若上游服务器集群发生变化，NGINX Plus 可以通过应用一致的哈希值来尽量减少负载的重新分配。
- IP Hash（仅限 HTTP）—— 根据客户端 IP 地址的前三个八位字节进行请求分配。
- Random with Two Choices—— 随机选择两台服务器并将请求转发到活动连接数较少的服务器（即，上方提到的“最少连接”算法）。通过使用 NGINX Plus，还可以通过“最少时间”算法优化使用效果。
4、利用 NGINX Plus 来限制连接数量
您可以限制 NGINX Plus 与上游 HTTP 或 TCP 服务器建立的连接数，或是与 UDP 服务器的建立的会话数。当与服务器的连接或会话数超过所定的限制时，NGINX Plus 会自动停止建立新的连接或会话。
比如在下面的配置代码中可以看到，webserver1 的连接限制为 250 个，webserver2 的连接限制为 150 个。 而 queue 关键字指定了 NGINX Plus 放在操作系统的监听队列中的最大连接数，每个连接在队列里最多保留 30 秒； 额外的连接请求将会被舍弃。
upstream backend {
zone backends 64k;
queue 750 timeout=30s;
server webserver1 max_conns=250;
server webserver2 max_conns=150;
}当服务器的活跃连接数低于自身限制时，NGINX Plus 就会将监听队列中的连接发送给该服务器。限制连接数会有助于保持针对客户端请求的服务的一致性和可预测性——即使是在流量高峰期也是如此。
5、会话保持
您可通过配置 NGINX Plus 来识别用户会话，并将同一会话中的所有请求发送到同一个上游服务器。当应用服务器将状态存储于本地时，这点至关重要——因为将一个正在进行中的用户会话发送到不同服务器会带来严重的问题。即使应用在集群环境下共享状态信息，会话保持仍有助于提高性能。
NGINX 开源版支持基于哈希值的会话保持算法（即 “Hash”和“IP Hash”两种负载均衡算法）。在此基础上，NGINX Plus 增加了基于 Cookie 的会话保持算法，其中包括了 sticky cookie。
NGINX Plus 将会话 cookie 添加在上游组件给特定客户端的第一个响应中，从而可以安全地识别生成响应的服务器。后续的客户端请求都会包含这个 cookie，这样 NGINX Plus 就可以将这些请求都路由至同一个上游服务器
upstream backend {
server webserver1;
server webserver2;
sticky cookie srv_id expires=1h domain=.example.com path=/;
}在上方的示例中，NGINX Plus 在客户端最开始的响应中插入了一个名为 srv_id 的 cookie 来标识处理该请求的服务器。当后续再收到包含该 cookie 的请求时，NGINX Plus 就会直接将该请求转发到同一个服务器。
另外，NGINX Plus 还支持粘性学习（sticky learn)和粘性路由（sticky route）会话保持算法。
注：基于 Cookie 的会话保持是 NGINX Plus 独有性能之一。
6、主动健康检查
默认情况下，NGINX 会对来自上游服务器的响应执行基础检查，并在可能的情况下重试失败的请求。NGINX Plus 添加了带外应用健康检查（也称“合成事务（synthetic transactions）”），还添加了一个慢启动功能，以便优雅地将新的或是恢复的服务器添加到负载均衡组。
这些功能使得 NGINX Plus 能够检测和解决更广泛的问题，从而显著提高 HTTP 和 TCP/UDP 应用的可靠性。
upstream my_upstream {
zone my_upstream 64k;
server server1.example.com slow_start=30s;
}
server {
# ...
location /health {
internal;
health_check interval=5s uri=/test.php match=statusok;
proxy_set_header Host www.example.com;
proxy_pass http://my_upstream
}
}
match statusok {
# Used for /test.php health check
status 200;
header Content-Type = text/html;
body ~ "Server[0-9]+ is alive";
} 在以上示例中，NGINX Plus 每 5 秒发就向 /test.php 发出一次请求。针对这些请求的响应必须满足 match 块中所定义的条件——即返回状态代码 200 OK 且 HTTP 响应体中包含 “ServerN is alive” 的文本——上游服务器才会被认为是处于健康状态。
注：主动健康检查为 NGINX Plus 独有性能之一
7、使用 DNS 进行服务发现
默认情况下，NGINX Plus 服务器启动时会去解析 DNS 名称，并持久地缓存解析值。例如，当您使用 example.com 来指定上游服务器并配合使用 server 关键字和 resolve 变量时，NGINX Plus 会定期重新解析域名。如果相关联的 IP 地址列表发生了变化，NGINX Plus 会立即开始在新的服务器组之间进行负载均衡。
若想要配置 NGINX Plus 来使用 DNS SRV 记录，需要在 server 关键字中加入 service=http 并包含 resolver 字段，如下所示：
resolver 127.0.0.11 valid=10s;
upstream service1 {
zone service1 64k;
server service1 service=http resolve;
}在上方示例中，NGINX Plus 以 10 秒为单位对 127.0.0.11（即内置 Docker DNS 服务器）进行查询，以刷新对于 service1 的域名解析。
注： 使用 DNS 进行服务发现为 NGINX Plus 独有性能之一。
8、NGINX Plus API
NGINX Plus 包含一个带有单个 API 端点的 RESTful API，从而能够在零停机时间的条件下动态更新上游配置和键值存储。
以下配置代码包含了 api 关键字从而启用对 /api 端点的读写访问。
upstream backend {
zone backends 64k;
server 10.10.10.2:220 max_conns=250;
server 10.10.10.4:220 max_conns=150;
}
server {
listen 80;
server_name www.example.org;
location /api {
api write=on;
}
} 当这个 API 像上面示例一样启用时，就可以使用下面的 curl 命令将新服务器添加到现有的上游组。上面的示例使用了 POST 方法，并通过 JSON 编码将服务器的IP地址设置为 192.168.78.66，权重设置为 200，最大同时连接数设置为 150。（关于代码中的 version 部分，请用参考文档中指定的 API 当前版本号进行替换。）
$ curl -iX POST -d '{"server":"192.168.78.66:80","weight":"200","max_conns":"150"}' http://localhost:80/api/version/http/upstreams/backend/servers/运行如下代码从而以 JSON 格式来展示所有后端上游服务器的完整配置：
$ curl -s http://localhost:80/api/version/http/upstreams/backend/servers/ | python -m json.tool
{
"backup": false,
"down": false,
"fail_timeout": "10s",
"id": 0,
"max_conns": 250,
"max_fails": 1,
"route": "",
"server": "10.10.10.2:220",
"slow_start": "0s",
"weight": 1
},
{
"backup": false,
"down": false,
"fail_timeout": "10s",
"id": 1,
"max_conns": 150,
"max_fails": 1,
"route": "",
"server": "10.10.10.4:220",
"slow_start": "0s",
"weight": 1
},
{
"backup": false,
"down": false,
"fail_timeout": "10s",
"id": 2,
"max_conns": 200,
"max_fails": 1,
"route": "",
"server": "192.168.78.66:80",
"slow_start": "0s",
"weight": 200
} 要修改现有上游服务器的配置，需要通过内部 ID 进行识别该服务器，内部 ID 为上方代码的输出结果中 id 字段的值。下方示例中的命令是使用 PATCH 方法将 ID 为 2 的服务器进行重新设置，指定 IP 和监听端口为 192.168.78.55:80，权重为 500，最大连接限制数为 350。
$ curl -iX PATCH -d '{"server":"192.168.78.55:80","weight":"500","max_conns":"350"}' http://localhost:80/api/version/http/upstreams/backend/servers/2 您可以在此网址查看 NGINX Plus API 完整 Swagger（OpenAPI 规范）文档：
Swagger UI.
注： NGINX Plus API 为 NGINX Plus 独有性能之一。
总结
以上就是博主对nginx的理解和汇总，参考文献来自nginx的官方文档，由于nginx的功能非常丰富，并且非常稳定，是当今主流的web应用之一，作为一名合格的运维人员，熟悉到精通nginx是必不可少的一步。如果大家有意见分歧的，欢迎评论留言，博主也会改进学习。
1267
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
