本文的前提需要了解一些 Linux 知識。
以下圍繞 Nginx 1.23 的網(wǎng)關(guān)應(yīng)用；參考官網(wǎng)：http://nginx.org/
本文沒有對概念性方面做深入的闡述，常見的是一筆帶過，而更多的...是對配置項的解釋。

為什么需要網(wǎng)關(guān)

通常后臺提供了不同的應(yīng)用服務(wù)，甚至是集群，每種服務(wù)每個服務(wù)，需要維護不同的請求地址，甚至服務(wù)認(rèn)證、跨域等動作，管理起來比較麻煩。因此，需要一個網(wǎng)關(guān)，介于客戶端和應(yīng)用服務(wù)之間，所有的外部請求都會先經(jīng)過網(wǎng)關(guān)，網(wǎng)關(guān)再把請求分發(fā)到目標(biāo)服務(wù)。網(wǎng)關(guān)對外提供唯一請求入口，作為對外聯(lián)系的窗口，易于管理和維護請求。

作者：[Sol·wang] - 博客園，原文出處：https://www.cnblogs.com/Sol-wang/

一、Nginx 概述

Nginx 不僅是一個高性能的Web服務(wù)器，還具備訪問代理、負(fù)載均衡、內(nèi)容緩存等功能，用于客戶端訪問流量到后臺應(yīng)用服務(wù)器負(fù)載均衡和請求轉(zhuǎn)發(fā)。其基于模塊化的代碼架構(gòu)及可與其它有效集成的可編程特性，使其具有強大的擴展能力。Nginx以資源消耗低、高穩(wěn)定、高性能的并發(fā)處理能力著稱。

1.1 Nginx 特性

訪問代理：
Nginx 可以通過訪問路徑、URL 關(guān)鍵字、客戶端 IP等多種手段實現(xiàn)訪問路由分配。

反向代理：
將接收到的請求再轉(zhuǎn)到后端的目標(biāo)應(yīng)用服務(wù)器，并把響應(yīng)數(shù)據(jù)返回給客戶端。支持目前絕大多數(shù)的網(wǎng)絡(luò)協(xié)議：HTTP/FastCGI/RPC/UDP/TCP等。

負(fù)載均衡：
通過自身的 upstream 模塊支持多種負(fù)載均衡算法，使后端服務(wù)器可以非常方便地進行橫向擴展，以應(yīng)對高并發(fā)。

內(nèi)容緩存：
Nginx支持靜態(tài)站點和后端分離，可以把靜態(tài)內(nèi)容緩存起來，也可以將后端變化不大的響應(yīng)結(jié)果緩存起來，使整體實現(xiàn)了更高速的相應(yīng)能力。

可擴展性：
可定制的模塊化架構(gòu)方式，更多的語言(C/Perl/JavaScript/Lua)支持開發(fā)第三方模塊并引入，增強可編程及擴展能力。

1.2 Nginx 進程

首先，進程是CPU管理的運行單元，CPU的單個核心也可以運行多個進程，只不過是交替運行著各個進程，稱為時間片，這種方式速度很快，以至于看上去像在同時運行；多核CPU就能同時運行更多的進程。

Nginx是由多個進程運行，一個主進程Master和多個子進程Worker，主進程負(fù)責(zé)管理子進程，如：重啟/重載/創(chuàng)建/銷毀等，子進程負(fù)責(zé)處理具體的請求等業(yè)務(wù)功能。進程間共享內(nèi)存數(shù)據(jù)，更多的進程帶來更好的處理能力。

Nginx 進程運行示意圖：

1.3 Nginx 重載

Nginx支持配置信息的重載，并以最新的配置內(nèi)容運行，當(dāng)Nginx在高速運行的時候，如何做到平穩(wěn)過渡呢？

相關(guān)命令：nginx -s reload

重載過程：
Nginx Master process 負(fù)責(zé) fork 出一個新的 Worker process，最新的Worker使用新的配置信息運行，此時，Worker有新舊之分，新 Worker 用新配置運行，舊 Worker 依然用舊配置運行，這時候就銷毀一個舊的worker。Master繼續(xù) fork 出新的 Worker。。。以同樣的方式持續(xù)替換舊Worker，直到全部替換完成。整個過程中，Nginx 并沒有停止運行，絲滑過渡。

