大家好似扔，我是前端dog君吨些，一名95后前端小兵。2019年畢業(yè)于北京化工大學(xué)炒辉，天津人豪墅，不知道有校友和老鄉(xiāng)嘛？對前端的熱愛辆脸，讓我們在此相聚但校，希望這篇文章，能幫助到您啡氢，也同時希望能交到志同道合的小伙伴状囱，共同發(fā)展，一起進步倘是。我的微信號dm120225亭枷，備注簡書，期待您的光臨搀崭。

上一篇我們聊了聊docker的基本操作叨粘，鏈接：寫給前端的docker簡明教程。那么這一篇瘤睹，我們就用docker安裝nginx升敲，聊一聊nginx的基本操作。

我們將會從以下幾部分展開：nginx介紹轰传、nginx原理驴党、nginx安裝、nginx配置获茬、nginx應(yīng)用港庄，一步步的和大家一起學(xué)習(xí)nginx。

nginx介紹

定義

我們先來看下nginx的基本定義吧：

nginx是一個高性能的http和反向代理的web服務(wù)器恕曲，同時也提供了IMAP POP3 SMTP服務(wù)鹏氧。

不過我們一般不使用nginx作為郵件服務(wù)器，最多的用途佩谣，是利用nginx高性能的http部署應(yīng)用和反向代理做轉(zhuǎn)發(fā)把还。說到這，我們看一下兩個基本概念茸俭，正向代理和反向代理有什么區(qū)別吊履。

正向代理和反向打理

實踐中客戶端無法直接跟服務(wù)端發(fā)起請求的時候，我們就需要代理服務(wù)瓣履。代理可以實現(xiàn)客戶端與服務(wù)端之間的通信,我們的Nginx也可以實現(xiàn)相應(yīng)的代理服務(wù)率翅。

正向代理

客戶端 <一> 代理 一>服務(wù)端

我們簡單地打個租房的比方:

A(客戶端)想租C(服務(wù)端)的房子,但是A(客戶端)并不認(rèn)識C(服務(wù)端)租不到。
B(代理)認(rèn)識C(服務(wù)端)能租這個房子所以你找了B(代理)幫忙租到了這個房子袖迎。

這個過程中C(服務(wù)端)不認(rèn)識A(客戶端)只認(rèn)識B(代理)
C(服務(wù)端)并不知道A(客戶端)租了房子糠雨，只知道房子租給了B(代理)古徒。

反向代理

客戶端 一>代理 <一> 服務(wù)端

我們也用一個租房的例子:

A(客戶端)想租一個房子,B(代理)就把這個房子租給了他。
這時候?qū)嶋H上C(服務(wù)端)才是房東。
B(代理)是中介把這個房子租給了A(客戶端)损肛。

這個過程中A(客戶端)并不知道這個房子到底誰才是房東
他都有可能認(rèn)為這個房子就是B(代理)的

由上的例子和圖我們可以知道，正向代理和反向代理的區(qū)別在于代理的對象不一樣,正向代理的代理對象是客戶端,反向代理的代理對象是服務(wù)端宠页。

優(yōu)缺點

了解了正向代理和反向代理的區(qū)別后葵孤，我們來看下nginx的優(yōu)缺點。

優(yōu)點

高并發(fā)量

nginx采用了異步非阻塞的方式來處理請求暇榴，能夠支持高達5w個并發(fā)連接數(shù)的響應(yīng)厚棵。

內(nèi)存消耗小

nginx采用的事件處理方式蕉世，與多線程相比，不需要創(chuàng)建線程婆硬，每個請求占用的內(nèi)存很少狠轻，也沒有上下文切換，事件處理非常輕量級彬犯。

簡單穩(wěn)定

配置簡單（在conf文件中配置） 性能穩(wěn)定（nginx采用了分階段資源分配技術(shù)向楼，使cpu內(nèi)存占有率非常低，具有很高的穩(wěn)定性）谐区。

模塊化程度高

nginx是高度模塊化設(shè)計湖蜕。

低成本

nginx是開源免費的。

內(nèi)置的健康檢查功能

如果 nginx代理后端的某臺web服務(wù)宕機了宋列，不會影響前端訪問
節(jié)省帶寬昭抒，會直接剔除掉。

支持熱部署

啟動特別容易虚茶，并且?guī)缀蹩梢宰龅?em>724小時不間斷運行*戈鲁，即使運行數(shù)月也不需要重新啟動。還能夠在不間斷服務(wù)的情況下嘹叫，對軟件版本進行升級婆殿。

