一、代理服务
比较容易理解吧，简单来说。客户端访问服务器并不是直接访问的，而是通过中间代理服务器，代理服务器再去访问服务器。就像一个中转站一样，无论什么，只要从客户端到服务器，你就要通过我。
一）正向代理
正向代理，就是代理服务器为客户端代理，也就是说，服务器并不知道真实的客户端是谁，而是通过代理服务器把请求发送给真实的服务器。比如，通过公司网络访问外网百度，那么公司的代理服务器就会代理你的主机，访问百度网站。百度服务器无法获得你个人的真实主机ip。
就像上图展示的那样。web1、web2就是你在公司内的个人主机ip，然后通过公司的nginx代理服务器，访问外部网络。
语法：
Syntax: proxy_pass URL Default: -- Context: server,location
实践：
删除之前的配置，然后我们加下正向代理的配置：
resolver 8.8.8.8; #谷歌的域名解析地址 location / { # $http_host 要访问的主机名 $request_uri请求路径 proxy_pass http://$http_host$request_uri; }
这样，nginx的正向代理配置其实就ok了，哦对，别忘了重载nginx服务器。为了我们可以用本地测试，还需要一些额外的修改。Windows系统，修改下本机的hosts文件，地址在：C:\Windows\System32\drivers\etc。里面有个hosts，通过编辑器打开，添加如下内容：
ip（你服务器的ip）（空格）域名（随便一个域名）
我的添加完了之后是这样的：
然后，你可以正常访问百度，或者其他域名地址，或者也可以通过curl来访问。但是这样我们实际上比较无感，所以我们来看下nginx日志，日志在/var/log/nginx/access.log中。
二）反向代理
反向代理，简单来说就是代理服务器代理的是服务器，客户端并不知道真正的服务器是什么。
nginx配置如下：
location ~ ^/api { proxy_pass http://localhost:3000; proxy_redirect default; #重定向 proxy_set_header Host $http_host; #向后传递头信息 proxy_set_header X-Real-IP $remote_addr; #把真实IP传给应用服务器 proxy_connect_timeout 30; #默认超时时间 proxy_send_timeout 60; # 发送超时 proxy_read_timeout 60; # 读取超时 proxy_buffering on; # 在proxy_buffering 开启的情况下，Nginx将会尽可能的读取所有的upstream端传输的数据到buffer，直到proxy_buffers设置的所有buffer们 被写满或者数据被读取完(EOF) proxy_buffers 4 128k; # proxy_buffers由缓冲区数量和缓冲区大小组成的。总的大小为number*size proxy_busy_buffers_size 256k; # proxy_busy_buffers_size不是独立的空间，他是proxy_buffers和proxy_buffer_size的一部分。nginx会在没有完全读完后端响应的时候就开始向客户端传送数据，所以它会划出一部分缓冲区来专门向客户端传送数据(这部分的大小是由proxy_busy_buffers_size来控制的，建议为proxy_buffers中单个缓冲区大小的2倍)，然后它继续从后端取数据，缓冲区满了之后就写到磁盘的临时文件中。 proxy_buffer_size 32k; # 用来存储upstream端response的header proxy_max_temp_file_size 256k; # response的内容很大的 话，Nginx会接收并把他们写入到temp_file里去，大小由proxy_max_temp_file_size控制。如果busy的buffer 传输完了会从temp_file里面接着读数据，直到传输完毕。 }
然后需要我们在服务器上安装一下node，简单来说通过下载node官网的linux版node的二进制包，通过ftp传输到服务器。然后解压缩node包，然后配置node环境变量即可。这个就不多说了，大家可以百度一下。
然后我们在服务器新建一个node的http服务，端口号3000、4000、5000，对，创建三个文件。是在服务器上哦，实际上跟在本地没啥区别。
然后我们通过浏览器，你的ip/api/xxx就可以代理到3000端口的服务了。哦对，别忘了在服务器启动你的node服务。
二、负载均衡
我们先来看张图吧：
使用集群是网站解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足时，不要企图去换更强大的服务器，对大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务需求。这种情况下，更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。通过负载均衡调度服务器，将来自浏览器的访问请求分发到应用服务器集群中的任何一台服务器上，如果有更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不再成为整个网站的瓶颈。
那么下面，我们来看下，如何通过nginx服务器，配置集群。首先，我们需要在nginx服务器，同过不同的端口号，创建几个node服务。node服务的代码类似这样：
var http = require( 'http' ); var server =http.createServer( function ( request ,response ){ response.end('server3 000'); } ); server.listen( 3000 ,function(){ console.log( 'HTTP服务器启动中，端口：3000' ); });
然后，nginx中可以这样配置：
http{ upstream zhufeng { server 127.0.0.1:3000 weight=10; server 127.0.0.1:4000; server 127.0.0.1:5000; } server { location / { proxy_pass http://zhufeng; } } }
然后呢，安装一下pm2：
yum install pm2 -g
如果太慢的话，可以试试淘宝源。这里就不说怎么配置了哦。然后安装好pm2后，通过pm2启动各个node服务。pm2是一个node应用的进程管理器。
然后，可以通过以下命令来启动和查看node服务进程：
# 启动node服务
pm2 start xxx.js name xxx
# 查看当前服务
pm2 list
后端服务器调试状态：
| 状态 | 描述 |
|---|---|
| down | 当前的服务器不参与负载均衡 |
| backup | 当其它节点都无法使用时的备份的服务器 |
| max_fails | 允许请求失败的次数,到达最大次数就会休眠 |
| fail_timeout | 经过max_fails失败后，服务暂停的时间,默认10秒 |
| max_conns | 限制每个server最大的接收的连接数,性能高的服务器可以连接数多一些 |
例子：
upstream webserver{ server localhost:3000 down; server localhost:4000 backup; server localhost:5000 max_fails=1 fail_timeout=10s; }
分配方式：
| 类型 | 种类 |
|---|---|
| 轮询(默认) | 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除 |
| weight(加权轮询) | 指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况 |
| ip_hash | 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题 |
| least_conn | 哪个机器上连接数少就分发给谁 |
| url_hash(第三方) | 按访问的URL地址来分配 请求，每个URL都定向到同一个后端 服务器上(缓存) |
| fair(第三方) | 按后端服务器的响应时间来分配请求，响应时间短的优先分配 |
| 正定义hash | hash自定义key |
例子：
upstream webserver{ ip_hash; server 127.0.0.1:3000; } upstream webserver{ least_conn; server 127.0.0.1:3000; } upstream webserver{ url_hash; server 127.0.0.1:3000; } upstream webserver{ fair; server 127.0.0.1:3000; } upstream webserver{ hash $request_uri; server 127.0.0.1:3000; }
三、其他
一）缓存
首先啊，缓存有很多种，比如之前学过的浏览器缓存，还有应用服务器缓存，代理缓存，客户端缓存等等等等。我们可以在nginx中使用prxoy_cache来设置代理缓存。
http{ # 缓存路径 目录层级 缓存空间名称和大小 失效时间为7天 最大容量为10g proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=cache:100m inactive=60m max_size=10g; }
稍微复杂点的方式如下：
if ($request_uri ~ ^/cache/(login|logout)) { set $nocache 1; } location / { proxy_pass http://webserver; } location ~ ^/cache/ { proxy_cache cache; proxy_cache_valid 200 206 304 301 302 60m; # 对哪些状态码缓存，过期时间为60分钟 proxy_cache_key $uri; #缓存的维度 proxy_no_cache $nocache; proxy_set_header Host $host:$server_port; #设置头 proxy_set_header X-Real-IP $remote_addr; #设置头 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #设置头 proxy_pass http://127.0.0.1:6000; }
然后呢，上面的各个字段的含义如下：
| 键值 | 含义 |
|---|---|
| proxy_cache | 使用名为cache的对应缓存配置 |
| proxy_cache_valid 200 206 304 301 302 10d; | 对httpcode为200的缓存10天 |
| proxy_cache_key $uri | 定义缓存唯一key,通过唯一key来进行hash存取 |
| proxy_set_header | 自定义http header头，用于发送给后端真实服务器 |
| proxy_pass | 指代理后转发的路径，注意是否需要最后的/ |
二）location
它的使用其实就是正则表达式，但是语法规则会有些特性，正则我就不在这里多说，咱们直接看下location的语法：
- location仅匹配URI，忽略参数
- 前缀字符串
- 常规
- = 精确匹配
- ^~ 匹配上后则不再进行正则表达式的匹配
- 正则表达式
- ~ 大小写敏感的正则表达式匹配
- ~*忽略大小写的正则表达式匹配
- 内部调转
- 用于内部跳转的命名location @
Syntax location [=|~|~*|^~] uri {...} location @name{...} default - Context server,location
匹配的优先级，按照上面的顺序，从上到下，最上面的优先级最高，我们来看个实际的例子：
location ~ /T1/$ { return 200 '匹配到第一个正则表达式'; } location ~* /T1/(\w+)$ { return 200 '匹配到最长的正则表达式'; } location ^~ /T1/ { return 200 '停止后续的正则表达式匹配'; } location /T1/T2 { return 200 '最长的前缀表达式匹配'; } location /T1 { return 200 '前缀表达式匹配'; } location = /T1 { return 200 '精确匹配'; }
/T1 // 精确匹配 /T1/ // 停止后续的正则表达式匹配 /T1/T2 // 匹配到最长的正则表达式 /T1/T2/ // 最长的前缀表达式匹配 /t1/T2 // 匹配到最长的正则表达式
三）rewrite
可以实现URI的重写和重定向，它的用处有很多，常用于URL页面的跳转，兼容旧版本，SEO优化（伪静态），维护（后台维护、流量转发），安全（伪静态）等，它的语法是这样的：
syntax: rewrite regex replacement [flag] Default: — Context: server, location, if
- 如果正则表达式（regex）匹配到了请求的URI（request URI），这个URI会被后面的replacement替换
- rewrite的定向会根据他们在配置文件中出现的顺序依次执行
- 通过使用flag可以终止定向后进一步的处理
一个例子：
rewrite ^/users/(.*)$ /show?user=$1? last;=
flag，标志位是标识规则对应的类型。
| flag | 含义 |
|---|---|
| last | 先匹配自己的location,然后通过rewrite规则新建一个请求再次请求服务端 |
| break | 先匹配自己的location,然后生命周期会在当前的location结束,不再进行后续的匹配 |
| redirect | 返回302昨时重定向,以后还会请求这个服务器 |
| permanent | 返回301永久重定向,以后会直接请求永久重定向后的域名 |
1）last
- 结束当前的请求处理,用替换后的URI重新匹配
location - 可理解为重写（rewrite）后，发起了一个新请求，进入server模块，匹配location
- 如果重新匹配循环的次数超过10次，nginx会返回500错误
- 返回302 http状态码
- 浏览器地址栏显示重定向后的url
2）break
- 结束当前的请求处理，使用当前资源，不再执行location里余下的语句
- 返回302 http状态码
- 浏览器地址栏显示重定向后的url
3）redirect
- 临时跳转，返回302 http状态码
- 0浏览器地址栏显示重地向后的url
4）permanent
- 永久跳转，返回301 http状态码；
- 浏览器地址栏显示重定向后的url
例子如下：
location ~ ^/break { rewrite ^/break /test break; root /data/html; } location ~ ^/last { rewrite ^/last /test last; } location /test { default_type application/json; return 200 '{"code":0,"msg":"success"}'; } location ~ ^/redirect { rewrite ^/redirect http://www.baidu.com redirect; } location ~ ^/permanent { rewrite ^/permanent http://www.baidu.com permanent; }
可以通过curl来测试一下：
curl http://115.29.148.6/break test curl http://115.29.148.6/last {"code":0,"msg":"success"} curl -vL http://115.29.148.6/redirect curl -vL http://115.29.148.6/permanent