二、安裝配置

2.1 編譯安裝

安裝前提：

yum install gcc -y                # C語言編譯器
yum install pcre pcre-devel -y    # PCRE Library
yum install zlib zlib-devel -y    # zlib Library

編譯安裝：

# 進入解壓后的目錄中 編譯安裝 [指定用戶/組] [--with-追加自帶模塊名稱] 
./configure --prefix=/usr/local/nginx [--user=www --group=www] [--with-http_gzip_static_module]
make && make install

2.2 啟動實例

進入主進程目錄：/usr/local/nginx/bin

nginx            # 啟動
nginx -s stop    # 停止，立即
nginx -s quit    # 退出，處理完現(xiàn)有任務(wù)后
nginx -s reopen  # 重啟
nginx -s reload  # 重載配置，交替更新工作進程

docker 運行 nginx 很簡單：

拉取鏡像：docker pull nginx
啟動容器：docker run -d --name=ngx-a -p 80:80 nginx

瀏覽器打開主機IP顯示 NGINX 歡迎頁面。

影響 Nginx 的系統(tǒng)關(guān)聯(lián)項

Firewall/UFW 防火墻：端口的開放
SELinux 權(quán)限的限制：請求后端的權(quán)限

2.3 配置文件結(jié)構(gòu)

nginx 的配置文件默認(rèn)存于 /etc/nginx/nginx.conf，其中通過 include 引入其它目錄子配置文件。

• 全局塊：針對 Nginx 實例的設(shè)置，資源及事件的設(shè)定。
• HTTP：從 Client 到 Nginx 的請求設(shè)置，請求過程中要處理的各項配置；
• Upstream：代理轉(zhuǎn)發(fā)的下個目的地列表，后端服務(wù)組地址列表，連接與負(fù)載均衡的設(shè)定。
• Server：從 Nginx 到 Service 的設(shè)置，通常對應(yīng)前后端某種服務(wù)或組；限制設(shè)定，代理設(shè)定，錯誤機制等。
• Location：路由匹配轉(zhuǎn)發(fā)通訊，重定向等。

配置模板示例

###### 全局塊
worker_processes    auto;                   # 工作進程數(shù)
error_log  /var/log/nginx/error.log notice; # 錯誤級別記錄

events {
    worker_connections  1024;               # 單個工作進程，可承載的最大連接數(shù)
}

http {
    ###### MIME 配置
    include       /etc/nginx/mime.types;    # 文件擴展名與文件類型映射表
    default_type  application/octet-stream; # mime.types 不包含時的默認(rèn)設(shè)置
    
    ###### 請求日志配置
    log_format  log-format-a  '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_forwarded_for"';
    access_log  /var/log/nginx/access.log  log-format-a;    # 訪問日志路徑 及引用格式
    
    ###### 后端可用服務(wù)配置
    upstream backend-server-name {
        server 192.168.1.101:80;
        server 192.168.1.102:80;
    }
    
    server {
        ###### 請求匹配
        listen       80;                 # 客戶端請求的端口
        server_name  _;                  # 客戶端請求的域名；區(qū)分不同服務(wù)（可多個空格區(qū)分,支持正則）
        
        location / {
            ###### 重寫配置
            rewrite ^<規(guī)則>$ <目的地> break;
            
            ###### 轉(zhuǎn)發(fā)到后端配置
            proxy_pass http://backend-server-name$request_uri;    # 轉(zhuǎn)發(fā)到后臺服務(wù)地址，來自于 upstream 項
            proxy_http_version 1.1;                               # 指明版本（1.1默認(rèn)為keep-alive長連接，1.0默認(rèn)為短連接）
            proxy_set_header Host $host;                          # 保持原來的請求域名
            proxy_ignore_client_abort on;                         # 客戶端斷網(wǎng)時，是否中斷對后端的請求
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 從遠(yuǎn)程客戶端IP到服務(wù)端的層層代理轉(zhuǎn)發(fā)IP，多IP追加空格分隔
            
            ###### Cookie 域名/路徑
            proxy_cookie_domain {backend-domain} {request-domain};
            proxy_cookie_path {backend-path} {request-path};
        }
        
        ###### 指定文件拒絕所有訪問
        location ~ ^/(\.user.ini|\.ht|\.git|\.svn|\.project|LICENSE|README.md){
            deny all;
        }
        
        ###### 限制的客戶端
        location \ {
            deny 172.18.0.101;    # 拒絕的ip
            allow 172.18.1.10;    # 允許的ip
        }
        
        ###### 客戶端緩存配置
        location ~* \.(js|css|jpg|svg|gif|png)$ {
            if (-f $request_filename) {    # -f：只能是文件，因為這用-f判斷了
                expires 30d;               # 緩存有效時長 30 天
                break;
            }
        }
        
        ###### 防盜鏈配置
        location ~* \.(gif|jpg|png|bmp)$ {  # 指定格式禁止的請求來源：google/baidu
            valid_referers none blocked *.ttlsa.com server_names ~\.google\. ~\.baidu\.;
            if ($invalid_referer) {
                return 403;                 # 狀態(tài)碼
                #rewrite ^/ http://www.ttlsa.com/403.jpg;
            }
        }
        
        ###### (前端) 錯誤機制
        error_page  404              /404.html;    # 錯誤碼 轉(zhuǎn)向的 錯誤頁
        error_page  500 502 503 504  /50x.html;    # 錯誤碼 轉(zhuǎn)向的 錯誤頁
        location = /50x.html {                     # 錯誤頁 指向的 靜態(tài)頁面
            root   /usr/share/nginx/html;
        }
    }
}