缺點

適用范圍小

nginx僅能支持http，https和Email協(xié)議罩扇，這樣就在適用范圍上面小些婆芦。

nginx不支持url來檢測

對后端服務(wù)的健康檢查，只支持通過端口來檢測喂饥，不支持通過url來檢測消约。

不支持session的直接保持

可通過ip_hash來解決。

nginx原理

現(xiàn)在我們對nginx已經(jīng)有了一些初步認(rèn)識了员帮。下面我們一起來看下nginx的原理或粮。

工作過程：
nginx在啟動后，會有一個master進程和多個worker進程捞高，master進程主要用來管理worker進程氯材，包含：接收來自外界的信號，向各worker進程發(fā)送信號硝岗，監(jiān)控worker進程的運行狀態(tài)氢哮，當(dāng)worker進程退出后（異常情況下），會自動重新啟動新的worker進程型檀。而基本的網(wǎng)絡(luò)事件冗尤，則是放在了worker進程中來處理。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求裂七，各進程互相之間是獨立的皆看。一個請求，只可能在一個worker進程中處理碍讯，一個worker進程悬蔽，不可能處理其他進程的請求扯躺。worker進程的個數(shù)是可以設(shè)置的捉兴，一般我們會設(shè)置與機器的cpu核數(shù)一致（這里面的原因與nginx的進程模型以及事件處理模型分不開的）

nginx安裝

我們了解完nginx是什么，有什么特點录语，基本原理后倍啥，下面就一起來使用docker來安裝nginx，體驗一下nginx澎埠。

我們編寫的docker-compose.yml文件內(nèi)容如下:

# docker-compose.yml

version: '3.1'
services:
  nginx:
    restart: always
    image: daocloud.io/library/nginx:1.7.8
    container_name: nginx
    ports:
      - 80:80
    volumes:
      - volumes:/etc/nginx
volumes:
  volumes: {}

我們在服務(wù)器上新建一個nginx目錄將docker-compose.yml放進去虽缕。這里要給大家解釋下數(shù)據(jù)卷為什么這么寫。docker-compose根據(jù)這個配置文件去執(zhí)行蒲稳，執(zhí)行到volumes時氮趋，會自動根據(jù)映射一個數(shù)據(jù)卷，數(shù)據(jù)卷名稱為當(dāng)前目錄名+volumes江耀，如下：

可以看到剩胁，我們在nginx目錄下使用docker-compose啟動nginx，自動創(chuàng)建了一個叫nginx_volumes的數(shù)據(jù)卷祥国。默認(rèn)nginx的安裝目錄在/etc/nginx昵观，我們來看下nginx數(shù)據(jù)卷nginx_volumes都有什么內(nèi)容。

可以看到nginx數(shù)據(jù)卷中有如上的文件舌稀。說明我們的數(shù)據(jù)卷也映射成功啊犬，接下來我們訪問下nginx。

出現(xiàn)了如上界面壁查，說明我們的nginx安裝并啟動成功觉至。

nginx配置

安裝好了nginx后，我們來看下nginx都可能會有什么配置睡腿。nginx的配置文件是nginx.conf语御，我們已經(jīng)在數(shù)據(jù)卷中映射出來了，我們來看下都有什么內(nèi)容嫉到。

我們可以看到沃暗，這里在最后又 include 了 /etc/nginx/conf.d目錄下所有以conf結(jié)尾的文件，我們來看下都有什么內(nèi)容何恶。

我們打開default.conf

這里我們截取了部分內(nèi)容孽锥。關(guān)于nginx的使用，核心可以說是去修改這個配置文件。我們來整理一下惜辑，針對這些配置文件做些介紹唬涧，來看下都是干什么用的。

整體介紹

nginx共分為三塊：main（全局塊）盛撑、events（塊）碎节、http塊

main（全局塊）

從配置文件開始到events塊之間的內(nèi)容，主要控制nginx子進程所屬的用戶和用戶組抵卫，派生子進程數(shù)狮荔，錯誤日志位置和級別，pid位置等介粘。

events塊

events塊主要影響nginx服務(wù)器與用戶的網(wǎng)絡(luò)連接殖氏，常用的設(shè)置包括是否開啟對多work_process下的網(wǎng)絡(luò)連接進行序列化，是否允許同時接收多個網(wǎng)絡(luò)連接姻采，選取哪種事件驅(qū)動模型來處理連接請求雅采，每個work_process可以同時支持的最大連接數(shù)等。

