首先来介绍下nginx的反向代理。
代理服务器一般分为正向代理（通常直接称为代理服务器）和反向代理。
画个图我们就好理解了。
正向代理：可以想象成是路由器，我们要通过它来上网的那种。（可以说是客户端的代理）
反向代理：客户端的请求过来之后交给反向代理服务器，然后反向代理服务器再交给后台真实的服务器。（这个是服务器端的代理）
我们今天说的是nginx的反向代理功能的实现。同时，反向代理还可以实现负载均衡的功能。可以自己思考下。
由于实验比较简单，这边环境就简单处理。
http-server1：192.168.10.156（Apache服务）
http-server2：192.168.10.157（nginx服务）
nginx-proxy：192.168.10.159
保证http服务器搭建完成，并能正常访问
nginx-proxy安装（其他依赖条件自己安装）。版本：nginx-1.4.7.tar.gz
tar -zxvf nginx-1.4.7.tar.gz /home
./configure
--prefix=/usr/local/nginx \
--sbin-path=/usr/local/bin \
--conf-path=/etc \
--error-log-path=/usr/local/nginx/error.log \
--pid-path=/usr/local/nginx/ngnix.pid \
--lock-path=/usr/local/nginx/nginx.lock \
--with-http_ssl_module \
--with-http_gzip_static_module \
--with-http_perl_module \
--http-log-path=/usr/local/nginx/access.log \
--http-fastcgi-temp-path=/usr/local/nginx/html \
--with-pcre --with-zlib=/usr --with-openssl=/usr
make && make install
编辑nginx的配置文件。
vim /etc/nginx.conf
#user nobody;
worker_processes 1;
events {
worker_connections 1024;
}
http {
upstream loadbance {
server 192.168.10.156;
server 192.168.10.157;（如果其其他端口，后面请加端口号：X.X.X.X:8888)
}
server {
listen 80;
location / {
proxy_pass http://loadbance;
}
}
}
红色部分为搭建反向代理服务器所需要的简单配置。(注意，nginx行尾的分号）
upstream：反向代理的关键字
loadbance：你可以理解为后台一组服务器的名称
server： 后台真实的服务器地址，可以是IP或者FQDN（如果是FQDN，别忘记解析）
listen：监听的端口，如果没有把原来nginx做web服务器的配置内容注销掉，建议改为其他端口
proxy_pass：后面跟http://loadbance 此一定要和upstream后面（服务器组名称）的名称保持一致
OK，大功告成。访问进行测试。
访问代理服务器地址：http://192.168.10.159，然后刷新
这就是nginx的反向代理。其实我们还可以延伸下。
nginx的反向代理功能我认为就可以当做一个简单的负载均衡来使用，我们可以指定nginx的调度算法：
nginx的官网上说（其实个人认为不止4中，你可以在服务器的ip地址后面加上服务器的权值，但是按官网上加上权值是不算一种。）
NGINX supports four load balancing methods:
1）：The round-robin method 轮询
2）：The least_conn method 最少连接数
a request is sent to the server with the least number of active connections with server weights taken into consideration。请求会送到活跃链接最少的服务器上（服务器的权值要考虑进来的）
3）：The ip_hash method
The method guarantees that requests from the same address get to the same server unless it is not available。这种方法保证了来自同一个IP地址的请求会得到同一个服务器的响应，除非挂了。（其是通过客户端的ip（IPV4 or IPV6)地址来计算出此IP的hash值的）
4）；The generic hash method:
the server to which a request is sent is determined from a user-defined key which may be a text, variable, or their combination. For example, the key may be a source IP and port,
请求会发送到一个用户定义键值（可以是text，变量，或者混合的）的服务器上
再来看一个官网说的：
If a method other than the default one is used, the corresponding directive (least_conn,ip_hash or hash) should be specified inside the upstream before the server directives.如果你要使用其他的调度算法（默认使用的round-robin），相应的指令必须在upstream内部指定，并且要在server指令之前。
比如：最小数链接/ip_hash/hash $request_uri consistent;（如果是使用轮询的方式的话，就不用写了，因为默认算法就是轮询）
upstream loadbance {
least_conn; //或者是ip_hash和(hash $request_uri consistent)
server 192.168.10.156 weight=3; //可以设置权值的哦
server 192.168.10.157;（如果其其他端口，后面请加端口号：X.X.X.X:8888)
}
哎呀，我擦，这就扯远了。其实，nginx还有一个健康检查的功能，如果有台服务器挂了，请求不会分发到该服务器上。比如下面的写法：
upstream loadbance {
server 192.168.10.156 weight=3;
server 192.168.10.157;
server 192.168.10.158 backup;//当备机使用
server 192.168.10.155 down; //如果你要临时移除一台服务器进行升级或者其他操作，可以把其标记为down的状态，这样请求就不会到其上。
}
其实，我们还可以通过server内部的location指令来指定不同的路径分发到不同的服务器上去。来实现分流。
比如，可以定义多个upstream。upstream1，upstream2.......然后
location /mp3 {
proxy_pass http://upstream1;
}
location /flv {
proxy_pass http://upstream2;
}
等等等等。location后面的路径你可以使用精确路径，通配符，正则表达式扥等。OK，到此为止。要不然就刹不住了，东西太多了。
本文出自 “linux菜鸟” 博客，请务必保留此出处http://ludihua.blog.51cto.com/4601284/1602642
nginx 是优秀的反向代理服务器，这里主要讲它的健康检查和负载均衡机制，以及这种机制带来的问题。所谓健康检查，就是当后端出现问题（具体什么叫出现问题，依赖于具体实现，各个实现定义不一样），不再往这个后端分发请求，并且做后续的检查，直到这个后端恢复正常。所谓负载均衡，就是选择后端的方式，如何（根据后端的能力）将请求均衡的分发到后端。此外，当请求某个后端失败时，要将该请求分发到其它后端（redispatch）。这里以ngx_http_upstream_round_robin（简称RR）做为负载均衡模块，以ngx_http_proxy_module（检查proxy）作为后端代理模块。
nginx 的健康检查和负载均衡是密切相关的，它没有独立的健康检查模块，而是使用业务请求作为健康检查，这省去了独立健康检查线程，这是好处。坏处是，当业务复杂时，可能出现误判，例如后端响应超时，这是可能是后端宕机，也可能是某个业务请求自身出现问题，跟后端无关。如果后端宕机，nginx还要在将它标记为不可用之后，仍不时的将业务请求分发给它，以检查后端是否恢复。
nginx 完成客户端请求Header部分的解析，upstream 调用RR模块的peer.get 选择具体的后端。当请求结束，upstream 调用RR模块的peer.free，向RR反馈后端的健康情况。当upstream和后端通信时，出现错误会调用 ngx_http_upstream_next，
void ngx_http_upstream_next(ngx_http_request_t *r, ngx_http_upstream_t *u, ngx_uint_t ft_type); 第三个参数指明错误类型，共有如下错误类型
#define NGX_HTTP_UPSTREAM_FT_ERROR 0x00000002
#define NGX_HTTP_UPSTREAM_FT_TIMEOUT 0x00000004
#define NGX_HTTP_UPSTREAM_FT_INVALID_HEADER 0x00000008
#define NGX_HTTP_UPSTREAM_FT_HTTP_500 0x00000010
#define NGX_HTTP_UPSTREAM_FT_HTTP_502 0x00000020
#define NGX_HTTP_UPSTREAM_FT_HTTP_503 0x00000040
#define NGX_HTTP_UPSTREAM_FT_HTTP_504 0x00000080
#define NGX_HTTP_UPSTREAM_FT_HTTP_404 0x00000100
#define NGX_HTTP_UPSTREAM_FT_UPDATING 0x00000200
#define NGX_HTTP_UPSTREAM_FT_BUSY_LOCK 0x00000400
#define NGX_HTTP_UPSTREAM_FT_MAX_WAITING 0x00000800
#define NGX_HTTP_UPSTREAM_FT_NOLIVE 0x40000000
ngx_http_upstream_next，只要错误类型不是 NGX_HTTP_UPSTREAM_FT_HTTP_404，都认为后端有问题（NGX_PEER_FAILED）
if (ft_type == NGX_HTTP_UPSTREAM_FT_HTTP_404) {
state = NGX_PEER_NEXT;
} else {
state = NGX_PEER_FAILED;
}
ngx_http_upstream_next 调用RR的peer.free，RR根据state判断刚才接受请求的后端是否健康。
if (ft_type != NGX_HTTP_UPSTREAM_FT_NOLIVE) {
u->peer.free(&u->peer, u->peer.data, state);
}
ngx_http_upstream_next 如果超过最大重试次数（默认为后端的个数，每试过一个，就减1），或者proxy设置不允许redispatch，则向客户端返回响应status。
if (u->peer.tries == 0 || !(u->conf->next_upstream & ft_type)) {
ngx_http_upstream_finalize_request(r, u, status);
}
proxy 模块的 proxy_next_upstream 配置，在何种情况下将请求redispatch到下一个后端。
刚刚谈到，只要错误类型不是 NGX_HTTP_UPSTREAM_FT_HTTP_404，都认为后端有问题。这里的错误类型包括，连接后端失败，连接，读写后端超时，后端返回了500，502，504等。这个策略是有待商榷的，尤其是读写后端超时也判断为后端不可用。因为某个业务请求，可能因为自身的原因而导致读写超时。注意，在proxy_next_upstream 中指定timeout，http_504 是不同的，前者表示upstream连接，读写后端超时，后者表示后端返回的http code 是504。
实际上健康检查不是必须的，因为redispatch的存在保证了，就算有后端宕机，客户端仍将收到正确的响应。那么我们考虑关掉健康检查。通过upstream 的server配置的max_fails 参数
RR 的peer.get，如果max_fails 为0，则该后端总是可用的（就算它真有问题）。
if (peer->max_fails == 0
|| peer->fails < peer->max_fails)
{
break;
}
因为redispatch的次数，取决于后端的个数，所以后端的个数稍微多一点是有好处的。
下面是一些佐证分析的测试。
upstream test {
server 127.0.0.1:8060 max_fails=0;
server 127.0.0.1:8070 max_fails=0;
server 127.0.0.1:8080 max_fails=0;
server 127.0.0.1:8090 max_fails=0;
}
只有8060，8070是存活的，8080，8090处于不可用状态，这里max_fails=0，关闭了健康检查。
proxy_read_timeout 2;
读超时设为2S。
proxy_next_upstream error timeout;
默认当 error 和 timeout发生时，redispatch。
测试请求的sleep参数指定后端的sleep时间，code参数指定后端返回的http code。根据time和sleep时间的对比，判断重试了几个后端。
time curl "http://127.0.0.1:8099/index.php?sleep=3" -vv
real 0m4.014s
sleep=3，读超时，重试了2个后端。
修改配置 proxy_next_upstream error;
time curl "http://127.0.0.1:8099/index.php?sleep=3" -vv
real 0m2.018s
读超时，不再redispatch，重试了1个后端。
修改配置 proxy_next_upstream error http_504;
time curl "http://127.0.0.1:8099/index.php?sleep=1" -vv
real 0m1.022s
这个是正常请求。
time curl "http://127.0.0.1:8099/index.php?sleep=1&code=504" -vv
real 0m2.023s
让后端返回504，此时nginx会做redispatch，重试了2个后端
但是nginx返回给客户端的是502，不是504，因为所有的后端都返回504，nginx认为后端不可用，返回502.
测试健康检查，关掉redispatch。proxy_next_upstream off;
curl "http://127.0.0.1:8099/index.php?sleep=3" -vv
返回了两次502，两次504。存活的后端返回504，有问题的返回502。
修改 max_fails server 127.0.0.1:8060 max_fails=1; 对8060开启健康检查。
curl "http://127.0.0.1:8099/index.php?sleep=3" -vv
第一轮4次请求，返回两次502，两次504
8080和8090有问题，返回502，8060和8070响应超时，返回504，因为8060开启了健康检查，并且返回了504，所以被标记为不可用。
第二轮4次请求，返回三次502，一次504。8070没有开启健康检查，所以仍然返回504。
根据测试分析，业务请求（sleep 3s，或者 输出 http 504）可以让nginx误以为后端宕了，而这时后端活得好好的。在私有云平台，这个通常不是问题，把超时设大点，不返回5XX错误，可以避免这个问题。但是在公有云平台，这是致命的，因为业务可以编程输出5XX错误。有两种方法应对，一种是关闭健康检查，一种是修改nginx的代码，仅对 NGX_HTTP_UPSTREAM_FT_ERROR 判定为后端有问题。
转载于:https://blog.51cto.com/7090376/1604232
1124
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