2.4 前后端分離

把前端站點部署到 Nginx：

server {
    listen 80;
    server_name xxx.com;
    
    # 前端配置
    location / {
        # 前端站點路徑
        root /home/vue/dist;
        index index.html
    }
    
    # 后端配置
    location /api {
        proxy_set_header host $HOST;
        proxy_pass http://192.168.1.101:8081;
    }
}

2.5 負(fù)載均衡模式

在配置項 upstream 中，負(fù)責(zé)提供可用的服務(wù)地址列表，并可指定負(fù)載均衡的實現(xiàn)方式。

輪詢 Round-Robin：將訪問按序依次請求到后端各個服務(wù)器上，能確保平均負(fù)載

upstream backend-a {
    server 192.168.1.101:80;
    server 192.168.1.102:80;
}

?權(quán)重 Weight：按百分比請求到后端服務(wù)器上，常用到硬件配置不同的場景

upstream backend-b {
    server 192.168.1.101:80 weight=3;
    server 192.168.1.102:80 weight=7;
}

?最少連接 Least-Connect：處理請求少的后端服務(wù)優(yōu)先接收新請求

upstream backend-c {
    least_conn;
    server 192.168.1.101:80;
    server 192.168.1.102:80;
}

IP-Hash：相同的訪問IP落到后端同個服務(wù)器上，所以支持會話保持，但不是絕對平均負(fù)載

upstream backend-d {
    ip_hash;
    server 192.168.1.101:80;
    server 192.168.1.102:80;
}

第三方的會話保持 sticky_cookie_insert，同時支持負(fù)載均衡。

2.6 限流與熔斷

限流：通過對并發(fā)/請求進行限速來保護系統(tǒng)，防止系統(tǒng)過載癱瘓而不能提供服務(wù)；為了更好控制整個系統(tǒng)的負(fù)載情況，即使阻止了某些請求，系統(tǒng)繼續(xù)提供服務(wù)。

http_limit_conn：單個IP同時允許的連接限制

http {
    
    # 連接限流定義
    # - $binary_remote_addr：限制對象(客戶端)
    # - zone：限制自定義名稱
    # - 10：內(nèi)存中用10兆空間存儲連接記錄
    limit_conn_zone $binary_remote_addr zone={limits-name}:10m;
                
    server {
        location /search/ {
            
            # 單個IP同時允許建立多少連接（并發(fā)限制）
            limit_conn {limits-name} 1;
        }
    }
}

http_limit_req：單個IP請求頻率的限制；次/每秒；