http塊

http塊包括http-全局塊慨亲、http-server塊婚瓜、upstream 塊⌒炭茫可以嵌套多個server巴刻，配置代理，緩存铐望，日志定義等絕大多數(shù)功能和第三方模塊的配置冈涧。這是我們最重要的配置，以后我們的大部分配置工作是在http塊下完成的正蛙。

http-server塊

nginx中主機的配置塊督弓，可用于配置多個虛擬主機，每個server塊就相當(dāng)于一個虛擬主機乒验。

upstream 塊

配置負載均衡愚隧。

http-server-location 塊

一個server塊可以配置多個location塊，這塊的主要作用是基于nginx服務(wù)器接收到的請求路徑锻全，對虛擬主機名稱之外的字符串進行匹配狂塘，對待定的請求進行處理。

配置詳解

#定義Nginx運行的用戶和用戶組
user www www;
#
#nginx進程數(shù),建議設(shè)置為等于CPU總核心數(shù).
worker_processes 8;
#
#全局錯誤日志定義類型,[ debug | info | notice | warn | error | crit ]
error_log /var/log/nginx/error.log info;
#
#進程文件
pid /var/run/nginx.pid;
#
#一個nginx進程打開的最多文件描述符數(shù)目,理論值應(yīng)該是最多打開文件數(shù)（系統(tǒng)的值ulimit -n）與nginx進程數(shù)相除,但是nginx分配請求并不均勻,所以建議與ulimit -n的值保持一致.
worker_rlimit_nofile 65535;
#
#工作模式與連接數(shù)上限
events
{
    #參考事件模型,use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型是Linux 2.6以上版本內(nèi)核中的高性能網(wǎng)絡(luò)I/O模型,如果跑在FreeBSD上面,就用kqueue模型.
    use epoll;
    #單個進程最大連接數(shù)（最大連接數(shù)=連接數(shù)*進程數(shù)）
    worker_connections 1024;    #最大連接數(shù)鳄厌，默認(rèn)為512
}
#
#設(shè)定http服務(wù)器
http
{
    include mime.types; #文件擴展名與文件類型映射表
    default_type application/octet-stream; #默認(rèn)文件類型荞胡，文件流形式
    #charset utf-8; #默認(rèn)編碼
    server_names_hash_bucket_size 128; #服務(wù)器名字的hash表大小
    client_header_buffer_size 32k; #上傳文件大小限制
    large_client_header_buffers 4 64k; #設(shè)定請求緩
    client_max_body_size 8m; #設(shè)定請求緩
      keepalive_timeout 65;  #連接超時時間，默認(rèn)為75s了嚎，可以在http泪漂，server廊营，location塊。
    # 開啟目錄列表訪問,合適下載服務(wù)器,默認(rèn)關(guān)閉.
    autoindex on; # 顯示目錄
    autoindex_exact_size on; # 顯示文件大小 默認(rèn)為on,顯示出文件的確切大小,單位是bytes 改為off后,顯示出文件的大概大小,單位是kB或者MB或者GB
    autoindex_localtime on; # 顯示文件時間 默認(rèn)為off,顯示的文件時間為GMT時間 改為on后,顯示的文件時間為文件的服務(wù)器時間
    
    sendfile on; # 開啟高效文件傳輸模式,sendfile指令指定nginx是否調(diào)用sendfile函數(shù)來輸出文件,對于普通應(yīng)用設(shè)為 on,如果用來進行下載等應(yīng)用磁盤IO重負載應(yīng)用,可設(shè)置為off,以平衡磁盤與網(wǎng)絡(luò)I/O處理速度,降低系統(tǒng)的負載.注意：如果圖片顯示不正常把這個改成off.
    tcp_nopush on; # 防止網(wǎng)絡(luò)阻塞
    tcp_nodelay on; # 防止網(wǎng)絡(luò)阻塞
    
    
    # FastCGI相關(guān)參數(shù)是為了改善網(wǎng)站的性能：減少資源占用,提高訪問速度.下面參數(shù)看字面意思都能理解.
    fastcgi_connect_timeout 300; ## 鏈接
    fastcgi_send_timeout 300;  ##讀取 是指nginx進程向fastcgi進程發(fā)送request的整個過程的超時時間
    fastcgi_read_timeout 300;  ##發(fā)請求 是指fastcgi進程向nginx進程發(fā)送response的整個過程的超時時間
    fastcgi_buffer_size 64k;
    fastcgi_buffers 4 64k;
    fastcgi_busy_buffers_size 128k;
    fastcgi_temp_file_write_size 128k;
    
    # gzip模塊設(shè)置
    gzip on; #開啟gzip壓縮輸出
    gzip_min_length 1k; #允許壓縮的頁面的最小字節(jié)數(shù),頁面字節(jié)數(shù)從header偷得content-length中獲取.默認(rèn)是0,不管頁面多大都進行壓縮.建議設(shè)置成大于1k的字節(jié)數(shù),小于1k可能會越壓越大
    gzip_buffers 4 16k; #表示申請4個單位為16k的內(nèi)存作為壓縮結(jié)果流緩存,默認(rèn)值是申請與原始數(shù)據(jù)大小相同的內(nèi)存空間來存儲gzip壓縮結(jié)果
    gzip_http_version 1.1; #壓縮版本（默認(rèn)1.1,目前大部分瀏覽器已經(jīng)支持gzip解壓.前端如果是squid2.5請使用1.0）
    gzip_comp_level 2; #壓縮等級.1壓縮比最小,處理速度快.9壓縮比最大,比較消耗cpu資源,處理速度最慢,但是因為壓縮比最大,所以包最小,傳輸速度快
    gzip_types text/plain application/x-javascript text/css application/xml;
    #壓縮類型,默認(rèn)就已經(jīng)包含text/html,所以下面就不用再寫了,寫上去也不會有問題,但是會有一個warn.
    gzip_vary on;#選項可以讓前端的緩存服務(wù)器緩存經(jīng)過gzip壓縮的頁面.例如:用squid緩存經(jīng)過nginx壓縮的數(shù)據(jù)
    
    #開啟限制IP連接數(shù)的時候需要使用
    #limit_zone crawler $binary_remote_addr 10m;
    
    #虛擬主機的配置
    server
    {
        # 監(jiān)聽端口
        listen 80;
        # 域名可以有多個,用空格隔開
        server_name 127.0.0.1;
        # HTTP 自動跳轉(zhuǎn) HTTPS
        rewrite ^(.*) https://www.baidu.com;
        deny 127.0.0.1;  #拒絕的ip
        allow 172.18.5.54; #允許的ip 
    }
    upstream myserver {   
      server 127.0.0.1:8080;
      server 192.168.24.189:8080 backup;  #熱備
    }
    server
    {
        # 監(jiān)聽端口 HTTPS
        listen 443 ssl;
        server_name https://www.baidu.com;
        root /data/www/;
        # 配置域名證書
        ssl_certificate      C:\WebServer\Certs\certificate.crt;
        ssl_certificate_key  C:\WebServer\Certs\private.key;
        ssl_session_cache    shared:SSL:1m;
        ssl_session_timeout  5m;
        ssl_protocols SSLv2 SSLv3 TLSv1;
        ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
        ssl_prefer_server_ciphers  on;
    
        index index.html index.htm index.php;
        
        location ~ .*\.(php|php5)?$
        {
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
            include fastcgi.conf;
        }
        
        # 配置地址攔截轉(zhuǎn)發(fā)萝勤，解決跨域驗證問題
        location /oauth/{
            proxy_pass https://localhost:13580/oauth/;
            proxy_set_header HOST $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
        
        # 圖片緩存時間設(shè)置
        location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
            expires 10d;
        }
        
        # JS和CSS緩存時間設(shè)置
        location ~ .*\.(js|css)?$ {
            expires 1h;
        }

        # 日志格式設(shè)定
        log_format access '$server_name $remote_addr -$remote_user [$time_local] "$request"'
                  '$status $uptream_status $body_bytes_sent "$http_referer"'
                  '"$http_user_agent" "$http_x_forwarded_for" '
                  '$ssl_protocol $ssl_cipher $upstream_addr $request_time $upstream_response_time';
       # 定義本虛擬主機的訪問日志
        access_log /var/log/nginx/access.log access;
        
        # 設(shè)定查看Nginx狀態(tài)的地址.StubStatus模塊能夠獲取Nginx自上次啟動以來的工作狀態(tài)露筒，此模塊非核心模塊，需要在Nginx編譯安裝時手工指定才能使用
        location /NginxStatus {
            stub_status on;
            access_log on;
            auth_basic "NginxStatus";
            auth_basic_user_file conf/htpasswd;
            #htpasswd文件的內(nèi)容可以用apache提供的htpasswd工具來產(chǎn)生.
        }
    }
}

