Nginx是用來幹什麼的？

1、靜態HTTP服務器

首先，Nginx是一個HTTP服務器，能夠將服務器上的靜態文件（如HTML、圖片）經過HTTP協議展示給客戶端。

配置：

1. server {
2. listen80; # 端口號
3. location / {
4. root /usr/share/nginx/html; # 靜態文件路徑
5. }
6. }

2、反向代理服務器

什麼是反向代理？

客戶端原本能夠直接經過HTTP協議訪問某網站應用服務器，網站管理員能夠在中間加上一個Nginx，客戶端請求Nginx，Nginx請求應用服務器，而後將結果返回給客戶端，此時Nginx就是反向代理服務器。

配置：

1. server {
2. listen80;
3. location / {
4. proxy_pass http://192.168.20.1:8080; # 應用服務器HTTP地址
5. }
6. }

既然服務器能夠直接HTTP訪問，爲何要在中間加上一個反向代理，不是畫蛇添足嗎？反向代理有什麼做用？繼續往下看，下面的負載均衡、虛擬主機等，都基於反向代理實現，固然反向代理的功能也不只僅是這些。

3、負載均衡

當網站訪問量很是大，網站站長開心賺錢的同時，也攤上事兒了。由於網站愈來愈慢，一臺服務器已經不夠用了。因而將同一個應用部署在多臺服務器上，將大量用戶的請求分配給多臺機器處理。同時帶來的好處是，其中一臺服務器萬一掛了，只要還有其餘服務器正常運行，就不會影響用戶使用。

Nginx能夠經過反向代理來實現負載均衡。

配置 

1. upstream myapp {
2. server192.168.20.1:8080; # 應用服務器1
3. server192.168.20.2:8080; # 應用服務器2
4. }
5. server {
6. listen80;
7. location / {
8. proxy_pass http://myapp;
9. }
10. }

以上配置會將請求輪詢分配到應用服務器，也就是一個客戶端的屢次請求，有可能會由多臺不一樣的服務器處理。能夠經過ip-hash的方式，根據客戶端ip地址的hash值將請求分配給固定的某一個服務器處理。

配置：

1. upstream myapp {
2. ip_hash; # 根據客戶端IP地址Hash值將請求分配給固定的一個服務器處理
3. server192.168.20.1:8080;
4. server192.168.20.2:8080;
5. }
6. server {
7. listen80;
8. location / {
9. proxy_pass http://myapp;
10. }
11. }

另外，服務器的硬件配置可能有好有差，想把大部分請求分配給好的服務器，把少許請求分配給差的服務器，能夠經過weight來控制。 

配置：

1. upstream myapp {
2. server192.168.20.1:8080weight=3; # 該服務器處理3/4請求
3. server192.168.20.2:8080; # weight默認爲1，該服務器處理1/4請求
4. }
5. server {
6. listen80;
7. location / {
8. proxy_pass http://myapp;
9. }
10. }

4、虛擬主機

有的網站訪問量大，須要負載均衡。然而並非全部網站都如此出色，有的網站，因爲訪問量過小，須要節省成本，將多個網站部署在同一臺服務器上。

例如將www.aaa.com和www.bbb.com兩個網站部署在同一臺服務器上，兩個域名解析到同一個IP地址，可是用戶經過兩個域名卻能夠打開兩個徹底不一樣的網站，互相不影響，就像訪問兩個服務器同樣，因此叫兩個虛擬主機。

配置：

1. server {
2. listen80default_server;
3. server_name _;
4. return444; # 過濾其餘域名的請求，返回444狀態碼
5. }
6. server {
7. listen80;
8. server_name www.aaa.com; # www.aaa.com域名
9. location / {
10. proxy_pass http://localhost:8080; # 對應端口號8080
11. }
12. }
13. server {
14. listen80;
15. server_name www.bbb.com; # www.bbb.com域名
16. location / {
17. proxy_pass http://localhost:8081; # 對應端口號8081
18. }
19. }

 

在服務器8080和8081分別開了一個應用，客戶端經過不一樣的域名訪問，根據server_name能夠反向代理到對應的應用服務器。

虛擬主機的原理是經過HTTP請求頭中的Host是否匹配server_name來實現的，有興趣的同窗能夠研究一下HTTP協議。

另外，server_name配置還能夠過濾有人惡意將某些域名指向你的主機服務器。

 

當咱們在用django開發的web項目時，開發測試過程當中用到的是django自帶的測試服務器，因爲其安全及穩定等性能方面的侷限性，django官方並不建議將測試服務器用在實際生產。

 

　　nginx+uwsgi+django是咱們經常使用的django部署方式。nginx做爲最前端的服務器，他負責接收全部的客戶端請求，對於請求的靜態文件，由nginx服務器本身完成，由於它具備很好處理靜態文件的能力，性能進行過優化，支持高併發量；uWSGI服務器做爲支持服務器，是用來服務nginx的，nginx將請求的動態文件交給uWSGI進行處理。uWSGI實現了uwsgi、wsgi和http協議，uwsgi協議是uWSGI自定義的協議，定義的是框架（django）和服務器對接的接口。

 

說說他們的關係，Nginx和uWSGI都是Web服務器，Nginx負責靜態內容，uWSGI負責Python這樣的動態內容，兩者配合共同提供Web服務以實現提升效率和負載均衡等目的。uWSGI實現了多個協議，如WSGI，HTTP協議，還有它本身的uwsgi協議，這樣和fastcgi相似，請求和響應的流程以下：

 

Request > Nginx > uWSGI > Django > uWSGI > Nginx > Response

 

請求先交由Nginx，若是是靜態內容就本身處理了，若是是動態內容就交給uWSGI服務器，uWSGI服務器處理整個Django項目的Python代碼，響應請求，原路返回，可是與fastcgi不一樣，Nginx、uWSGI和Django能夠獨立部署，而後整合。