Nginx主要功能

負載均衡
反向代理
動靜分離
配置https

負載均衡

負載均衡是一門計算機網絡技術，主要用來優化資源使用、最大化吞吐率、最小化響應時間、同時避免過載的目的。
如果一個網站只有一台服務器的話，如果這台服務器宕機了，那么整個網站將無法正常訪問。當訪問網站人數過多，並發量達到一定規模，超過服務器性能的極限，整個網站也將無法訪問。而負載均衡就是用來解決這一類的問題。
圖片描述

負載均衡是通過后端引入一個負載均衡器和至少一個額外的web服務器來緩解這類問題(增加的web服務器和原本的web服務器提供相同的內容)。用戶訪問的時候，先訪問到負載均衡器，再通過負載均衡器將請求轉發給后台服務器。
圖片描述

通過這種方法，當有一台服務器宕機時，負載均衡器就分配其他的服務器給用戶，極大的增加的網站的穩定性。

負載均衡器主要可以轉發http、https、tcp、udp四種請求規則
負載均衡器如何給用戶分配服務器？負載均衡器有多種負載均衡算法，基本就是給每台服務器一個不同的權重，通過權重來給用戶分配服務器。
負載均衡不需要前端進行配置，主要是服務端進行配置，前端稍作了解即可。

反向代理

反向代理是前端經常會用到的一項功能，主要是為了解決瀏覽器跨域訪問的問題。當協議、域名、端口號有一項或多項不同時，便違反了同源策略，需要跨域。前端跨域用的較多的有：

1.jsonp跨域：使用html的<script>標簽可以引入第三方的js文件，所以我們可以通過

<script src="http://后台接口"></script>

來繞過跨域的限制。但是需要注意的是，jsonp只支持get請求。

2.webpack反向代理：前端開發中，基於webpack配置環境的spa頁面已經是一種趨勢，webpack內置的proxy可以幫助我們在開發環境調試接口時將我們的地址代理到后台服務地址，解決跨域問題。配置如下

    
        proxyTable: {
            '/api': {
                target: 'http://192.168.xxx.xxx:8080', changeOrigin: true } }

這段代碼的含義就是，當前端訪問接口匹配到'/api'時，將代理到'http://192.168.xxx.xxx:8080'服務端地址，如果前台的接口名為/api/restful，代理的請求路徑將是'http://192.168.xxx.xxx:8080/api/restful'。