內(nèi)置變量

$remote_addr:客戶端的IP地址
$remote_user:客戶端用戶名敌卓，用于記錄瀏覽者進行身份驗證時提供的名稱慎式，如果沒有登錄，則為空
$time_local 訪問的時間和時區(qū)   如21/Sep/ 2016:12:21:15 + 0800  時間信息最后的+0800表示服務(wù)器所處時區(qū)位于UTC之后的8小時
$request 請求的URI和HTTP協(xié)議  如GET/HTTP/1.1
$status 記錄請求返回的HTTP狀態(tài)碼  如 200（成功）
$body_bytes_sent 發(fā)送給客戶端的文件主體內(nèi)容大小 如899
$http_referer   來路URL地址
$http_user_agent   客戶端瀏覽器信息
$http_x_forwarded for   客戶端ip地址列表（包括中間經(jīng)過的代理）

以上的nginx配置是比較全的了趟径，里面涉及到的像work_process 指令瘪吏，$remote_addr等內(nèi)置變量和其他配置，下面附上了大佬們的參考鏈接舵抹，大家可以詳細的進行查看肪虎。下面我們針對location塊的匹配做一個簡單的介紹。

location匹配

介紹

location指令是http模塊當(dāng)中最核心的一項配置惧蛹，根據(jù)預(yù)先定義的URL匹配規(guī)則來接收用戶發(fā)送的請求，根據(jù)匹配結(jié)果刑枝，將請求轉(zhuǎn)發(fā)到后臺服務(wù)器香嗓、非法的請求直接拒絕并返回403、404装畅、500錯誤處理等靠娱。

