Nginx的静态处理能力很强但是动态处理能力不足因此在企业中常用动静分离技术。动静分离技术其实是采用代理的方式在server{}段中加入带正则匹配的location来指定匹配项针对PHP的动静分离静态页面交给Nginx处理动态页面交给PHP-FPM模块或Apache处理。在Nginx的配置中是通location配置段配合正则匹配实现静态与动态页面的不同处理方式1.前端Nginx收到静态请求直接从NFS中返回给客户端。2.前端Nginx收到动态请求转交给通过FastCGI交给PHP服务器处理。----如果得到静态结果直接从NFS取出结果交给Nginx然后返回给客户端。----如果需要数据处理PHP服务器连接数据库后将结果返回给Nginx3.前端Nginx收到图片请求以.jpg、.png、.gif等请求交给后端Images服务器处理。server { listen 80; server_name localhost; index index.php index.html; root /app/blog; location ~* \.(css|js)$ { #NFS root /var/html/static } location ~* \.(png|ico|gif|jpg|jpeg)$ { #location匹配将图片交给Image处理 proxy_pass http://10.10.0.23:80; #Image服务器要开启web服务 } location ~* \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /var/html/yd_laravel/public$fastcgi_script_name; include /usr/local/nginx/conf/fastcgi_params; } }proxy_pass配置实现反向代理功能。执行 telnet 10.10.0.23验证成功反向代理故障节点自动摘流配置用到check模块是nginx_upstream_check_module淘宝 Tengine 模块upstream web { server 192.168.156.14:8889; server 192.168.156.15:8889; check fall3 interval3000 rise2 timeout2000 typehttp; check_http_expect_alive http_2xx http_3xx; check_http_send GET /web/v2/alive/check HTTP/1.0\r\n\r\n; }轮询策略未指定 ip_hash/weight默认轮询check 参数说明Tengine 健康检查interval3000每 3000ms (3s) 探测一次后端fall3连续 3 次探测失败 → 标记节点 down摘除流量rise2连续 2 次探测成功 → 节点恢复 up重新接入流量timeout2000探测请求 2 秒超时判定失败探测接口GET /web/v2/alive/check返回 2xx/3xx 认为存活nginx反向代理真实IP在编译Nginx时可通过添加http_realip_module模块来获取真实客户端IP地址。何为真实IP地址呢请看下图既获取到的真实客户端IP是101既不是正向代理服的104也不是反向代理的105proxy_set_header配置获取真实IPupstream联合proxy_pass实现负载均衡upstream phpserver { server 10.141.8.55:8005; server 10.141.8.55:8006; } server { listen 80; server_name www.xxx.com; log_not_found off; access_log /var/log/nginx/html-access.log main; charset utf-8; location / { proxy_pass http://phpserver; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header REMOTE-HOST $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 3600; proxy_send_timeout 3600; proxy_read_timeout 3600; proxy_buffer_size 256k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k; proxy_temp_file_write_size 256k; proxy_next_upstream error timeout invalid_header http_500 http_503 http_404; proxy_max_temp_file_size 128m; } }PHP脚本打印IP?php foreach($_SERVER as $k$v) echo $k . . $v . br /;在默认配置情况下如果要取得客户端真实IP地址的话只有取HTTP_X_FORWARDED_FOR的第一个逗号前的IP地址最靠谱nginx的TCP的反向代理Nginx默认只支持http的反向代理nginx在1.9版本之后想要支持tcp的反向代理需要在编译时增加tcp代理模块stream { upstream backend_server { server 10.100.138.15:8787; server 10.100.138.30:8787; } }nginx做TCP代理并不仅仅局限于WEB的URL请求还可以转发如memcached、MySQL等点到点的请求。TCP负载均衡原理上和LVS等是一致的工作在更为底层性能会高于原来HTTP负载均衡不少nginx的反向代理服务同时使用Http-basic模块来做HTTP验证。用于定义一个 Location 块且该块不能被外部 Client 所访问只能被 Nginx 内部配置指令所访问比如 try_files or error_pageupstream elasticsearch { server 127.0.0.1:9200; } server { location / { error_page 590 elasticsearch; error_page 595 protected_elasticsearch; if ($request_uri ~ ^/_cat/.*$) { return 590; } return 595; } location elasticsearch { proxy_pass http://elasticsearch; proxy_redirect off; } location protected_elasticsearch { auth_basic Protected Elasticsearch; auth_basic_user_file passwords; proxy_pass http://elasticsearch; proxy_redirect off; } }我们定义两个状态代码590-不需要验证595-需要验证使用nginx的location功能两个location都指向同一个集群但是其中一个需要认证添加$_SERVER服务器环境变量在PHP开发中为了区分线上生产环境还是本地开发环境如果我们能通过判断$_SERVER[APP_DEV]为 DEV还是PRO来区分该多好include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param APP_DEV PRO; # PRO or DEVNginx负载均衡策略nginx的负载均衡策略可以划分为两大类内置策略和扩展策略。内置策略包含加权轮询和ip hash在默认情况下这两种策略会编译进nginx内核只需在nginx配置中指明参数即可。扩展策略有很多如fair、通用hash、consistent hash等默认不编译进nginx内核。1、轮询默认每个请求按时间顺序逐一分配到不同的后端服务器如果后端服务器down掉能自动剔除。upstream backserver { server 192.168.0.14; server 192.168.0.15; }2、weight权重轮询策略指定轮询几率weight和访问比率成正比用于后端服务器性能不均的情况。upstream backserver { server 192.168.0.14 weight3;#30% server 192.168.0.15 weight7; }权重越高在被访问的概率越大如上例分别是30%70%。上述方式存在一个问题就是说在负载均衡系统中假如用户在某台服务器上登录了那么该用户第二次请求的时候因为我们是负载均衡系统每次请求都会重新定位到服务器集群中的某一个那么已经登录某一个服务器的用户再重新定位到另一个服务器其登录信息将会丢失这样显然是不妥的。3、ip_hash我们可以采用ip_hash指令解决这个问题如果客户已经访问了某个服务器当用户再次访问时会将该请求通过哈希算法自动定位到该服务器。每个请求按访问ip的hash结果分配这样每个访客固定访问一个后端服务器可以解决session的问题。用ip_hash做会话保持有很大的缺陷它是通过客户端ip来实现负载不会很均匀。upstream backserver { ip_hash; server 192.168.0.14:88; server 192.168.0.15:80; }4、fair第三方upstream-fair模块按后端服务器的响应时间来分配请求响应时间短的优先分配。upstream backserver { server server1; server server2; fair; }5、url_hash第三方nginx_upstream_hash模块按访问url的hash结果来分配请求使每个url定向到同一个后端服务器后端服务器为缓存时比较有效。upstream backserver { server squid1:3128; server squid2:3128; hash $request_uri; hash_method crc32; }6.Sticky策略第三方nginx-sticky-module模块它是基于cookie的一种nginx的负载均衡解决方案通过分发和识别cookie来使同一个客户端的请求落在同一台服务器上可以解决session的问题。upstream backserver{ sticky; server 172.31.3.82:9170; server 172.31.3.82:9171; server 172.31.3.82:9173; }upstream的参数列表如下down表示单前的server暂时不参与负载weight默认为1.weight越大负载的权重就越大。max_fails允许请求失败的次数默认为1.当超过最大次数时返回proxy_next_upstream模块定义的错误fail_timeout:max_fails次失败后暂停的时间。backup其它所有的非backup机器down或者忙的时候请求backup机器。所以这台机器压力会最轻。keepalive连接数keepalive的值指定了每个工作进程中保留的持续连接到nginx负载均衡器缓存的最大值。如果超过这个设置值的闲置进程想链接到nginx负载均衡器组最先连接的将被关闭。location对URL进行匹配.可以进行重定向或者进行新的代理负载均衡注nginx支持同时设置多组的负载均衡用来给不用的server来使用。