http {
    # 請求限流定義
    # - $binary_remote_addr：限制對象(客戶端)
    # - zone：定義限制(策略)名稱
    # - 10m：用十兆空間記錄訪問次數(shù)
    # - rate：每秒10次的請求處理速率
    limit_req_zone $binary_remote_addr zone={limits-name}:10m rate=1r/s;
    # 請求限流定義
    # - $server_name：限制對象，對指定服務(wù)器請求的限制
    limit_req_zone $server_name zone={limits-name}:10m rate=10r/s;
                
    server {
        location /search/ {
            # 引用以上定義的限流策略，做以下設(shè)定（漏桶方式）
            # - burst：最多接收5個排隊用戶IP，處于等待處理狀態(tài)（容量）
            # - nodelay：超出排隊之外的更多請求，拒絕并返回503（溢出）
            limit_req zone={limits-name} [burst=5] [nodelay];
        }
    }
}

http_limit_rate：向客戶端傳輸響應(yīng)的速率限制；字節(jié)/每秒/每連接；0不限制

http {   
    server {
        location /download/ {
            
            # 帶寬限制
            limit_rate_after 5m; # 初始限速5m
            limit_rate 500k;     # 超出后限速500k
        }
    }
}

熔斷：當(dāng)后端服務(wù)發(fā)生指定頻率錯誤后，Nginx觸發(fā)熔斷措施，不再請求此后端服務(wù)，直接返回默認(rèn)內(nèi)容到用戶端。

upstream http_backend {
    # 10s內(nèi)出現(xiàn)3次錯誤，該服務(wù)器將被視為不可用(熔斷)
    server 192.168.1.101:8080 max_fails=3 fail_timeout=10s;
    server 192.168.1.102:8080 max_fails=3 fail_timeout=10s;
}

當(dāng)然也有容錯機制，Nginx 默認(rèn)自動轉(zhuǎn)向其它服務(wù)再請求，相關(guān)配置：proxy_next_upstream

不成文的內(nèi)存使用計算公式

給 Nginx 預(yù)備多大的內(nèi)存，隨著參數(shù)的調(diào)整而變化，特定緩存排除在外；
預(yù)估 Nginx 內(nèi)存使用計算公式：worker_processes * worker_connections / 1000 = G

三、性能優(yōu)化

3.1 全局優(yōu)化

# 工作進程數(shù)
worker_processes auto;           # 建議 CPU核心數(shù)|CPU線程數(shù)

# 最大支持的連接(open-file)數(shù)量；最大值受限于 Linux open files (ulimit -n)
# 建議公式：worker_rlimit_nofile > worker_processes * worker_connections
worker_rlimit_nofile    65535;

events {
    use epoll;                   # 高效的IO多路復(fù)用（RedHat6+ 都支持 epoll）
    multi_accept on;             # 設(shè)置一個進程是否同時接受多個網(wǎng)絡(luò)連接
    worker_connections  10240;   # 單個工作進程，可承載的最大連接數(shù)；
}

3.2 與客戶端之間的優(yōu)化

http {
    
    ###### 零拷貝技術(shù)
    sendfile on;            # 開啟不讀到(應(yīng)用本身)內(nèi)存，直接通過系統(tǒng)發(fā)出數(shù)據(jù)
    #sendfile_max_chunk 2m; # 每個進程每次調(diào)用傳輸數(shù)量不能大于設(shè)定的值，默認(rèn)0為無上限。
    
    ###### 網(wǎng)絡(luò)傳輸
    # on：累積到一定容量的數(shù)據(jù)再發(fā)，發(fā)送次數(shù)少
    # off：有數(shù)據(jù)就發(fā)，發(fā)送次數(shù)多，占用網(wǎng)絡(luò)資源
    tcp_nopush on;
    
    ###### 長連接；用戶端比較分散，keepalive 默認(rèn)值已經(jīng)足夠，個人不建議重設(shè)
    
    ###### 響應(yīng)數(shù)據(jù) 開啟壓縮模式
    gzip on;
    gzip_vary on;                                # 為兼容老瀏覽器，追加到Header的壓縮標(biāo)注
    gzip_proxied any;                            # 所有代理請求都壓縮，也可指定類型
    gzip_comp_level 2;                           # 壓縮等級1-9(比例)等級越大 壓縮越高 越耗CPU
    gzip_min_length 128;                         # 壓縮前提，當(dāng)返回內(nèi)容大于指定時再壓縮
    gzip_types text/css text/xml image/svg+xml;  # 指定壓縮的文件類型；更多壓縮項可參考 mime.types
}

3.3 與后端服務(wù)之間的優(yōu)化