語法

nginx官方文檔給出location語法如下：

location [=|~|~*|^~] uri { … }
其中，方括號中的四種標(biāo)識符是可選項掠兄，用來改變請求字符串和uri的匹配方式像云。uri是待匹配的請求字符串，可以是不包含正則的字符串蚂夕，這種模式被稱為“標(biāo)準(zhǔn)的uri"迅诬；也可以包含正則，這種模式被稱為"正則uri"婿牍，如下：

location ~ .*\.(php|php5)?$ { }

uri匹配模式

location指令分為兩種匹配模式：

• 普通字符串匹配：以=開頭或開頭無引導(dǎo)字符（～）的規(guī)則

• 正則匹配：以～或～開頭表示正則匹配侈贷，~表示正則不區(qū)分大小寫

= 精確匹配；用于標(biāo)準(zhǔn)uri前等脂，要求請求字符串和uri嚴(yán)格匹配俏蛮。如果匹配成功，就停止匹配上遥，立即執(zhí)行該location里面的請求搏屑。
~ 正則匹配；用于正則uri前粉楚，表示uri里面包含正則辣恋，并且區(qū)分大小寫。
~* 正則匹配；用于正則uri前抑党，表示uri里面包含正則包警，不區(qū)分大小寫。
^~ 非正則匹配底靠；用于標(biāo)準(zhǔn)uri前害晦，nginx服務(wù)器匹配到前綴最多的uri后就結(jié)束，該模式匹配成功后暑中，不會使用正則匹配壹瘟。
無 普通匹配（最長字符匹配）；與location順序無關(guān)鳄逾，是按照匹配的長短來取匹配結(jié)果稻轨。若完全匹配，就停止匹配雕凹。

uri 匹配規(guī)則

當(dāng)nginx收到一個請求后殴俱，會截取請求的URI部份，去搜索所有l(wèi)ocation指令中定義的URI匹配模式枚抵。在server模塊中可以定義多個location指令來匹配不同的url請求线欲，多個不同location配置的URI匹配模式，總體的匹配原則是：先匹配普通字符串模式（普通匹配汽摹，匹配到會暫存李丰，繼續(xù)搜索正則匹配），再匹配正則模式(正則模式匹配到逼泣，即為最終匹配)趴泌。只識別URI部份，例如請求為：/test/abc/user.do?name=xxxx

一個請求過來后拉庶，Nginx匹配這個請求的流程如下：

• 先查找是否有=開頭的精確匹配
  如：location = /test/abc/user.do { … }

• 再查找普通匹配
  以 最大前綴 為原則嗜憔，如有以下兩個location，則會匹配后一項
  location /test/ { … } location /test/abc { … }

匹配到一個普通格式后砍的，搜索并未結(jié)束痹筛，而是暫存當(dāng)前匹配的結(jié)果，并繼續(xù)搜索正則匹配模式

