Nginx 作為負(fù)載均衡是基于代理模式的基礎(chǔ)之上，所以在看本篇文章時(shí)犬性，你需要對 Nginx 的代理瞻离、負(fù)載均衡的基本原理及 Nginx 負(fù)載均衡配置有基礎(chǔ)的了解。
首先講一講 Nginx 作為負(fù)載均衡在整體服務(wù)架構(gòu)和網(wǎng)站服務(wù)架構(gòu)里所扮演的角色乒裆，其次重點(diǎn)介紹 Nginx 作為負(fù)載均衡時(shí)遇到的一些常見問題套利，比如客戶端 IP 地址獲取問題、域名攜帶問題 等等鹤耍。
Nginx 負(fù)載均衡應(yīng)用架構(gòu)
關(guān)于 Nginx 負(fù)載均衡應(yīng)用架構(gòu)在企業(yè)應(yīng)用中主要有兩種類型肉迫。
- 分層入口代理架構(gòu)
第一類是分層入口代理架構(gòu)（屬于相對傳統(tǒng)架構(gòu)），我們可以對整個(gè)后臺網(wǎng)站服務(wù)系統(tǒng)架構(gòu)做一個(gè)分層稿黄。大體可以分為用戶請求入口層喊衫，以及為用戶請求提供邏輯處理的服務(wù)層和為用戶提供真正相關(guān)數(shù)據(jù)的數(shù)據(jù)層。
如圖所示杆怕，我們可以發(fā)現(xiàn)入口層是最接近用戶請求的族购，所以在這一層中，Nginx 扮演著重要的角色——入口網(wǎng)關(guān)陵珍，并承擔(dān) 7 層負(fù)載均衡（LB）的功能联四。如圖所示入口層的 Nginx 之前還有一套 LB，LB層的主要功能是為了保證 Nginx 本身的高可用撑教、或承擔(dān) TCP/IP 負(fù)載均衡功能，所以這里整個(gè)入口層的負(fù)載均衡模式是一個(gè) 4層LB+7層LB（Nginx）醉拓，這套架構(gòu)中把與業(yè)務(wù)服務(wù)的相關(guān)功能則由 Nginx來處理伟姐。
哪一些業(yè)務(wù)服務(wù)相關(guān)功能交給 Nginx 作合適呢？比如在入口層我們會放一些和用戶相關(guān)的信息亿卤，也比如動靜分離（及實(shí)現(xiàn)分離網(wǎng)站頁面的靜態(tài)元素和動態(tài)元素)愤兵，我們知道靜態(tài)元素沒有必要下沉到數(shù)據(jù)層獲取，可以直接通過 Nginx 實(shí)現(xiàn)動態(tài)和靜態(tài)的分流并由 Nginx 直接處理排吴。另外秆乳，用戶的訪問控制、反爬蟲等規(guī)則也是在入口層的 Nginx 實(shí)現(xiàn)的。
服務(wù)層同樣也需要 Nginx 屹堰， 來負(fù)載均衡實(shí)現(xiàn)上層請求應(yīng)答上的高可用肛冶。
分層架構(gòu)的最后一層是數(shù)據(jù)層，數(shù)據(jù)層中 Nginx 同樣可以實(shí)現(xiàn)負(fù)載均衡扯键，但數(shù)據(jù)層中通常使用的Nginx 較少見睦袖，為什么呢？因?yàn)檫@一層更追求數(shù)據(jù)調(diào)用的效率荣刑，比如 Memcache蛤铜、MySQL 等數(shù)據(jù)庫調(diào)用更多是基于底層的協(xié)議請求午绳，而非更上層的 HTTP 請求。
但如果如果追求 HTTP 的可靠性、和應(yīng)用性榜轿，是可以借助 Nginx 的負(fù)載均衡實(shí)現(xiàn)的，如：可Redis 使用 Nginx 做反向代理浪规，通過 Nginx 把前端發(fā)送的 HTTP 請求轉(zhuǎn)換成 Redis 協(xié)議的請求方式去請求Redis凰兑，這樣就完成了 Redis 的反向代理。這種方式虱颗，企業(yè)可以很好控制Redis的監(jiān)控沥匈、數(shù)據(jù)的一致性保障、及基于 Hash 算法穩(wěn)定性保障忘渔。
總結(jié)一下高帖，Nginx在分層架構(gòu)里扮演了一個(gè)7層應(yīng)用層負(fù)載均衡角色。隨著軟件架構(gòu)和系統(tǒng)架構(gòu)是不斷演進(jìn)變化畦粮，我們發(fā)現(xiàn)企業(yè)開始采用K8s散址、Docker這種輕量化、虛擬化部署宣赔；還有很多企業(yè)更加傾向于微服務(wù)架構(gòu)预麸，支持set化等。在這樣的架構(gòu)下儒将，傳統(tǒng)的分層負(fù)載均衡模式吏祸，促使改進(jìn)去支持服務(wù)注冊和發(fā)現(xiàn)。這個(gè)就是介紹的第二種Nginx負(fù)載均衡模式钩蚊。
- 服務(wù)注冊發(fā)現(xiàn)代理架構(gòu)
如圖所示贡翘，圖中重點(diǎn)列出了 Nginx 在注冊發(fā)現(xiàn)場景中扮演的角色。同樣砰逻，我們可以看到整個(gè)流量還是通過 Nginx 來做入口網(wǎng)關(guān)的鸣驱，但是重要的一點(diǎn)是 Nginx 需要支持動態(tài)的發(fā)現(xiàn)和注冊后端服務(wù)。
注冊是指后端的應(yīng)用程序（如圖中的 App1~App4）需要去往前端的中心存儲節(jié)點(diǎn)里面注冊它的應(yīng)用服務(wù)蝠咆，當(dāng)注冊上報(bào)后踊东，Nginx 動態(tài)發(fā)現(xiàn)并動態(tài)生成發(fā)現(xiàn)的配置北滥，然后對入口網(wǎng)關(guān)代理負(fù)載均衡進(jìn)行分流調(diào)整，我們可以發(fā)現(xiàn)在基于 K8s 和 Docker 這種部署模式業(yè)務(wù)入口網(wǎng)關(guān)就應(yīng)用了這種架構(gòu)闸翅。
兩種負(fù)載均衡應(yīng)用架構(gòu)說完了再芋，我們會發(fā)現(xiàn)兩種架構(gòu)最大的區(qū)別是后面一種支持后端服務(wù)的注冊與發(fā)現(xiàn)。
nginx負(fù)載均衡常見問題
- 客戶端IP地址獲取問題
第一個(gè)問題是客戶端 IP 地址獲取問題缎脾，為什么會存在客戶端 IP 地址獲取問題呢祝闻？
我們來看這樣一張模擬圖，圖中請求從用戶到 Nginx遗菠，再到后端服務(wù)联喘。我們可以看到用戶的 IP 地址是100.100.100.100，Nginx 的地址是 192.168.0.1辙纬，通過 Nginx 負(fù)載均衡到三臺后端服務(wù)豁遭，它們的 IP分別是 192.168.1.1、192.168.1.2贺拣、192.168.1.3蓖谢。
那么客戶端的 IP 地址為什么會無法被后端服務(wù)獲取呢？原因是我們獲取方式在Nginx的加入負(fù)載均衡后出現(xiàn)了差異譬涡，具體如下：
我們了解后端服務(wù)獲取IP的方式闪幽，第一種方式是由后端服務(wù)通過 4 層 TCP 協(xié)議獲取源 IP 地址，你會發(fā)現(xiàn)涡匀，通過這種方式盯腌，后端服務(wù)只能獲取 Nginx 的 IP 地址，而無法獲取到 100.100.100.100 這個(gè)IP地址陨瘩，原因在于 Nginx 做了一層反向代理腕够，而反向代理修改了客戶的源地址和源端口的包頭，所以在后端服務(wù)舌劳，通過這種方式只能獲取到 Nginx 的 IP帚湘，而無法獲取到用戶的 IP。
另外一種方式是后端服務(wù)通過 HTTP 標(biāo)準(zhǔn)請求頭信息 X-forwarded-for 獲取用戶IP信息甚淡，但是通過代理這一層時(shí)大诸，有可能把 X-forwarded-for 改寫或丟失用戶的請求地址，這樣就有可能導(dǎo)致 Xforwarded-for 在后端無法獲取用戶信息贯卦。
X-forwarded-for 頭的格式底挫，它會一層一層往后添加信息，比如第一層是客戶端的 IP 地址脸侥，然后是通過代理后的代理層IP，代理層后一層一層的追加信息盈厘。X-forwarded-for需要通過 Nginx 配置添加睁枕，從而使得標(biāo)準(zhǔn)協(xié)議將以X-forwarded-for 頭為載體，把用戶的 IP 地址和代理層 IP 地址添加到這個(gè)載
體中，這樣后端才能通過X-forwarded-for 獲取到詳細(xì)的 IP 地址信息外遇。
解決辦法
知道了問題發(fā)生的原因注簿，我們?nèi)绾蝸斫鉀Q呢？
第一種方式的解決辦法是在 Nginx 負(fù)載均衡的基礎(chǔ)上添加了一個(gè)轉(zhuǎn)發(fā)到后端的標(biāo)準(zhǔn) head 信息跳仿，把用戶的 IP 信息通過 X-Forwarded-For 方式傳遞過去诡渴。
第二種方式是就是添加一個(gè) X-Real 的自定義頭，自定義頭我們可以隨意的命名菲语，一般情況下命名為X-Real_IP妄辩，把用戶的真實(shí)四層 IP地址賦值給它，如何做到呢山上？
remote_addr 是一個(gè) Nginx 的內(nèi)置變量眼耀，它獲取到的是 Nginx 層前端的用戶 IP 地址，這個(gè)地址是一個(gè) 4 層的 IP 地址佩憾，我們來上圖哮伟，Nginx 的 IP 地址是 192.168.0.1，它的 remote_addr 是什么呢妄帘？它就是用戶的 100.100.100.100 這個(gè)地址楞黄，也就是直接將 TCP/IP 協(xié)議的用戶 IP 地址（源地址）以 remote_addr 變量的方式賦值給 X-Real_IP 的自定義變量，后端直接通過X-Real 獲取 X-Real IP信息抡驼，便可獲取到用戶地址鬼廓。
更深一層的分析，這兩種解決方式雖然解決地址獲取的問題婶恼，但各有優(yōu)劣桑阶，X-Forwarded-For 是通過Nginx 中的 $proxy_add_x_forwarded_for 內(nèi)置變量獲取的頭信息，通過 X-Forwarded-For傳遞到后端勾邦。在 Nginx 通過 proxy_add_x_forwarded_for 內(nèi)置變量獲取的 X-Forwarded-For 信息本身可能不準(zhǔn)確 因?yàn)榍岸擞脩艨梢宰鞔鄹?HTTP 的請求頭 所以如果被一些惡意用戶篡改了請求的 XForwarded 信息就會導(dǎo)致信息影響獲取真實(shí)的用戶 IP 地址信息蚣录。
第二種方式相對于第一種方式而言更加準(zhǔn)確，因?yàn)?remote_addr 是直接獲取第一層代理的用戶 IP 地址眷篇，如果直接把這個(gè)地址傳遞給 X-Real萎河，這樣就會更加準(zhǔn)確。但是它有什么劣勢呢蕉饼？如果是多級代理的話虐杯，用戶如果不是直接請求到最終的代理層，而是在中間通過了 n 層帶來轉(zhuǎn)發(fā)過來的話昧港，此時(shí)remote_addr 可能獲取的不是用戶的信息擎椰，而是 Nginx 最近一層代理過來的 IP 地址，此時(shí)同樣沒有獲取到真實(shí)的用戶 IP 地址信息创肥。
可以看到达舒，這兩種方式各有優(yōu)劣值朋，通常你也可以把這兩種配置都加進(jìn)去，然后交給后端綜合分析巩搏，這就是對于客戶端 IP 地址攜帶通常的配置方式昨登。
- 如何解決域名攜帶
第二個(gè)問題，也就是 Nginx 作為負(fù)載均衡是如何把請求域名信息攜帶到后端的贯底？這樣的問題是什么樣的場景呢丰辣？首先我們來看一張示意圖。
用戶的 IP 同樣是 100.100.100.100禽捆，Nginx 對外 IP 地址是 200.200.200.200笙什，Nginx 本身內(nèi)部的地址是 192.168.0.1，同樣分發(fā)給三個(gè)后端服務(wù)睦擂。當(dāng)用戶請求某一 Nginx 入口域名時(shí)得湘，會攜帶一個(gè)頭信息，叫作 Host 頭信息顿仇。如果通過域名方式淘正，當(dāng)用戶請求的是 http://www.baidu.com，它的 Host頭就是 www.baidu.com臼闻，以這樣的方式請求到代理層時(shí)鸿吆，由于 Nginx 沒有將頭信息攜帶到后端，而是把配置的頭信息置為空述呐，這樣就導(dǎo)致后端服務(wù)想要獲取不到用戶請求的 Host 信息惩淳，導(dǎo)致服務(wù)不可用。這時(shí)需要 Nginx 將用戶攜帶的 Host 頭信息真實(shí)的傳遞給后端乓搬。
第二種情況是假設(shè)用戶請求用的 IP 地址方式（非域名）思犁，此時(shí)會發(fā)現(xiàn)，用戶請求的 IP 地址的 Host頭信息本身就是空的进肯，所以如果后端需要用到 Host 頭信息激蹲，這就需要在 Nginx 中把 Host 頭改寫為一個(gè)要求的頭信息，我們來看下這個(gè)場景配置：
http {
…
upstream app_servers {
server ip1:port1;
server ip2:port2;
server ip3:port3;
}
server {
…
location / {
proxy_set_header Host $host ;
proxy set_header Host www.vipumi.com;
proxy_pass http://app_servers;
}
….
}
}
我們通過 proxy_set_header 配置方式加入 Host 頭部字段江掩，如果用戶的請求攜帶了域名学辱，就把這個(gè)域名的 head 頭以標(biāo)準(zhǔn)的 HTTP 方式將頭信息傳遞到后端，然后讓后端獲取 Host 頭信息环形，這樣訪問就不會受影響策泣。
然后，如果用戶沒有攜帶頭信息抬吟，而后端又要求指定域名萨咕，那么我們就可以在 proxy_set_header下，將 Host 頭信息指定成一個(gè)固定的域名火本，保證滿足后臺對 Host 頭信息的要求危队，這樣就可以解決域名攜帶問題蓄喇。
- 負(fù)載均衡導(dǎo)致session丟失問題
另外一個(gè)是 session 丟失問題，我們知道交掏，session 是用戶的一個(gè)會話信息，服務(wù)端和用戶端通信需要一個(gè)訪問認(rèn)證刃鳄，以及對鑒權(quán)處理的時(shí)候盅弛，給客戶端分配一串 session 信息，這個(gè) session 信息會在客戶端以 cookie 的方式承載到服務(wù)端中進(jìn)行校驗(yàn)叔锐。如果加入 Nginx 負(fù)載均衡挪鹏，會默認(rèn)開啟一個(gè)輪詢策略。假如這樣的一種場景愉烙，用戶請求到 Nginx讨盒，第一次請求會分發(fā)給 App server 1，第二次請求分發(fā)給 App server 2步责，但用戶的 session 保留在 App1 上返顺，此時(shí)這條請求再去請求 App2 的話，由于App2 上沒有 session 信息蔓肯，就導(dǎo)致會話丟失遂鹊，用戶需要重新登錄。我們看到 Nginx 作為負(fù)載均衡 + Java 后臺應(yīng)用中遇見的一種問題蔗包，我們該怎樣解決呢秉扑？
- Session 保持
第一種方式是做 Session 保持，就是把負(fù)載均衡策略基于原有輪詢數(shù)的基礎(chǔ)上调限，改用 ip_hash舟陆、URL_hash 來解決。ip_hash 就是基于用戶 IP 來做 hash耻矮，一個(gè)用戶的請求統(tǒng)一分發(fā)到一臺機(jī)器上秦躯。URL_hash 用于用戶請求固定頁面時(shí)，將用戶請求固定到具體 后端 上淘钟，就保證了 Session 不會被丟失宦赠。
- Session復(fù)制
第二種方式是 Session 復(fù)制。所謂 Session 復(fù)制是在后臺應(yīng)用的基礎(chǔ)上米母，讓 Session 之間可以以傳播的方式進(jìn)行復(fù)制勾扭。也就是 App1 上如果有一個(gè)Session，那么它可以復(fù)制給 App2铁瞒、App3妙色，無論怎樣輪詢，三個(gè) App 上都會有同樣的Session 信息慧耍，不至于因?yàn)檩喸儗?dǎo)致丟失會話失效身辨。
- Session 共享
Session 共享是由程序完成的丐谋，我們把 Session 信息不放在本地，通過應(yīng)用程序把 Session 信息放入共享的 K/V 存儲中煌珊，這樣就不會產(chǎn)生 Session 丟失情況了号俐。
我們可以看到，如果 Nginx 解決 Session 丟失問題基于 Session 保持來解決定庵，所以怎樣配置 Nginx呢吏饿？
http {
…
upstream app_servers {
ip_hash;
server ip1:port1;
server ip2:port2;
server ip3:port3;
}
server {
…
location / {
proxy_pass http://app_servers;
}
….
}
}
這個(gè)配置中我們在負(fù)載均衡 Upstream 對應(yīng)的地址池中加入一個(gè) ip_hash 策略猪落，這樣就可以基于 ip_hash 的方式進(jìn)行輪詢了。
http {
…
upstream app_servers {
hash $request_uri;
server ip1:port1;
server ip2:port2;
server ip3:port3;
}
server {
…
location / {
proxy_pass http://app_servers;
}
….
}
}
第二種方式基于 URL_hash笨忌，URL_hash 方式就是添加一個(gè)自定義 hash，通過設(shè)置 Nginx 內(nèi)部的請求變量 $request_url 進(jìn)行 hash 運(yùn)算官疲，這樣就可以基于這個(gè)請求的 URL 地址來做 hash 了，也就做到Session 的保持的方案庶艾。
- 真實(shí)的 Realserver 狀態(tài)檢測
最后一個(gè)常見問題是如何檢測后端的 Realserver 狀態(tài)，我們首先需要了解Nginx 默認(rèn)真實(shí)檢測后臺服務(wù)狀態(tài)是怎么實(shí)現(xiàn)的.
生產(chǎn)環(huán)境中 一個(gè) Nginx 作為負(fù)載均衡如果發(fā)現(xiàn)后端某一個(gè)節(jié)點(diǎn)出現(xiàn)問題 那么它會把這個(gè)節(jié)點(diǎn)剔除颖榜，并檢測下一個(gè)節(jié)點(diǎn)，那么 Nginx 是如何檢測到節(jié)點(diǎn)有問題呢煤裙？默認(rèn)情況下掩完，Nginx 基于 TCP 端口和連接方式檢測，也就是在服務(wù) ping 不通硼砰，或無法建立 TCP 鏈接且蓬，以及端口服務(wù)完全不可用的狀態(tài)下，才會認(rèn)為這個(gè)服務(wù)不可用题翰。
你可以想一想恶阴，在 Nginx 的這種檢測機(jī)制下通常是有遺漏的，如果響應(yīng)狀態(tài)或返回狀態(tài)有問題豹障，對于Nginx 代理層而言冯事，它并沒有做到一個(gè)有效的容錯(cuò)，只是檢測底層 TCP 連接方式血公，是不是也存在一定的局限性.
這個(gè)時(shí)候昵仅，你可能會想是否可以加入一個(gè) proxy_next_upstream 就可以把后端節(jié)點(diǎn)剔除呢？proxy_next_upstream 雖然能夠檢測到服務(wù)端返回到前端的狀態(tài)碼，但是無法做到真正自動摘除故障節(jié)點(diǎn)摔笤。
那么怎么做呢够滑？這里就需要依賴一個(gè)第三方模塊了，這個(gè)第三方模塊就是nginx_upstream_check_module吕世，它是由淘寶技術(shù)團(tuán)隊(duì)開發(fā)并開源的彰触，提供了更加細(xì)致的對后臺服務(wù)真實(shí)狀態(tài)的檢測。你可以把這個(gè)模塊編譯到 Nginx 中命辖，或是使用淘寶的 Tengine渴析，Tengine 也是基于 Nginx 1.6 版本開發(fā)開源的。我們接下來看下具體配置：
check interval=3000 rise=2 fall=5 timeout=1000 type=http; //定義檢查間隔吮龄、周期、時(shí)
check_keepalive_requests 100; //一個(gè)連接發(fā)送的請求數(shù)
check_http_send “HEAD / HTTP/1.1\r\nConnection: keep-alive\r\n\r\n”; //定義健康檢查
check_http_expect_alive http_2xx http_3xx; //判斷后端返回狀態(tài)碼
通過這樣的配置咆疗，我們定義了檢測間隔漓帚、周期和超時(shí)時(shí)間；定義了一個(gè)連接發(fā)送的請求數(shù)午磁；然后是定義健康檢查方式尝抖，比如檢查 head 頭的請求信息；最后判斷后端返回狀態(tài)碼迅皇，如果是非 200 或 300 的話昧辽，就認(rèn)為后臺服務(wù)不健康，需要把這個(gè)問題服務(wù)除掉登颓，避免用戶請求到問題節(jié)點(diǎn)搅荞。
未完待續(xù)
此文為系列文章，游戲發(fā)布于公眾號框咙，期待您的關(guān)注！公眾號：運(yùn)維大師兄喇嘱。