http {
    upstream backend_A {
        # ...
        
        # 長連接；所有請求匯聚到后端服務(wù)器，并發(fā)時是有必要在此基礎(chǔ)上重配 keepalive 的
        # 以下 keepalive 需要 http 1.1 版本，并且 header connection close
        keepalive 100;           # 每個Worker與后端的連接池中，保持指定量的空閑連接數(shù)（QPS的10%）
        keepalive_time 1h;       # 每個長連接的(忙碌+空閑)總時長，超出后強制失效
        keepalive_timeout 60s;   # 每個長連接，最大空閑時長，超出后自動關(guān)閉長連接
        keepalive_requests 1000; # 每次長連接支持的 Request 次數(shù)，超出后自動關(guān)閉
    }
    
    server {
        location \ {
            proxy_pass http://backend_A;
            proxy_http_version 1.1;            # 1.1 支持 keep-live
            proxy_set_header connection "";    # 覆蓋客戶端的連接頭
        }
    }
}

3.4 Cache settings

也就是把客戶端訪問的數(shù)據(jù)放到緩存中，緩存可以存到瀏覽器中，也可以存到Nginx中，當(dāng)用戶端發(fā)起請求時，直接將緩存中對應(yīng)的結(jié)果返回給用戶端，減少了大量的重復(fù)請求。

A.前端資源文件 css/js/image 緩存到瀏覽器，以減少瀏覽器向Nginx的請求：

http {
    ###### 靜態(tài)資源文件緩存（css/js/image）[HTTP1.1]
    # - public：可被任何對象緩存（不限瀏覽器）
    # - max-age：設(shè)定緩存有效期(秒)
    # - private：私有緩存；如：僅瀏覽器緩存，公共代理服務(wù)器不緩存
    # - no-cache：可緩存，每次驗證有效性，有效時跳過響應(yīng)體的回傳
    # - no-store：請求與響應(yīng)，不使用任何緩存
    add_header Cache-Control private,max-age=60;    # 僅在瀏覽器緩存60秒
    # HTTP1.0 版本設(shè)置方式為：Expires 1m;（不支持強制刷新）
}

B.變更頻率較少的后端應(yīng)用接口返回數(shù)據(jù)緩存到磁盤，Nginx直接讀磁盤數(shù)據(jù)返回給客戶端，減少Nginx向后端服務(wù)的請求：

http {
    ###### 定義緩存數(shù)據(jù)的存儲
    # - path：磁盤必須存在的目錄
    # - levels：緩存目錄結(jié)構(gòu)，1-3層級
    # - keys_zone：緩存定義的名稱及空間大小
    # - inactive：定義超出未使用時長后自動刪除
    proxy_cache_path {path} levels=1:2 keys_zone={cache-name}:50m inactive=1d;
    
    server {
        # ...
        location /api/ {
            proxy_cache {cache-name};     # 引用以上定義的緩存名稱
            proxy_cache_valid 200 302;    # 指定返回狀態(tài)才進行緩存
        }
    }
}

按照以上設(shè)置的{path}緩存目錄，看看Nginx緩存了什么...

3.5 擴展優(yōu)化

多級緩存：通過 Nginx 實現(xiàn)各種緩存的配置，瀏覽器緩存、CDN緩存、Nginx內(nèi)存、代理緩存、后端服務(wù)應(yīng)用緩存等。

資源靜態(tài)化 ssi 模塊：請求結(jié)果生成靜態(tài)頁，Nginx設(shè)置攔截，更多的請求直接讀靜態(tài)頁后返回；減少后端請求，定時生成靜態(tài)頁。

靜態(tài)資源同步 rsync：每臺服務(wù)都安裝，監(jiān)控目錄變化，把生成的靜態(tài)頁推送到多臺服務(wù)器。

合并請求 concat 第三方模塊：將多個靜態(tài)資源文件 合并為一次請求加載完成，減少并發(fā)量；淘寶示例：??xxx.js,yyy.js,zzz.js

四、動態(tài)負(fù)載

自動更新 upstream 上的可用服務(wù)地址，Nginx 的商業(yè)版才提供，開源的可去選擇第三方模塊；這里后端集群管理用的是 Consul；所以這里使用 Consul 提供的配套工具 Consul-Template。
當(dāng)后端集群 consul 上的應(yīng)用服務(wù)有變動時，工具 consul-template 負(fù)責(zé)拉取 consul 最新的健康應(yīng)用服務(wù)列表，并生成 nginx conf，最主要的是更新了 nginx upstream 中的可用服務(wù)地址，最后再重載 Nginx。