所有正則匹配模式location中找到第一個匹配項后廓鞠，就以此項為最終匹配結(jié)果

所以正則匹配項匹配規(guī)則帚稠，受定義的前后順序影響，但普通匹配模式不會

如果未找到正則匹配項床佳，則以普通匹配中緩存的結(jié)果為最終匹配結(jié)果

如果一個匹配都沒搜索到滋早，則返回404

綜上所述：location匹配優(yōu)先級為：

（精確匹配 = ）> (最長字符串匹配，但完全匹配 /xxx/yyy/zzz) >（非正則匹配 ^~）>（正則匹配 ~ ~*）>（最長字符串匹配砌们，不完全匹配 /abc）>（location通配 / /abc）

nginx應(yīng)用

下面呢杆麸，我們一起來看下搁进，nginx在我們工作中都會有什么用途。

web服務(wù)器

我們先來看下nginx定義

nginx是一個高性能的http和反向代理的web服務(wù)器昔头，同時也提供了IMAP POP3 SMTP服務(wù)

nginx是一個web服務(wù)器饼问，實際上，當(dāng)我們啟動了nginx之后揭斧，訪問80端口莱革，我們已經(jīng)可以看到一個界面，這就是nginx作為web服務(wù)器的一個應(yīng)用讹开。下面我們就一起來部署一個web應(yīng)用盅视。

• 新增nginx配置文件location模塊，配置如下：

• 在數(shù)據(jù)卷目錄下旦万，新增web1項目

  
  

現(xiàn)在我們已經(jīng)有了web1項目

• 重啟nginx

• 瀏覽器訪問 /web1

這就是nginx作為web服務(wù)器最簡單的例子闹击。客戶端通過瀏覽器訪問成艘，nginx截取/web1字符串拿到location中按照匹配原則進行匹配赏半，匹配到了之后返回相應(yīng)的資源。

反向代理

前面我們已經(jīng)講過了什么是反向代理狰腌。但是我們?yōu)槭裁葱枰聪虼砟爻疲繉嶋H上，在我們的前端琼腔，處理跨域請求的時候，通常情況下會直接使用webpack-dev-server為我們提供的proxy踱葛，也就是我們常說的CORS去處理跨域請求丹莲。實際上，如果我們在自己本機上搭建一臺nginx作為一個代理服務(wù)器尸诽，幫助我們將請求轉(zhuǎn)發(fā)出去甥材，這也是一種選擇。

反向代理實際上是 客戶端訪問應(yīng)用性含，nginx作為代理服務(wù)器轉(zhuǎn)發(fā)請求到真正的服務(wù)器洲赵，真正的服務(wù)器拿到數(shù)據(jù)后給到nginx，nginx返回給客戶端商蕴。下面我們就使用tomcat作為后端服務(wù)器叠萍，nginx作為反向代理。一起來看下吧绪商。

• 準(zhǔn)備好tomcat的docker-compose.yml文件

• 啟動tomcat1 docker-compose up -d

• 輸入網(wǎng)址苛谷，能正常訪問

  
  

• 配置nginx，新增location和upstream如下：

注意：upstream和server塊同級

• 保存配置格郁，重啟nginx
• 瀏覽器訪問/tomcat1

反向代理生效腹殿。

負載均衡

那么什么是負載均衡独悴？我們?yōu)槭裁葱枰撦d均衡？

傳統(tǒng)的架構(gòu)是锣尉，客戶端直接訪問服務(wù)端刻炒，服務(wù)端直接客戶端返回數(shù)據(jù)。但是隨著用戶量的增大自沧，訪問量的增大坟奥，一臺服務(wù)器無法承受原本的壓力，于是擴充了多臺服務(wù)器暂幼，就是服務(wù)器集群筏勒。那么我們的用戶訪問，比如說http://www.baidu.com旺嬉，我們訪問百度管行，只需要記住一個地址就可以了，而背后可能有成千上萬臺服務(wù)器邪媳，我們不可能去記住所有服務(wù)器的ip地址和端口號捐顷，我們只想記住一個域名就可以直接訪問應(yīng)用。nginx就是來幫助我們解決這個問題的雨效。

用戶發(fā)送請求迅涮，訪問的是nginx。nginx對用戶發(fā)送過來的請求進行轉(zhuǎn)發(fā)徽龟，那么按照什么策略進行轉(zhuǎn)發(fā)叮姑，能保證服務(wù)器的利用比較充分，用戶能夠流暢的進行訪問据悔，并且不會宕機传透，這就是我們說的nginx負載均衡。nginx為我們提供了多種負載均衡策略极颓，包括但不限于 輪詢朱盐、權(quán)重、ip_hash菠隆、fair兵琳、least_conn等，這里我們介紹比較常用的前三種骇径。

