首先客户端请求服务资源, nginx作为直接对外的服务接口,接收到客户端发送过来的http请求,会解包、分析, 如果是静态文件请求就根据nginx配置的静态文件目录,返回请求的资源, 如果是动态的请求,nginx就通过配置文件,将请求传递给uWSGI;uWSGI 将接收到的包进行处理,并转发给wsgi, wsgi根据请求调用django工程的某个文件或函数,处理完后django将返回值交给wsgi, wsgi将返回值进行打包,转发给uWSGI, uWSGI接收后转发给nginx,nginx最终将返回值返回给客户端(如浏览器)。 *注:不同的组件之间传递信息涉及到数据格式和协议的转换
作用:
sudo kill -9 2208 2209
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
ites-available
是存放当前的server配置, 在这里修改。
sites-enabled
是激活并使用的server配置(从sites_available的文件创建快捷方式到sites-enabled)
新建一个网站 test
# 不用sudo没有权限修改
sudo vim /etc/nginx/sites-available/test.conf
#配置负载均衡
# upstream ray {
# server 127.0.0.1:8000; # for a web port socket
#}
server {
listen 80;
server_name www.helloray.cn;#域名或者ip地址
charset utf-8;
# Django 的static和 media等静态资源交给Nginx处理
location /static {
# 路径必须和STATIC_ROOT一样
alias /var/www/myApp/static/;
}
location /media {
#项目下的media路径
alias /var/www/myApp/media/;
}
location /{
# 必须和uwsgi.ini中socket一样,配置了upstream可以将uwsgi_pass配置为:http:// + upstream名称,即“http://ray”.
uwsgi_pass 127.0.0.1:8080;
#uwsgi_pass http://ray;
include uwsgi_params;
}
}
激活网站:建立软链接
sudo ln -s /etc/nginx/sites-available/test.conf /etc/nginx/sites-enabled/test.conf
nginx创建静态文件目录,并更改权限
sudo mkdir -vp /var/www/myApp/static/
sudo chmod 777 /var/www/myApp/static/
在项目下setting.py 文件中
STATIC_URL = 'static'
STATIC_ROOT = '/var/www/myApp/static/'
STATICFILES_DIRS = [
os.path.join(BASE_DIR,'static'),
]
MEDIA_URL = '/media/'
MEDIA_ROOT = os.path.join(BASE_DIR,'media')
在项目目录下迁移静态文件
python manage.py collectstatic
Django中settings.py中的五个设置参数的一些故事:
1、MEDIA_ROOT与MEDIA_URL
事实上MEDIA_ROOT和MEDIA_URL代表的是用户上传后的文件一般保存的地方。我的理解是,可变文件的文件夹。
与这两个参数有联系的,是在Django的FileField和ImageField这样的Model类中,有upload_to参数可选。当upload_to设置相关的地址后,如:upload_to="username";文件上传后将自动保存到 os.path.join(MEDIA_ROOT, upload_to)。
而MEDIA_URL,,则代表用户通过URL来访问这个本地地址的URL。如本机http://127.0.0.1/, MEDIA_URL设置为"/site_media/",那么通过 http://127.0.0.1/site_media/*** 就可以访问相关的上传图片或者其他资源。
2、STATIC_ROOT与STATIC_URL
STATIC_ROOT和STATIC_URL则是网站中,用于网站显示的静态图片、CSS、JS等文件的保存地址。我的理解是,运行中不会再变文件的文件夹(即不会删除或者新增)
2.1 STATIC_URL
同MEDIA_URL类似;STATIC_URL为"/static/"时候,通过http://127.0.0.1/static/***就可以访问相关的静态文件了。
2.2 STATIC_ROOT
STATIC_ROOT是一个比较特殊的文件夹。这是区别Django的开发模式和部署模式下最大的地方了。
通常我们在开发模式下,可以在我们所在的project下建立相应的app, 然后每个app下都建立相应的static文件夹。在开发模式下(Debug=True),Django将为我们自动查找这些静态文件(每个app)并在网页上显示出来。然而,在部署模式下,Django认为这些工作交由web服务器来运行会更有效率。
因此,在部署时,我们需要运行一下python manage.py collectstatic 这个命令。这个命令将会把每个app里的static目录下的文件copy到STATIC_ROOT这个文件夹下,这时候如果在部署模式下(Debug=False),网页中相关的,如: http://127.0.0.1/static/*** 的访问,将不会访问Django下各个App中的static,而是STATIC_ROOT中所指定的文件夹。
3、Debug=False后,为何无法访问图片和js等文件了?
其实这个问题,是在于web服务器没有对STATIC_ROOT以及MEDIA_ROOT这两个文件夹进行映射所导致的。
以apache为例,假定:
STATIC_ROOT="/home/user/static/"
STATIC_URL="/static/"
MEDIA_ROOT="/home/user/media/"
MEDIA_URL="/media/"
那么可以在apache的配置文件中,增加以下:
<Location "/static/">
Order deny,allow
Allow from all
Satisfy Any
</Location>
Alias /static/ "/home/user/static"
<Location "/media/">
Order deny,allow
Allow from all
Satisfy Any
</Location>
Alias /media/ "/home/user/media/"
4、STATICFILES_DIRS:和TEMPLATE_DIRS的含义差不多,就是除了各个app的static目录以外还需要管理的静态文件,添加到这里的文件会在collectstatic时 copy到STATIC_ROOT中
网站的访问量越来越大,服务器的服务模式也得进行相应的升级,比如分离出数据库服务器、分离出图片作为单独服务,这些是简单的数据的负载均衡,将压力分散到不同的机器上。有时候来自web前端的压力,也能让人十分头痛。怎样将同一个域名的访问分散到两台或更多的机器上呢?这其实就是另一种负载均衡了,nginx自身就可以做到,只需要做个简单的配置就行。
nginx不单可以作为强大的web服务器,也可以作为一个反向代理服务器,而且nginx还可以按照调度规则实现动态、静态页面的分离,可以按照轮询、ip哈希、URL哈希、权重等多种方式对后端服务器做负载均衡,同时还支持后端服务器的健康检查。
nginx 的 upstream目前支持 4 种方式的分配
轮询:将请求依次轮询发给每个服务器,如果后端服务器down掉,能自动剔除。
最少链接:将请求发送给持有最少活动链接的服务器。
ip哈希:通过ip的哈希函数结果决定请求发送给哪个服务器。这样每个访客固定访问一个后端服务器,可以解决session的问题。
权重:服务器的权重越高,处理请求的概率越大。用于后端服务器性能不均的情况。
在nginx.conf配置文件中添加如下配置,此配置有三台服务器提供支付服务。
http {
upstream CashServers {
server CashServers1.com;
server CashServers2.com;
server CashServers3.com;
}
server {
listen 80;
location / {
proxy_pass http://CashServers;
}
}
}
http {
upstream CashServers {
least_conn;
server CashServers1.com;
server CashServers2.com;
server CashServers3.com;
}
server {
listen 80;
location / {
proxy_pass http://CashServers;
}
}
}
http {
upstream CashServers {
ip_hash;
server CashServers1.com;
server CashServers2.com;
server CashServers3.com;
}
server {
listen 80;
location / {
proxy_pass http://CashServers;
}
}
}
http {
upstream CashServers {
server CashServers1.com weight=3;
server CashServers2.com weight=2;
server CashServers3.com weight=1;
}
server {
listen 80;
location / {
proxy_pass http://CashServers;
}
}
}
附录:参数说明
>----------------附录:uwsgi参数说明----------------
>
>- http : 协议类型和端口号
>- processes : 开启的进程数量
>- workers : 开启的进程数量,等同于processes(官网的说法是spawn the specified number ofworkers / processes)
>- chdir : 指定运行目录(chdir to specified directory before apps loading)
>- wsgi-file : 载入wsgi-file(load .wsgi file)
>- stats : 在指定的地址上,开启状态服务(enable the stats server on the specified address)
>- threads : 运行线程。由于GIL的存在,我觉得这个真心没啥用。(run each worker in prethreaded mode with the specified number of threads)
>- master : 允许主进程存在(enable master process)
>- daemonize : 使进程在后台运行,并将日志打到指定的日志文件或者udp服务器(daemonize uWSGI)。实际上最常
> 用的,还是把运行记录输出到一个本地文件上。
>- daemonize : 使进程在后台运行,并将日志打到指定的日志文件或者udp服务器(daemonize uWSGI)。实际上最常
> 用的,还是把运行记录输出到一个本地文件上。
>- vacuum : 当服务器退出的时候自动清理环境,删除unix socket文件和pid文件(try to remove all of the generated file/sockets)