3.使用nginx進行反向代理
前端開發完成，對代碼進行打包后，webpack就無法使用了。這個時候我們手里只有html、css、js等靜態文件，后台接口地址都會訪問不到。這個時候nginx就登場了，nginx反向代理配置和webpack大同小異，匹配到動態的地址時將請求轉發到一個服務器地址實現跨域。具體流程如下：
1) 訪問nginx官網，下載nginx到本地
2) 將打包完成的代碼放置在nginx的html目錄下
3) 打開conf文件夾下的nginx.conf文件，配置如下：

        
server { listen 3000; //監聽的本地端口 server_name localhost; location /api { //匹配到/api開頭的接口時，轉發到下面的服務器地址 root html; proxy_pass http://192.168.xxx.xxx:8080; //服務器地址 }  location =/ { root html; index index.htm index.html; //默認主頁 }  # 所有靜態請求都由nginx處理，存放目錄為html location ~ \.(htm|html|js|css|jpg|png|gif|eot|svg|ttf|woff|woff2)$ { root html; //配置靜態資源地址 }  error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }

動靜分離

動靜分離是為了減少不必要的請求已減少資源的浪費、請求的延時。

舉個例子，假如我們所有的前台數據都從后台獲取，我們訪問百度首頁時，如果首頁有一張背景圖，那么我們每個人每次進入首頁時都要去請求接口獲取這張背景圖，而首頁的訪問量是巨大的，每次都為了一張背景圖去請求同一個接口對於資源的消耗不可計數，為了減少資源的損耗、加快網頁的加載速度，動靜分離由此而生。

像這種靜態資源，前端都會直接保存在本地文件之中，每次進入首頁的時候從本地文件內讀取靜態圖片資源，動態數據再通過反向代理去服務器端獲取展示。具體配置如下：


 location ~ \.(htm|html|js|css|jpg|png|gif|eot|svg|ttf|woff|woff2)$ { root html; //配置靜態資源地址 }

當匹配到上述后綴名時，直接去html內獲取靜態資源，不向后台發起請求。

配置https服務

微信小程序現在越來越火，大批前端開發進軍微信小程序，但是微信小程序只支持https請求，這是一個問題。但當你看完這篇文章，這將不再是阻擋你的一座大山。

要配置https服務，流程具體如下：
1) 申請證書，便宜ssl可以申請三個月免費ssl證書，申請過程請按照官方提示步驟
2) 申請完成后下載nginx版本的證書至本地，一個crt文件一個key文件，crt為證書，key為密鑰
3) 配置nginx，如下：

 
server { listen 443 ssl; //監聽443端口，因為443端口是https的默認端口。80為http的默認端口 server_name www.domain.com; //配置域名 ssl_certificate 證書的絕對路徑; ssl_certificate_key 密鑰的絕對路徑;  # location / { //反向代理的服務器地址，視情況進行配置  # proxy_pass http://112.35.xxx.xxx;  # } }

總結

最后，我們走一遍整個流程

1.用戶輸入http://域名，默認80端口
2.nginx監聽到80端口被訪問，匹配到域名為www.dream.com，將服務代理到http://192.168.3.10:8080
3.服務器返回頁面資源
4.用戶輸入https://二級域名,默認端口為443
5.nginx監聽443端口,匹配到相應域名，進行證書驗證，將服務代理到指定服務器

在PHP里，最方便的就是deployment了，只要把php文件丟到支持PHP的路徑里面，然后訪問那個路徑就能使用了；無論給主機添加多少PHP應用，只要把目錄改好就沒你的事了，完全不用關心php-cgi運行得如何，deployment極為方便。

◆fcgi：用spawn-fcgi或者框架自帶的工具對各個project分別生成監聽進程，然后和http服務互動。

無論哪種都很麻煩，apache的mod_wsgi配置起來很麻煩，內存占用還大，如果要加上nginx作為靜態頁面的服務器那就更麻煩了；我的應用基本上到后來都是是各個project各自為戰，且不說管理上的混亂，這樣對負載也是不利的，空閑的project和繁忙的project同樣需要占用內存。

如果Python中能有個什么東西像php-cgi一樣監聽同一端口，進行統一管理和負載平衡，那真是能省下大量的部署功夫。偶然看到了uWSGI，才發現居然一直不知道有那么方便地統一部署工具。uWSGI，既不用wsgi協議也不用fcgi協議，而是自創了一個uwsgi的協議，據說該協議大約是fcgi協議的10倍那么快，有個比較見下圖：

uwsgi的文檔雖然很多也很詳細，這里是uwsgi的官方文檔：http://projects.unbit.it/uwsgi/wiki/Doc。

Nginx的整體配置說來話長，這里不再多說，假設已經明白Nginx的基本配置，那么uwsgi就類似這么配置：

這就是把所有url傳給9090端口的uwsgi協議程序來互動。再到project目錄建立myapp.py，使得application調用框架的wsgi接口，比如web.py就是：

然后運行uwsgi監聽9090，其中-w后跟模塊名，也就是剛才配置的myapp

以上是單個project的最簡單化部署，uwsgi還是有很多令人稱贊的功能的，例如：

為了讓多個站點共享一個uwsgi服務，必須把uwsgi運行成虛擬站點：去掉“-w myapp”加上”–vhost”：

然后必須配置virtualenv，virtualenv是Python的一個很有用的虛擬環境工具，這樣安裝：

最后配置nginx，注意每個站點必須單獨占用一個server，同一server不同location定向到不同的應用不知為何總是失敗，估計也算是一個bug。

最初的設置完畢以后，再添加的應用，只需要在Nginx里面進行少量修改，無需重啟uwsgi，就能立刻部署完畢。uwsgi自帶了基於django的監控uwsgi運行狀態的工具，就拿它來部署好了：

於是uwsgi的監控信息可以在http://uwsgiadmin.django.obmem.info看到（用戶名密碼都是admin）。再比如LBForum論壇程序的部署：根據安裝說明安裝完畢，再按部署說明修改完配置文件，然后只需修改nginx配置文件：

雖然寫出來寥寥幾行，配置的時候我可吃盡了uwsgi的苦頭，有些想當然的用法完全不能成立，–no-site參數一加上去其他都好使LBForum怎么都部署不了，一開始多站點公用uwsgi怎么都成功不了等等。

Python世界很有趣，一直會發現有趣的東西，但是Python世界也很折騰人，大部分東西都是dev版本，文檔缺失，各種兼容問題。

nginx

#運行用戶
user nobody;
#啟動進程,通常設置成和cpu的數量相等
worker_processes 1;

#全局錯誤日志及PID文件
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;

#工作模式及連接數上限
events {
#epoll是多路復用IO(I/O Multiplexing)中的一種方式,
#僅用於linux2.6以上內核,可以大大提高nginx的性能
use epoll;

#單個后台worker process進程的最大並發鏈接數
worker_connections 1024;

# 並發總數是 worker_processes 和 worker_connections 的乘積
# 即 max_clients = worker_processes * worker_connections
# 在設置了反向代理的情況下，max_clients = worker_processes * worker_connections / 4 為什么
# 為什么上面反向代理要除以4，應該說是一個經驗值
# 根據以上條件，正常情況下的Nginx Server可以應付的最大連接數為：4 * 8000 = 32000
# worker_connections 值的設置跟物理內存大小有關
# 因為並發受IO約束，max_clients的值須小於系統可以打開的最大文件數
# 而系統可以打開的最大文件數和內存大小成正比，一般1GB內存的機器上可以打開的文件數大約是10萬左右
# 我們來看看360M內存的VPS可以打開的文件句柄數是多少：
# $ cat /proc/sys/fs/file-max
# 輸出 34336
# 32000 < 34336，即並發連接總數小於系統可以打開的文件句柄總數，這樣就在操作系統可以承受的范圍之內
# 所以，worker_connections 的值需根據 worker_processes 進程數目和系統可以打開的最大文件總數進行適當地進行設置
# 使得並發總數小於操作系統可以打開的最大文件數目
# 其實質也就是根據主機的物理CPU和內存進行配置
# 當然，理論上的並發總數可能會和實際有所偏差，因為主機還有其他的工作進程需要消耗系統資源。
# ulimit -SHn 65535

http {
#設定mime類型,類型由mime.type文件定義
include mime.types;
default_type application/octet-stream;
#設定日志格式
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

#sendfile 指令指定 nginx 是否調用 sendfile 函數（zero copy 方式）來輸出文件，
#對於普通應用，必須設為 on,
#如果用來進行下載等應用磁盤IO重負載應用，可設置為 off，
#以平衡磁盤與網絡I/O處理速度，降低系統的uptime.
sendfile on;
#tcp_nopush on;

#設定請求緩沖
client_header_buffer_size 128k;
large_client_header_buffers 4 128k;

#設定虛擬主機配置
server {
#偵聽80端口
listen 80;
#定義使用 www.nginx.cn訪問
server_name www.nginx.cn;

#默認請求
location / {

#定義首頁索引文件的名稱
index index.php index.html index.htm;

# 定義錯誤提示頁面
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}

#靜態文件，nginx自己處理
location ~ ^/(images|javascript|js|css|flash|media|static)/ {

#過期30天，靜態文件不怎么更新，過期可以設大一點，
#如果頻繁更新，則可以設置得小一點。
expires 30d;
}

#PHP 腳本請求全部轉發到 FastCGI處理. 使用FastCGI默認配置.
location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}

Nginx是一款自由的、開源的、高性能的HTTP服務器和反向代理服務器；同時也是一個 IMAP、 POP3、 SMTP代理服務器； Nginx可以作為一個 HTTP服務器進行網站的發布處理，另外 Nginx可以作為反向代理進行負載均衡的實現。

Nginx現在幾乎是眾多大型網站的必用技術，大多數情況下，我們不需要去詳細的配置它，但是了解它在應用程序中所擔當的角色，以及如何解決這些問題是非常有必要的。下面就從基本概念開始介紹:

正向代理與反向代理

代理是在服務器和客戶端之間架設的一層服務器，代理將接收客戶端的請求並將它轉發給服務器，然后將服務器的響應轉發給客戶端。

不管是正向代理還是反向代理，實現的都是上面的功能。

正向代理

位於客戶端和原始服務器(origin server)之間的服務器，為了從原始服務器取得內容，客戶端向代理發送一個請求並制定目標(原始服務器)，然后代理向原始服務器 轉交請求並將獲得的內容返回給客戶端。

正向代理是為客戶端服務的，客戶端可以根據正向代理訪問到它本身無法訪問到的服務器資源。

正向代理對客戶端是透明的，對服務端是非透明的，即服務端並不知道自己接收到的是來自代理的訪問還是來自真實客戶端的訪問。

反向代理

反向代理( Reverse Proxy)方式是值以代理服務器來接收連接請求，然后將請求轉發給內部網絡上的服務器，並將從服務器上得到結構返回給請求連接的客戶端，此時代理服務器對外表現為一個反向代理服務器。

反向代理是為服務端服務的，反向代理可以幫助服務器接收來自客戶端的請求，幫助服務器做請求的轉發、負載均衡等。

反向代理對服務端是透明的，對客戶端是非透明的，即客戶端並不知道自己訪問的是代理服務器，而服務器知道反向代理在為它服務。

基本配置

配置結構

下面是Nginx配置文件的基本結構
Nginx配置結構

events { 

}

http 
{
    server
    { 
        location path
        {
            ...
        }
        location path
        {
            ...
        }
     }

    server
    {
        ...
    }

}

main: Nginx的全局配置，對全局生效。
events: 配置影響Nginx服務器或與用戶的網絡連接。
http: 可以嵌套多個server，配置代理、緩存、日志等絕大多數功能和第三方模塊的配置。
server: 配置虛擬主機的相關參數，一個http中可以有多個server。
location: 配置請求的路由，以及各種頁面的處理情況。
upstream: 配置后端服務器的具體地址，負載均衡不可或缺的部分。

常用內置變量

下面是Nginx一些配置中的內置全局變量，你可以在配置的任意位置使用它們。

變量名	功能
`$host`	請求信息中的`Host`，如果請求中沒有`Host`行，則等於設置的服務器名
`$request_method`	客戶端請求類型，如`GET`、`POST`等
`$remote_addr`	客戶端的`IP`地址
`$remote_port`	客戶端的端口
`$args`	請求中的參數
`$content_length`	請求頭中的`Content-length`字段
`$http_user_agent`	客戶端`User-Agent`信息
`$http_cookie`	客戶端的`cookie`信息
`$server_protocol`	請求使用的協議，如`HTTP/1.0`、`HTTP/1.1`
`$server_addr`	服務器地址
`$server_name`	服務器名稱
`$server_port`	服務器端口號

前端可以用Nginx做些什么

解決跨域

跨域定義

跨域指的是瀏覽器不能執行其他網站的腳本。它是由瀏覽器的同源策略造成的，是瀏覽器對JavaScript施加的安全限制。

同源定義

如果兩個頁面的協議、端口、域名都相同，則這兩個頁面同源。

URL	結構	原因
http://clearlove.com/dir/a.html	成功
http://clearlove.com/dir2/b.html	成功
https://clearlove.com/dir/a.html	失敗	不同協議(http和https)
http://clearlove.com:81/dir/a.html	失敗	不同端口(80和81)
http://meiko.com/dir/a.html	失敗	不同域名(clearlove和meiko)

Nginx解決跨域的原理

例如:

前端server的域名為：fe.server.com
后端服務的域名為：dev.server.com

現在在fe.server.com對dev.server.com發起請求一定會出現跨域。

現在我們只需要啟動一個Nginx服務器，將server_name設置為fe.server.com,然后設置相應的location以攔截前端需要跨域的請求，最后將請求代理回dev.server.com。如下面的配置：

server {
  listen  80;
  server_name  fe.server.com;
  location / {
    proxy_pass dev.server.com;
  }
}

這樣可以完美繞過瀏覽器的同源策略：fe.server.com訪問Nginx的fe.server.com屬於同源訪問，而Nginx對服務端轉發的請求不會觸發瀏覽器的同源策略。

請求過濾

根據狀態碼過濾

error_page 500 501 502 503 504 506 /50x.html; location = /50x.html { #將根路徑改為存放html的路徑。 root /root/static/html; }

根據請求類型過濾

if ( $request_method !~ ^(GET|POST|HEAD)$ ) {
  return 403;
}

其他

可以根據URL、文件請求類型等進行過濾。

配置gzip

gzip是規定的三種標准HTTP壓縮格式之一。目前絕大多數的網站都在使用gzip傳輸 HTML、CSS、JavaScript 等資源文件。

對於文本文件，gzip的效果非常明顯，開啟后傳輸所需流量大約會降至 1/4 ~ 1/3。

並不是每個瀏覽器都支持gzip的，如何知道客戶端是否支持gzip呢，請求頭中的Accept-Encoding來標識對壓縮的支持。
圖片描述

啟用gzip同時需要客戶端和服務端的支持，如果客戶端支持gzip的解析，那么只要服務端能夠返回gzip的文件就可以啟用gzip了,我們可以通過Nginx的配置來讓服務端支持gzip。下面的respone中Content-Encoding: gzip，指服務端開啟了gzip的壓縮方式。
圖片描述

gzip                    on;
gzip_http_version       1.1; gzip_comp_level 5; gzip_min_length 1000; gzip_types text/csv text/xml text/css text/plain text/javascript application/javascript application/x-javascript application/json application/xml;

gzip

開啟或者關閉gzip模塊
默認值為off
可配置為on / off

gzip_http_version

啟用 gZip 所需的HTTP最低版本
默認值為HTTP/1.1

這里為什么默認版本不是1.0呢？

HTTP 運行在TCP連接之上，自然也有着跟TCP一樣的三次握手、慢啟動等特性。

啟用持久連接情況下，服務器發出響應后讓TCP連接繼續打開着。同一對客戶/服務器之間的后續請求和響應可以通過這個連接發送。
圖片描述
為了盡可能的提高 HTTP 性能，使用持久連接就顯得尤為重要了。

HTTP/1.1默認支持TCP持久連接，HTTP/1.0也可以通過顯式指定Connection: keep-alive來啟用持久連接。對於TCP持久連接上的HTTP報文，客戶端需要一種機制來准確判斷結束位置，而在HTTP/1.0中，這種機制只有Content-Length。而在HTTP/1.1中新增的Transfer-Encoding: chunked所對應的分塊傳輸機制可以完美解決這類問題。

Nginx同樣有着配置chunked的屬性chunked_transfer_encoding，這個屬性是默認開啟的。

Nginx在啟用了gZip的情況下，不會等文件gzip完成再返回響應，而是邊壓縮邊響應，這樣可以顯著提高 TTFB(Time To First Byte，首字節時間，WEB性能優化重要指標)。這樣唯一的問題是，Nginx開始返回響應時，它無法知道將要傳輸的文件最終有多大，也就是無法給出Content-Length這個響應頭部。

所以，在HTTP1.0中如果利用Nginx啟用了gzip，是無法獲得Content-Length的，這導致HTTP1.0中開啟持久鏈接和使用gzip只能二選一，所以在這里gzip_http_version默認設置為1.1。

gzip_comp_level

壓縮級別，級別越高壓縮率越大，當然壓縮時間也就越長（傳輸快但比較消耗cpu）。
默認值: 1
壓縮級別取值: 1-9

gzip_min_length

設置允許壓縮的頁面最小字節數，Content-Length小於該值的請求將不會被壓縮。
默認值: 0
當設置的值較小時，壓縮后的長度可能比原文件大，建議設置1000以上

gzip_types

要采用gzip壓縮的文件類型(MIME類型)
默認值: text/html(默認不壓縮js/css)

負載均衡

Nginx如何實現負載均衡

upstream指定后端服務器地址列表

upstream balanceServer {
  server 10.1.22.33:12345; server 10.1.22.34:12345; server 10.1.22.35:12345; }

在server中攔截響應請求，並將請求轉發到upstream中配置的服務器列表。

server {
  server_name  fe.server.com;
  listen 80;
  location /api {
    proxy_pass http://balanceServer;
  }
}

上面的配置只是指定了Nginx需要轉發的服務端列表，並沒有指定分配策略。

Nginx實現負載均衡的策略

輪詢策略

默認情況下采用的策略，將所有客戶端請求輪詢分配給服務端。這種策略是可以正常工作的，但是如果其中某一台服務器壓力太大，出現延遲，會影響所有分配在這台服務器下的用戶。

upstream balanceServer {
  server 10.1.22.33:12345; server 10.1.22.34:12345; server 10.1.22.35:12345; }

最小連接數策略

將請求優先分配給壓力較小的服務器，它可以平衡每個隊列的長度，並避免向壓力大的服務器添加更多的請求。

upstream balanceServer {
  least_conn;
  server 10.1.22.33:12345; server 10.1.22.34:12345; server 10.1.22.35:12345; }

最快響應時間策略

依賴於Nginx Plus，優先分配給響應時間最短的服務器。

upstream balanceServer {
  fair;
  server 10.1.22.33:12345; server 10.1.22.34:12345; server 10.1.22.35:12345; }

客戶端IP綁定

來自同一個IP的請求永遠只分配一台服務器，有效解決了動態網頁存在的session共享問題。

upstream balanceServer {
  ip_hash;
  server 10.1.22.33:12345; server 10.1.22.34:12345; server 10.1.22.35:12345; }

負載均衡服務器配置參數

Nginx實現負載均衡的策略中，每一台服務器后面都可以攜帶的參數有:

down: 當前服務器不參與負載均衡。
weight: 權重，值越大，服務器的負載量就越大。
max_fails: 允許請求失敗的次數，默認為1。
fail_timeout: max_fails次失敗后暫停的時間。
backup: 備份機，只有其它所有的非backup機器down或者忙時才會請求backup機器。

如下面的配置是指：負載中有三台服務器，當請求到達時，nginx按時間順序和權重把請求分配給三台服務器處理，例如有100個請求，有30%是服務器33處理，有50%的請求是服務器34處理，有20%的請求是服務器35處理。

upstream balanceServer {
  server 10.1.22.33:12345 weight=30; server 10.1.22.34:12345 weight=50; server 10.1.22.35:12345 weight=20; }

如下面的配置是指：負載中有三台服務器，服務器33的失敗超時時間為60s，服務器34暫不參與負載，服務器35只用作備份機。

upstream balanceServer {
  server 10.1.22.33:12345 fail_timeout=60s; server 10.1.22.34:12345 down; server 10.1.22.35:12345 backup; }

靜態資源服務器

location ~* \.(png|gif|jpg|jpeg)$ {
  root    /root/static/;  
  autoindex on;
  access_log  off;
  expires     10h;# 設置過期時間為10小時          
}

匹配以png|gif|jpg|jpeg為結尾的請求，並將請求轉發到本地路徑，root中指定的路徑即Nginx本地路徑。同時也可以進行一些緩存的設置。

訪問限制

經常會遇到希望網站讓某些特定用戶的群體（比如只讓公司內網）訪問，或者控制某個url不讓人訪問。配置如下：

location / {
  deny  192.168.1.100;
  allow 192.168.1.10/200;
  allow 10.110.50.16;
  deny  all;
}

其實deny和allow是ngx_http_access_module模塊（已內置）中的語法。采用的是從上到下匹配方式，匹配到就跳出不再繼續匹配。

上述配置的意思就是，首先禁止192.168.1.100訪問，然后允許192.168.1.10-200 ip段內的訪問（排除192.168.1.100），同時允許10.110.50.16這個單獨ip的訪問，剩下未匹配到的全部禁止訪問。實際生產中，經常和ngx_http_geo_module模塊（可以更好地管理ip地址表，已內置）配合使用。

適配PC與移動環境

現在很多網站都存在PC站和H5站兩個站點，因此根據用戶的瀏覽環境自動切換站點是很常見的需求。

Nginx可以通過內置變量$http_user_agent，獲取到請求客戶端的userAgent，從而知道用戶處於移動端還是PC，進而控制重定向到H5站還是PC站。比如，PC端站點是mysite.com，H5端是mysite-H5.com。配置如下：

location / {
  # 移動、pc設備適配
  if ($http_user_agent ~* '(Android|webOS|iPhone|iPod|BlackBerry)') {
    set $mobile_request '1';
  }
  if ($mobile_request = '1') { rewrite ^.+ http://mysite-H5.com; } }

總結

上述只是通過一些簡單的應用，希望能夠引起廣大前端童靴對Niginx的興趣。事實上，Nginx不僅僅局限於這些微小的工作，在實際生產中作用其實更加巨大。對於有志於“大前端”的童靴，了解和熟悉Nginx絕對是必修技能之一。

前后端分離這個問題其實松哥和大家聊過很多了，上周松哥把自己的兩個開源項目部署在服務器上以幫助大家可以快速在線預覽（喜大普奔，兩個開源的 Spring Boot + Vue 前后端分離項目可以在線體驗了），然后群里就有小伙伴想讓松哥來聊聊如何結合 Nginx 來部署前后端分離項目？今天我們就來聊一聊這個話題。

不得不說的跨域

很多人對前后端分離部署感到困惑，其實主要是困惑跨域問題怎么解決。因為前后端分離項目在開發的時候，前端通過 nodejs 來運行，需要一個單獨的端口，后端通過 Tomcat 或者 Jetty 來運行，也需要端口，兩個不同的端口，就造成了跨域。

但是松哥之前多次和大家聊過這個問題，這種跨域並不是我們傳統開發中真正的跨域，這個所謂的跨域只在開發環境中存在，生產環境下就不存在這個跨域問題了。所以我們不能按照以往的通過 JSONP 或者 CORS 之類的手段來解決這個跨域問題。

前后端分離開發中，前端為了能夠模擬出測試數據，並且模擬出請求，一般需要借助於 nodejs 來運行，這是開發時候的狀態，開發時候的配置大家可以參考這篇文章：

前后端分離歷險記

等開發完成后，我們會對前端項目編譯打包，編譯打包完成之后，就只剩下一堆 js、css 以及 html 文件了，我們把這些編譯打包后的文件拷貝到后端項目中，這樣再去運行就不存在跨域問題了（例如將編譯打包后的靜態文件拷貝到 Spring Boot 項目的 src/main/resources/static 目錄下）。這種方式我就不再多說了，相信大家都會，今天咱們主要來看看如何結合 Nginx 來部署。

Nginx 大殺器

結合 Nginx 來部署前后端分離項目算是目前的主流方案。一來部署方便，二來通過動靜分離也可以有效提高項目的運行效率。

大家知道我們項目中的資源包含動態資源和靜態資源兩種，其中：

動態資源就是那些需要經過容器處理的資源，例如 jsp、freemarker、各種接口等。
靜態資源則是那些不需要經過容器處理，收到客戶端請求就可以直接返回的資源，像 js、css、html 以及各種格式的圖片，都屬於靜態資源。

將動靜資源分開部署，可以有效提高靜態資源的加載速度以及整個系統的運行效率。

在前后端分離項目部署中，我們用 Nginx 來做一個反向代理服務器，它既可以代理動態請求，也可以直接提供靜態資源訪問。我們來一起看下。建議大家先閱讀松哥以前關於 Nginx 的一篇舊文，可以有效幫助大家理解后面的配置：

Nginx 極簡入門教程！

后端部署

后端接口的部署，主要看項目的形式，如果就是普通的 SSM 項目，那就提前准備好 Tomcat ，在 Tomcat 中部署項目，如果是 Spring Boot 項目，可以通過命令直接啟動 jar，如果是微服務項目，存在多個 jar 的話，可以結合 Docker 來部署（參考一鍵部署 Spring Boot 到遠程 Docker 容器），無論是那種形式，對於我們 Java 工程師來說，這都不是問題，我相信這一步大家都能搞定。

后端項目可以在一個非 80 端口上部署，部署成功之后，因為這個后端項目只是提供接口，所以我們並不會直接去訪問他。而是通過 Nginx 請求轉發來訪問這個后端接口。

松哥這里以我去年為一個律所的小程序為例，后端是一個 Spring Boot 工程，那么我可以通過 Docker 部署，也可以直接通過命令來啟動，這里簡單點，直接通過命令來啟動 jar ，如下：

nohup java -jar jinlu.jar > vhr.log &

后端啟動成功之后，我並不急着直接去訪問后端，而是安裝並且去配置一個 Nginx，通過 Nginx 來轉發請求，Nginx 的基本介紹與安裝，大家可以參考（Nginx 極簡入門教程！），我這里就直接來說相關的配置了。

這里我們在 nginx.conf 中做出如下配置：

首先配置上游服務器：

upstream zqq.com{ server 127.0.0.1:9999 weight=2; }

在這里主要是配置服務端的地址，如果服務端是集群化部署，那么這里就會有多個服務端地址，然后可以通過權重或者 ip hash 等方式進行請求分發。

然后我們在 server 中配置轉發規則：

location /jinlu/ { proxy_pass http://zqq.com; tcp_nodelay on; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }

這樣配置完成后，假設我目前的域名是 javaboy.org，那么用戶通過 http://www.javaboy.org/jinlu/** 格式的地址就可以訪問到我服務端的接口。

前端部署

以 Vue 為例，如果是 SPA 應用，項目打包之后，就是一個 index.html 還有幾個 js、css、images 以及 fonts ，這些都是靜態文件，我們將靜態文件首先上傳到服務器，然后在 nginx.conf 中配置靜態資源訪問，具體配置如下：

location ~ .*\.(js|css|ico|png|jpg|eot|svg|ttf|woff|html|txt|pdf|) { root /usr/local/nginx/html/;#所有靜態文件直接讀取硬盤 expires 30d; #緩存30天 }

當然我這里是按照資源類型來攔截的，即后綴為 js、css、ico 等的文件，統統都不進行請求分發，直接從本地的 /usr/local/nginx/html/ 目錄下讀取並返回到前端（我們需要將靜態資源文件上傳到 /usr/local/nginx/html/ 目錄下）。

如果我們的服務器上部署了多個項目，這種寫法就不太合適，因為多個項目的前端靜態文件肯定要分門別類，各自放好的，這個時候我們一樣可以通過路徑來攔截，配置如下：

location /jinlu-admin/ { root /usr/local/nginx/html/jinlu-admin/;#所有靜態文件直接讀取硬盤 expires 30d; #緩存30天 }

這樣，請求路徑是 /jinlu-admin/ 格式的請求，則不會進行請求分發，而是直接從本機的 /usr/local/nginx/html/jinlu-admin/ 目錄下返回相關資源。采用這方方式配置靜態資源，我們就可以部署多個項目了，多個項目的部署方式和上面的一樣。

這樣部署完成之后，假設我的域名是 javaboy.org ，那么用戶通過 http://www.javaboy.org/jinlu-admin/**
格式的請求就可以訪問到前端資源了。

此時大家發現，前端的靜態資源和后端的接口現在處於同一個域之中了，這樣就不存在跨域問題，所以我一開始基說不必用 JSONP 或者 CORS 去解決跨域。特殊情況可能需要在 nginx 中配置跨域，這個松哥以后再和大家細聊~

好了，不知道小伙伴有沒有看懂呢？有問題歡迎留言討論。

路徑	類型	作用
/etc/logrotate.d/nginx	配置文件	Nginx日志輪轉，用於logrotate服務的日志切割
/etc/nginx /etc/nginx/nginx.conf /etc/nginx/conf.d /etc/nginx/conf.d/default.conf	目錄、配置文件	Nginx主配置文件
/etc/nginx/fastcgi_params /etc/nginx/uwsgi_params /etc/nginx/scgi_params	配置文件	cgi配置相關，fastcgi配置
/etc/nginx/koi-utf /etc/nginx/koi-win /etc/nginx/win-utf	配置文件	編碼轉換映射文件
/etc/nginx/mime.types	配置文件	設置http協議的Content-Type與擴展名對應關系
/usr/lib/systemd/system/nginx-debug.service /usr/lib/systemd/system/nginx.service /etc/sysconfig/nginx /etc/sysconfig/nginx-debug	配置文件	(centos7)配置出系統守護進程管理器的管理方式
/usr/lib64/nginx/modules /etc/nginx/modules	目錄	nginx模塊目錄
/usr/sbin/nginx /usr/sbin/nginx-debug	命令	nginx服務的啟動終端管理命令
/var/cache/nginx	目錄	Nginx的緩存目錄
/var/log/nginx	目錄	nginx的日志目錄

nginx配置文件詳解-最全-生產

定義Nginx運行的用戶和用戶組

nginx進程數，建議設置為等於CPU總核心數。

全局錯誤日志定義類型，[ debug | info | notice | warn | error | crit ]

進程文件

一個nginx進程打開的最多文件描述符數目，理論值應該是最多打開文件數（系統的值ulimit -n）與nginx進程數相除，但是nginx分配請求並不均勻，所以建議與ulimit -n的值保持一致。

工作模式與連接數上限

參考事件模型，use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型是Linux 2.6以上版本內核中的高性能網絡I/O模型，如果跑在FreeBSD上面，就用kqueue模型。

單個進程最大連接數（最大連接數=連接數*進程數）

設定http服務器

charset utf-8; #默認編碼

FastCGI相關參數是為了改善網站的性能：減少資源占用，提高訪問速度。下面參數看字面意思都能理解。

gzip模塊設置

壓縮類型，默認就已經包含text/html，所以下面就不用再寫了，寫上去也不會有問題，但是會有一個warn。

limit_zone crawler $binary_remote_addr 10m; #開啟限制IP連接數的時候需要使用

upstream的負載均衡，weight是權重，可以根據機器配置定義權重。weigth參數表示權值，權值越高被分配到的幾率越大。

虛擬主機的配置

監聽端口

域名可以有多個，用空格隔開

圖片緩存時間設置

JS和CSS緩存時間設置

日志格式設定

定義本虛擬主機的訪問日志

對 “/” 啟用反向代理

后端的Web服務器可以通過X-Forwarded-For獲取用戶真實IP

以下是一些反向代理的配置，可選。

設定緩存文件夾大小，大於這個值，將從upstream服務器傳

設定查看Nginx狀態的地址

htpasswd文件的內容可以用apache提供的htpasswd工具來產生。

本地動靜分離反向代理配置

所有jsp的頁面均交由tomcat或resin處理

所有靜態文件由nginx直接讀取不經過tomcat或resin

linux下通過pip安裝最新uwsgi

先期情況和問題

解決方案

實施步驟

Nginx主要功能

負載均衡

反向代理

動靜分離

配置https服務

總結

-----------------------------------------------------------------------

Nginx與前端開發

Nginx與Node.js

反向代理

前端可以用Nginx做些什么

總結

nginx

正向代理與反向代理

正向代理

反向代理

基本配置

配置結構

常用內置變量

前端可以用Nginx做些什么

解決跨域

跨域定義

同源定義

Nginx解決跨域的原理

請求過濾

根據狀態碼過濾

根據請求類型過濾

其他

配置gzip

gzip

gzip_http_version

gzip_comp_level

gzip_min_length

gzip_types

負載均衡

Nginx如何實現負載均衡

Nginx實現負載均衡的策略

輪詢策略

最小連接數策略

最快響應時間策略

客戶端IP綁定

負載均衡服務器配置參數

靜態資源服務器

訪問限制