為了演示負載均衡躯肌，首先我們準(zhǔn)備兩個tomcat服務(wù)，這里我們直接看下效果既峡。

訪問8081端口

訪問8082端口

到此呢羡榴，我們的兩個tomcat服務(wù)和nginx已經(jīng)準(zhǔn)備好，下面介紹下nginx的負載均衡策略运敢。

輪詢

將客戶端發(fā)起的請求校仑，平均的分配給每一臺服務(wù)器忠售。

這是nginx默認(rèn)的負載均衡策略，我們在nginx中配置下

• 進入nginx的數(shù)據(jù)卷

  
  

• 對conf.d 的default.conf進行配置

• 配置結(jié)束后重啟nginx

我們可以看到迄沫，當(dāng)客戶端發(fā)送請求到/tomcat1時稻扬，nginx進行轉(zhuǎn)發(fā)，轉(zhuǎn)發(fā)到兩個服務(wù)羊瘩，8081和8082的tomcat服務(wù)泰佳，nginx默認(rèn)采用的是輪詢策略，我們用瀏覽器訪問測試下尘吗，可以發(fā)現(xiàn)逝她，頁面在tomcat1服務(wù)和tomcat2服務(wù)中跳來跳去，并且是每個服務(wù)交替訪問睬捶，這就是nginx負載均衡的輪詢策略黔宛。

權(quán)重

將客戶端的請求，根據(jù)服務(wù)器的權(quán)重值不同擒贸，分配不同的數(shù)量臀晃。

我們的服務(wù)器，在不能保證配置相同的情況下介劫，有的服務(wù)器配置相對較低徽惋，有的服務(wù)器配置相對較高，那么我們就讓配置較高的服務(wù)器多處理請求座韵，配置較低的服務(wù)器少處理請求险绘，這就用到了權(quán)重策略。我們在nginx中配置感受下：

• 配置權(quán)重策略

  
  

我們只需要將upstream中的服務(wù)后添加weight參數(shù)即可誉碴。途中配置代表如果來了5個請求隆圆，81端口的tomcat服務(wù)處理4次，82端口的tomcat服務(wù)處理1次翔烁。

• 重啟nginx

我們用瀏覽器訪問測試下，可以看到,連續(xù)訪問5次旨涝，有4次是被tomcat1服務(wù)處理的蹬屹，有1次是被tomcat2處理的，這就是nginx負載均衡的權(quán)重策略白华。

ip_hash

基于發(fā)起請求的客戶端的ip地址不同慨默，始終會將請求發(fā)送到指定的服務(wù)器上。

上面的兩種方法可能存在一個問題弧腥，就是我們?nèi)绻辉谝慌_服務(wù)器去處理請求的話厦取，用戶第一次訪問tomcat1服務(wù)，第二次訪問tomcat2服務(wù)管搪，那就造成了session丟失的問題虾攻。那么為什么會這樣呢铡买？我們簡單的理解下cookie session鑒權(quán)策略
用戶輸入賬號密碼，向服務(wù)端發(fā)送請求霎箍，服務(wù)端校驗通過后給服務(wù)端種cookie奇钞，cookie中存有session_id字段，服務(wù)端存儲session作為唯一標(biāo)識漂坏，下次用戶再訪問從cookie中讀取session_id景埃，和服務(wù)端存儲的session進行對比，如果能找到顶别，那么給客戶端返回數(shù)據(jù)谷徙。

那么如果我們第一次訪問tomcat1服務(wù)，第二次訪問tomcat2服務(wù)驯绎，假設(shè)session存儲在tomcat1服務(wù)中完慧，那么自然tomcat2中拿不到用戶的session，這就造成了session丟失的問題条篷。那么怎么解決這個問題呢骗随？

1.我們可以弄一臺session服務(wù)器專門存儲session，為多個服務(wù)器共享赴叹，這樣問題就解決了鸿染，但是久而久之，session服務(wù)器數(shù)據(jù)越來越大乞巧，或許還需要一個session集群涨椒。

2.基于token的鑒權(quán)策略。用戶登錄成功后绽媒，我們給用戶簽發(fā)一個token蚕冬，用戶每次請求都帶來這個token，服務(wù)端進行解析是辕，能正確解析出來數(shù)據(jù)囤热，給客戶端返回數(shù)據(jù)。解析的過程是在程序計算出來的获三，也就是說旁蔼，這個算法，每臺服務(wù)器都存在疙教，可以解決這個問題棺聊。