1、下載部署 consul-template

# 從官網(wǎng) https://releases.hashicorp.com/consul-template/ 下載軟件包
curl -O https://releases.hashicorp.com/consul-template/0.31.0/consul-template_0.31.0_linux_amd64.zip
unzip consul-template_0.31.0_linux_amd64.zip consul-template # unzip解壓軟件包并重命名
mv consul-template /usr/local/bin/                           # 移動到特定目錄
/usr/local/bin/consul-template -v                            # 驗證安裝效果，顯示版本號

2、創(chuàng)建生成 nginx conf 的模板文件 ngx-server-conf.tmp，用于生成指定格式的 nginx.conf 文件；內(nèi)容示例如下：

為便于集中管理配置文件，存放于 nginx 默認(rèn)的配置目錄下 /etc/nginx/conf.d/ngx-server-conf.tmp

########## 自動生成多個 upstream
{{range services}} {{$name := .Name}} {{$service := service .Name}}
upstream {{$name}} {
        least_conn;
        {{range $service}}server {{.Address}}:{{.Port}};
        {{else}}server 127.0.0.1:65535; # force a 502{{end}}
} {{end}}
########## upstream end ##########

server {
        listen 80;
        server_name xxx.com;
        location / {
                root /usr/share/nginx/html/;
                index index.html;
        }

        ########## 自動生成多個 locattion
{{range services}} {{$name := .Name}}
        location /api/{{$name}} {
                proxy_pass http://{{$name}};
                proxy_http_version 1.1;
        }
{{end}} ########## location end ##########
}

更多的模板文件語法可參考官網(wǎng)說明：consul-template templating language

3、創(chuàng)建 consul-template 的配置文件 ctmp.hcl，用以設(shè)定運行參數(shù)。內(nèi)容示例如下：

為便于集中管理配置文件，存放于 nginx 容器內(nèi)的默認(rèn)配置目錄下 /etc/nginx/conf.d/ctmp.hcl

# 連接 consul 的配置
consul {
    address = "172.18.0.3:8500"    # consul node
}

# 生成 nginx config file 的配置
template {
    source = "/etc/nginx/conf.d/ngx-server-conf.tmp"   # consul-template 的配置模板文件
    destination = "/etc/nginx/conf.d/default.conf"     # 生成的 nginx-server 配置文件
    command = ["nginx", "-s", "reload"]                # 執(zhí)行的命令，以重載 Nginx 配置
}
# 總結(jié)步驟：從 address 拉數(shù)據(jù)，通過格式 source 生成 destination 配置，最后 command 重載Nginx。

以上更多的配置項參考官網(wǎng)說明：consul-template configuration options

4、啟動運行 consul-template

# 指定配置文件 啟動 consul-template
/usr/local/bin/consul-template -config /etc/nginx/conf.d/ctmp.hcl
# 驗證效果：可查看生成的 nginx conf
cat /etc/nginx/conf.d/default.conf

效果：先查看當(dāng)前 nginx default.conf；之后停掉后端一個應(yīng)用服務(wù)，再查看對比 nginx 前后兩個 default.conf 的內(nèi)容變化。

五、高可用

高可用 - 雙機熱備：主機和從機通過TCP/IP網(wǎng)絡(luò)連接，正常情況下主機處于工作狀態(tài)，從機處于監(jiān)視狀態(tài)，一旦從機發(fā)現(xiàn)主機異常，從機將會在很短的時間之內(nèi)代替主機，完全實現(xiàn)主機的功能。

工具 Keepalived，安裝到內(nèi)網(wǎng)中每個裝有 Nginx 的系統(tǒng)上：
多個 Keepalived 實例形成一個組，組成員有 Master/slave 之分，時時監(jiān)控組內(nèi)所有 Keepalived 實例的運行情況；
Keepalived 通過一個虛擬IP加入到 Master 網(wǎng)卡上，所以通過虛擬IP能夠直接連接到 Master上，也就是其中一個 Nginx；
一個 Keepalived 成員宕機后，從 Slave 中選舉出新的 Master，也就是把虛擬IP自動加入到新的 Master上，持續(xù)提供服務(wù)；
對外僅通過內(nèi)網(wǎng)的虛擬IP完成與 Nginx 的連接，而不關(guān)心使用的 Nginx 在哪臺機上。

