Nginx负载均衡

1.普通的Http代理：
  注意：在upstream中不要使用http://backend1.example.com，而在proxy_pass中则要加上http://backend
  upstream backend  {
    server backend1.example.com weight=5;
    server backend2.example.com:8080;
    server unix:/tmp/backend3;
   }

   server {
       location / {
             proxy_pass  http://backend;
       }
   }

2.FastCGI代理：
  注意：由于fastcgi_pass不是普通的http代理，所以在fastcgi_pass中直接对应upstream的name即可       
   upstream webpys {
        server  unix:/opt/test/log/webpy.6001.sock;
        server  unix:/opt/test/log/webpy.6002.sock;
    }
    server {
       location / {
             fastcgi_pass    webpys;       
       }

   }

8.2 使用Nginx作为反向代理¶

一个代理服务器是一台中转客户端资源请求到适当的服务器的机器。一些网络安装使用代理服务器过滤或缓存本地网络机器到Internet的HTTP请求。因为我们将运行一些在不同TCP端口上的Tornado实例，因此我们将使用反向代理服务器：客户端通过Internet连接一个反向代理服务器，然后反向代理服务器发送请求到代理后端的Tornado服务器池中的任何一个主机。代理服务器被设置为对客户端透明的，但它会向上游的Tornado节点传递一些有用信息，比如原始客户端IP地址和TCP格式。

我们的服务器配置如图8-1所示。反向代理接收所有传入的HTTP请求，然后把它们分配给独立的Tornado实例。

图8-1 反向代理服务器后端的Tornado实例

8.2.1 Nginx基本配置¶

代码清单8-1中的列表是一个Nginx配置的示例。Nginx启动后监听来自80端口的连接，然后分配这些请求到配置文件中列出的上游主机。在这种情况下，我们假定上游主机监听来自他们自己的环回接口上的端口的连接。

代码清单8-1 一个简单的Nginx代理配置

user nginx;worker_processes 5;error_log /var/log/nginx/error.log;pid /var/run/nginx.pid;events {    worker_connections 1024;    use epoll;}proxy_next_upstream error;upstream tornadoes {    server 127.0.0.1:8000;    server 127.0.0.1:8001;    server 127.0.0.1:8002;    server 127.0.0.1:8003;}server {    listen 80;    server_name www.example.org *.example.org;    location /static/ {        root /var/www/static;        if ($query_string) {            expires max;        }    }    location / {        proxy_pass_header Server;        proxy_set_header Host $http_host;        proxy_redirect off;        proxy_set_header X-Real-IP $remote_addr;        proxy_set_header X-Scheme $scheme;        proxy_pass http://tornadoes;    }}

这个配置示例假定你的系统使用了epoll。在不同的UNIX发行版本中经常会有轻微的不同。一些系统可能使用了poll、/dev/poll或kqueue代替。

按顺序来看匹配location /static/或location /的请求可能会很有帮助。Nginx把位于location指令中的字符串看作是一个以行起始锚点开始、任何字母重复结束的正则表达式。所以/被看作是表达式^/.*。当Nginx匹配这些字符串时，像/static这样更加特殊的字符串在像/这样的更加的通用的字符串之前被检查。Nginx文档中详细解释了匹配的顺序。

除了一些标准样板外，这个配置文件最重要的部分是upstream指令和服务器配置中的proxy指令。Nginx服务器在80端口监听连接，然后分配这种请求给upstream服务器组中列出的Tornado实例。proxy_pass指令指定接收转发请求的服务器URI。你可以在proxy_pass URI中的主机部分引用upstream服务器组的名字。

Nginx默认以循环的方式分配请求。此外，你也可以选择基于客户端的IP地址分配请求，这种情况下（除非连接中断）可以确保来自同一IP地址的请求总是被分配到同一个上游节点。你可以在HTTPUpstreamModule文档中了解更多关于这个选项的知识。

还需要注意的是location /static/指令，它告诉Nginx直接提供静态目录的文件，而不再代理请求到Tornado。Nginx可以比Tornado更高效地提供静态文件，所以减少Tornado进程中不必要的加载是非常有意义的。

8.2.2 Nginx的SSL解密¶

应用的开发者在浏览器和客户端之间传输个人信息时需要特别注意保护信息不要落入坏人之手。在不安全的WiFi接入中，用户很容易受到cookie劫持攻击，从而威胁他们在流行的社交网站上的账户。对此，大部分主要的社交网络应用都默认或作为用户可配置选项使用安全协议。同时，我们使用Nginx解密传入的SSL加密请求，然后把解码后的HTTP请求分配给上游服务器。

代码清单8-2展示了一个用于解密传入的HTTPS请求的server块，并使用代码清单8-1中我们使用过的代理指令转发解密后的通信。

代码清单8-2 使用SSL的server块

server {    listen 443;    ssl on;    ssl_certificate /path/to/cert.pem;    ssl_certificate_key /path/to/cert.key;    default_type application/octet-stream;    location /static/ {        root /var/www/static;        if ($query_string) {            expires max;        }    }    location = /favicon.ico {        rewrite (.*) /static/favicon.ico;    }    location / {        proxy_pass_header Server;        proxy_set_header Host $http_host;        proxy_redirect off;        proxy_set_header X-Real-IP $remote_addr;        proxy_set_header X-Scheme $scheme;        proxy_pass http://tornadoes;    }}

这段代码和上面的配置非常相似，除了Nginx将在标准HTTPS的443端口监听安全Web请求外。如果你想强制使用SSL连接，你可以在server块中包含一个rewrite指令来监听80端口的HTTP连接。代码清单8-3是这种重定向的一个例子。

代码清单8-3 用于重定向HTTP请求到安全渠道的server块

server {    listen 80;    server_name example.com;    rewrite /(.*) https://$http_host/$1 redirect;}

Nginx是一个非常鲁棒的工具，我们在这里仅仅接触到帮助Tornado部署的一些简单的配置选项。Nginx的wiki文档是获得安装和配置这个强有力的工具额外信息的一个非常好的资源。