3.基于nginx的ip_hash策略。這就是我們這里來介紹的贞谓，nginx負載均衡中的ip_hash策略可以解決問題限佩。用戶來訪問，nginx對其ip進行hash運算，存儲起來祟同，指定一個服務(wù)器為用戶處理請求作喘。那么下次用戶再來訪問時，就會一直訪問這臺服務(wù)器耐亏。

以上是對cookie session token的簡單了解徊都，詳細解讀可以看dog君的另一篇文章：一文讀懂cookie session token

下面我們就對nginx的ip_hash策略進行配置，nginx配置如下：

實際上广辰，我們只需要在upstream塊中添加ip_hash即可暇矫，重啟nginx，我們來測試下：可以看到择吊，一直訪問的都是tomcat1服務(wù)李根。那么為什么不是tomcat2服務(wù)呢？因為tomcat1服務(wù)的權(quán)重比較大几睛，第一次訪問的是tomcat1服務(wù)房轿，又因為有ip_hash策略，所以后面訪問的一直都是tomcat1服務(wù)了所森。

動靜分離

為了加快網(wǎng)站的解析速度囱持，可以把動態(tài)頁面和靜態(tài)頁面由不同的服務(wù)器解析，加快解析速度焕济，降低原來單個服務(wù)器的壓力

比如說纷妆，我們的圖片，js文件晴弃，css文件掩幢，html頁面咪笑，都可以放在nginx中锐峭，nginx的高性能http來幫助我們處理這些請求。像jsp等動態(tài)頁面腔彰，可以放在tomcat中來去處理芍阎。

這就是nginx的動靜分離世曾，巧妙地運用了nginx可以作為web服務(wù)器的特點。

一些計算

nginx能建立的最大連接數(shù) worker_connections * worker_processes
HTTP請求本地資源支持最大并發(fā)數(shù)量 worker_connections * worker_processes
HTTP作為反向代理支持最大并發(fā)數(shù) worker_connections * worker_processes / 2

接上面的動靜分離谴咸，這里給出一個nginx并發(fā)能力的計算公式：
worker_connections * worker_processes / 4 | 2 = nginx最終的并發(fā)能力

動態(tài)資源除以4度硝，靜態(tài)資源除以2，因為動態(tài)資源寿冕，nginx是作為反向代理存在的，客戶端發(fā)送請求給nginx椒袍，nginx發(fā)送請求給服務(wù)端驼唱，服務(wù)端返回響應(yīng)給nginx，nginx返回響應(yīng)給客戶端驹暑，一次請求玫恳，建立了4次連接辨赐。

那么我們?nèi)绻麆屿o分離的話，靜態(tài)資源交給nginx來處理京办，客戶端發(fā)送請求給nginx掀序，nginx直接返回給客戶端，那么只建立了兩次請求惭婿。所以說不恭，動靜分離，會提高nginx的并發(fā)能力财饥。

總結(jié)

那么到此為止呢换吧，我們的nginx已經(jīng)介紹完畢了。對于nginx钥星，以上內(nèi)容只是皮毛沾瓦，強大的nginx考慮到了我們多種應(yīng)用場景，太多的配置供我們選擇谦炒，比如說upstream 中的backup贯莺，設(shè)置備用機，作為代理服務(wù)器可以修改請求頭和響應(yīng)頭等等宁改，備用機可以作為我們進行版本升級發(fā)布時進行用戶無感知熱更新缕探，那么作為代理服務(wù)器，大家想到他可以做什么呢透且？這個問題留給大家來思考啦撕蔼！最后，給大家附上一個彩蛋吧秽誊，我們在vue項目中如何使用nginx進行無感知發(fā)版鲸沮，也是某大神的良心之作
vue項目部署的最佳實踐,實現(xiàn)無感知發(fā)版

參考鏈接：
16張圖入門nginx
nginx配置文件詳解
nginx配置中l(wèi)ocation匹配規(guī)則詳解

我是前端dog君，一名95后前端小兵锅论。對前端的熱愛讼溺，讓我們在此相聚，希望這篇文章最易，能幫助到您怒坯，也同時希望能交到志同道合的小伙伴，共同發(fā)展藻懒，一起進步剔猿。我的微信號dm120225，備注簡書嬉荆，期待您的光臨归敬。