1、web服务 – 最初开发NGINX是为了解决 C10K 问题 – 可以轻松支撑10,000或更多的并发连接。使用NGINX为你的Python应用提供web服务,可以让你的网站运行更快,即便在小流量的情况下也有效果。当你的用户成千上万时,确定无疑,它可以提供更高的性能,更少的崩溃,以及更少的当机时间。你也可以使用NGINX提供静态文件缓存或者微缓存服务,一个独立的NGINX反向代理也是很好的选择(见下一段)。
2、反向代理– 你可以在应用服务的前端用NGINX做反向代理。NGINX接收Web请求并分发到你的应用服务。这个“怪招”可以让你的网站运行得更快,减少当机,消费更少的服务资源,而且可以提高安全性。你也可以在反向代理服务器上缓存静态资源(非常高效),添加静态内容的微缓存,以减少应用自身的负载,等等。
3、为多个应用服务提供动态均衡 – 通过布署反向代理服务。通过多应用服务并行运行和NGINX或者NGINX插件来做流量负载均衡。通过这种布署,根据流量需要,增长稳定性和运行时间需要,你可以很轻松地在线扩展网站性能。如果你需要让给定用户的会话在同一个服务上,你只需要配置负载均衡以支持会话持久化。
选择单服务或者微服务布署
小网站在单个服务器上就可以运行得很好。大的网站需要多个服务器。但如果你处于中间地带–或者你的网站从一个小网站变成一个大网站– 你可以做一些有趣的选择。
如果你使用单机布署,大流量和浏览激增会给你带来很大的风险。你的扩展手段非常有限,无外乎优化你的应用,把web服务切换到NGINX,使用一个更大更快的服务器,或者使用内容分发网络(CDN)。所有这些可选项的实施都耗时耗钱,而且在实施过程中还有引入bug的风险。
另外一个很显然的风险是单机布署存在单点故障问题 – 很多问题可以导致你的站点挂掉,而且没有快速简单的解决方案。
使用NGINX做为应用的代理服务
如果你把服务切换成NGINX并且使用单机布署,你可以自由地选择使用开源的NGINX或者NGINX插件。NGINX包括企业级支持和一些扩展功能。像实时活动监测这样的扩展功能是支持单机布署的。如果做为反向代理,采用分布式布署,你可以使用其他NGINX插件,如负载均衡和会话持久化。
有很多事情都要考虑周详,除非你确定你的网站在未来很长时间内都是一个小网站,不需要关心当机问题,否则,你要明白,单机布署存在很多风险。分布式布署比较易于扩展 – 单点故障可以通过工程解决,性能可以按需调整,可以快速扩充服务器能力。
使用NGINX替换你的Web服务
在Web时代的早期,Apache就是web服务的同义词。但NGINX自2000年出现以来,迅速流行开来;现在已经是排名第一的web服务,被1,000, 10,000多个网站和世界上最繁忙的100,000多个网站使用。
NGINX最初是为了解决C10K问题而开发 – 在给定内存预算下支持10,000+并发。其他web服务需要为每个连接分配内存块,所以他们会耗尽物理内存,当数以千记的用户在同一时间访问一个网站,它会变慢甚至崩溃。NGINX处理器可以单独处理一个请求,也可以优雅地扩展,同时处理多个用户。(这可以很好地解决额外问题,后面会详述。)
一个高层NGINX架构图如下所示。
NGINX 架构, 选自开源应用架构第二卷
在上图,一个Python应用服务被布署在后端的应用服务块中,如图所示,它通过FastCGI被访问。NGINX不“知道”怎么运行Python,所以它需要一个网关连结需要的环境。FastCGI是一个被PHP,Pyhton和其他语言广泛使用的接口。
但是,连结Python和NGINX的流行方案是网络服务网关接口(WSGI)。WSGI工作在多线程和多进程环境下,所以他兼容本文所提到的所有布署选项。
如果你将web服务迁移到NGINX,这里有一些有用的软件:
Configuring gunicorn – “Green Unicorn”是一个流行的WSGI服务,配合NGINX使用。
Configuring uWSGI – 另一个流行的WSGI服务,配合NGINX使用. uWSGI包含NGINX指令支持。
Using uWSGI, NGINX, and Django – 一个流行的Python web框架。
下面的代码片断将向你展示如何配置NGINX和uWSGI – 这个案例中的工程使用Python框架Django。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
http {
...
upstream django {
server
127.0
.
0.1
:
29000
;
}
server {
listen
80
;
server_name myapp.example.com;
root /var/www/myapp/html;
location / {
index index.html;
}
location /
static
/ {
alias /var/django/projects/myapp/
static
/;
}
location /main {
include /etc/nginx/uwsgi_params;
uwsgi_pass django;
uwsgi_param Host $host;
uwsgi_param X-Real-IP $remote_addr;
uwsgi_param X-Forwarded-For $proxy_add_x_forwarded_for;
uwsgi_param X-Forwarded-Proto $http_x_forwarded_proto;
}
}
}
|
实现静态文件缓存
缓存静态内容包括:为不经常变更的文件保存副本 – 不经常是指数小时或者永远 – 副本保存在其他位置而不是应用服务中。典型的静态内容是网页中经常用到的JPEG图片。
缓存静态文件是提升应用性能的常用手段,经常被用到:
1、用户浏览器
2、互联网提供商 – 从公司网络到互联网提供商(ISP)
3、web服务, 也就是本文所讲的
在web服务端实现静态文件缓存有两个好处:
1、为用户提供快速服务 – NGINX 专门为静态文件缓存做过优化,对静态内容请求的处理比应用服务要快。
2、减少应用服务负载– 应用服务不需要处理已经缓存的静态文件,已经由web服务接管。
缓存静态文件在单服务器上也可以很好的实现,但底层硬件资源仍然是由web服务和应用服务所共享。如果web服务要处理频率的静态文件访问 – 甚至是海量 – 应用服务可以使用的硬件资源就会变少,一些功能可能就会变慢。
如果要支持浏览器缓存,需要正确设置静态文件的头部信息。如HTTPCache Control(特别是它的max age设置),Expires,和Entity标记。如果想深入了解,参见NGINX Plus的管理员指南:使用NGINX为uWSGI和Django提供应用网关
下面的NGINX配置代码用来缓存静态文件,包括JPEG文件,GIF文件,PNG文件,MP4文件,Powerpoint文件,和一些其他文件,请把www.example.com替换成你自己的网址。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
server {
# substitute your web server's URL
for
"www.example.com"
server_name www.example.com;
root /var/www/example.com/htdocs;
index index.php;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
try_files $uri =
404
;
include fastcgi_params;
# substitute the socket, or address and port, of your Python server
fastcgi_pass unix:/var/run/php5-fpm.sock;
#fastcgi_pass
127.0
.
0.1
:
9000
;
}
location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg
|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid
|midi|wav|bmp|rtf)$ {
expires max;
log_not_found off;
access_log off;
}
}
|