Keepalived 官網(wǎng)

5.1 配置運行 Keepalived

安裝 Keepalived：yum install -y keepalived
配置文件：/etc/keepalived/keepalived.conf
配置模板：可僅留 global_defs，vrrp_instance，virtual_ipaddress

global_defs {
    router_id <key>           # 同組不重復(fù)的唯一標(biāo)識
}

vrrp_instance <Instance-Name> {
    state MASTER              # MASTER/BACKUP;有主優(yōu)先運行
    interface <net-card-name> # 指定虛擬IP寄存的網(wǎng)卡
    priority 100              # 相同角色的優(yōu)先級，越大越優(yōu)先
    advert_int 1              # 間隔秒檢測一次成員的運行狀況
    
    authentication {          # 成員間的通訊憑證
        auth_type PASS        # 同組相同的方式
        auth_pass 1111        # 同組相同的編碼，保持成員互通
    }
    
    virtual_ipaddress {       # 追加新IP，對外提供的通訊入口
        192.168.17.200        # 同網(wǎng)段的、未被使用的、虛擬新IP
    }
}

啟動后，可在 Master 中的指定網(wǎng)卡中看到已追加的虛擬IP；不妨 ping 下你的虛擬IP...
再配置一臺 Keepalived，注意這里配置的不同項為：router_id / state / priority

瀏覽器中訪問虛擬IP，就直接訪問了 Master 上的 Nginx；
關(guān)掉Master服務(wù)器后，Keepalived 將虛擬IP又添加到了備用服務(wù)器上了；
虛擬IP繼續(xù)提供正常的 Nginx 服務(wù)，瀏覽器正常訪問虛擬IP地址；
當(dāng) Master 修復(fù)啟動后，Keepalived 又將虛擬IP自動切換到 Master 上，始終以 Master 優(yōu)先使用。

注意

Keepalived 僅檢測自己主進程的運行狀況，并不是檢測 Nginx 的運行狀況；
所以：當(dāng) Nginx 錯誤，而 Keepalived 運行正常時，并不能達到 Master 轉(zhuǎn)移的效果；
方案：用腳本定時檢測 Nginx 的主進程，Nginx發(fā)生錯誤時主動 Kill Keepalived，達到 Master 轉(zhuǎn)移的效果。

5.2 腳本檢測 Nginx 服務(wù)

創(chuàng)建檢測腳本文件 /etc/keepalived/check_nginx.sh 內(nèi)容示例：

#!/bin/bash
# 檢測 Nginx 服務(wù)的運行狀態(tài)
cka=$(systemctl is-active nginx)
# 檢測 Nginx worker process 運行的個數(shù)
ckn=$(ps -C nginx --no-heading | wc -l)
# 雙重驗證，當(dāng) Nginx 運行異常時
# 制造keepalived異常，使得啟用備用服務(wù)器
if [ $ckn -eq 0 ] || [ $cka -ne "active" ]; then
        killall -9 keepalived
fi

并賦予用戶可執(zhí)行權(quán)限；如：chmod +x /etc/keepalived/check_nginx.sh

Keepalived 腳本定時檢測配置內(nèi)容示例：

# global_defs ...

vrrp_script check_nginx_status {             ### 定義檢測策略
    user root                                # 負(fù)責(zé)檢測的用戶
    interval 1                               # 檢測間隔秒
    script /etc/keepalived/check_nginx.sh    # 檢測的可執(zhí)行文件
}

vrrp_instance <Instance-Name> {
    # ...
    track_script {
        check_nginx_status                   # 引用檢測策略
    }
    # ...
}

在 Master 上停止 Nginx 運行 試試看...????

以上是一個聯(lián)動停止運行的方案，那是不是需要一個聯(lián)動啟動也更為方便，自行考量...文章來源地址http://www.zghlxwxcb.cn/news/detail-433215.html

到了這里，關(guān)于微服務(wù) - Nginx網(wǎng)關(guān) · 進程機制 · 限流熔斷 · 性能優(yōu)化 · 動態(tài)負(fù)載 · 高可用的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！