負(fù)載均衡在服務(wù)端開發(fā)中算是一個(gè)比較重要的特性。因?yàn)镹ginx除了作為常規(guī)的Web服務(wù)器外，還會(huì)被大規(guī)模的用于反向代理前端，因?yàn)镹ginx的異步框架可以處理很大的并發(fā)請(qǐng)求，把這些并發(fā)請(qǐng)求hold住之后就可以分發(fā)給后臺(tái)服務(wù)端(backend servers，也叫做服務(wù)池， 后面簡稱backend)來做復(fù)雜的計(jì)算、處理和響應(yīng)，這種模式的好處是相當(dāng)多的：隱藏業(yè)務(wù)主機(jī)更安全，節(jié)約了公網(wǎng)IP地址，并且在業(yè)務(wù)量增加的時(shí)候可以方便地?cái)U(kuò)容后臺(tái)服務(wù)器。
負(fù)載均衡可以分為硬件負(fù)載均衡和軟件負(fù)載均衡，前者一般是專用的軟件和硬件相結(jié)合的設(shè)備，設(shè)備商會(huì)提供完整成熟的解決方案，通常也會(huì)更加昂貴。軟件的復(fù)雜均衡以Nginx占據(jù)絕大多數(shù)，本文也是基于其手冊(cè)做相應(yīng)的學(xué)習(xí)研究的。
.png)
負(fù)載均衡涉及到以下的基礎(chǔ)知識(shí)。
(1) 負(fù)載均衡算法
a. Round Robin: 對(duì)所有的backend輪訓(xùn)發(fā)送請(qǐng)求，算是最簡單的方式了，也是默認(rèn)的分配方式；
b. Least Connections(least_conn): 跟蹤和backend當(dāng)前的活躍連接數(shù)目，最少的連接數(shù)目說明這個(gè)backend負(fù)載最輕，將請(qǐng)求分配給他，這種方式會(huì)考慮到配置中給每個(gè)upstream分配的weight權(quán)重信息；
c. Least Time(least_time): 請(qǐng)求會(huì)分配給響應(yīng)最快和活躍連接數(shù)最少的backend；
d. IP Hash(ip_hash): 對(duì)請(qǐng)求來源IP地址計(jì)算hash值，IPv4會(huì)考慮前3個(gè)octet，IPv6會(huì)考慮所有的地址位，然后根據(jù)得到的hash值通過某種映射分配到backend；
e. Generic Hash(hash): 以用戶自定義資源(比如URL)的方式計(jì)算hash值完成分配，其可選consistent關(guān)鍵字支持一致性hash特性；
(2) 會(huì)話一致性
用戶(瀏覽器)在和服務(wù)端交互的時(shí)候，通常會(huì)在本地保存一些信息，而整個(gè)過程叫做一個(gè)會(huì)話(Session)并用唯一的Session ID進(jìn)行標(biāo)識(shí)。會(huì)話的概念不僅用于購物車這種常見情況，因?yàn)镠TTP協(xié)議是無狀態(tài)的，所以任何需要邏輯上下文的情形都必須使用會(huì)話機(jī)制，此外HTTP客戶端也會(huì)額外緩存一些數(shù)據(jù)在本地，這樣就可以減少請(qǐng)求提高性能了。如果負(fù)載均衡可能將這個(gè)會(huì)話的請(qǐng)求分配到不同的后臺(tái)服務(wù)端上，這肯定是不合適的，必須通過多個(gè)backend共享這些數(shù)據(jù)，效率肯定會(huì)很低下，最簡單的情況是保證會(huì)話一致性——相同的會(huì)話每次請(qǐng)求都會(huì)被分配到同一個(gè)backend上去。
(3) 后臺(tái)服務(wù)端的動(dòng)態(tài)配置
出問題的backend要能被及時(shí)探測并剔除出分配群，而當(dāng)業(yè)務(wù)增長的時(shí)候可以靈活的添加backend數(shù)目。此外當(dāng)前風(fēng)靡的Elastic Compute云計(jì)算服務(wù)，服務(wù)商也應(yīng)當(dāng)根據(jù)當(dāng)前負(fù)載自動(dòng)添加和減少backend主機(jī)。
(4) 基于DNS的負(fù)載均衡
通?，F(xiàn)代的網(wǎng)絡(luò)服務(wù)者一個(gè)域名會(huì)關(guān)連到多個(gè)主機(jī)，在進(jìn)行DNS查詢的時(shí)候，默認(rèn)情況下DNS服務(wù)器會(huì)以round-robin形式以不同的順序返回IP地址列表，因此天然將客戶請(qǐng)求分配到不同的主機(jī)上去。不過這種方式含有固有的缺陷：DNS不會(huì)檢查主機(jī)和IP地址的可訪問性，所以分配給客戶端的IP不確保是可用的(Google 404)；DNS的解析結(jié)果會(huì)在客戶端、多個(gè)中間DNS服務(wù)器不斷的緩存，所以backend的分配不會(huì)那么的理想。
Nginx中的負(fù)載均衡配置在手冊(cè)中描述的極為細(xì)致，此處就不流水帳了。對(duì)于常用的HTTP負(fù)載均衡，主要先定義一個(gè)upstream作為backend group，然后通過proxy_pass/fastcgi_pass等方式進(jìn)行轉(zhuǎn)發(fā)操作，其中fastcgi_pass幾乎算是Nginx+PHP站點(diǎn)的標(biāo)配了。
Nginx中的會(huì)話一致性是通過sticky開啟的，會(huì)話一致性和之前的負(fù)載均衡算法之間并不沖突，只是需要在第一次分配之后，該會(huì)話的所有請(qǐng)求都分配到那個(gè)相同的backend上面。目前支持三種模式的會(huì)話一致性：
(1). Cookie Insertion
在backend第一次response之后，會(huì)在其頭部添加一個(gè)session cookie，即由負(fù)載均衡器向客戶端植入 cookie，之后客戶端接下來的請(qǐng)求都會(huì)帶有這個(gè)cookie值，Nginx可以根據(jù)這個(gè)cookie判斷需要轉(zhuǎn)發(fā)給哪個(gè)backend了。
sticky cookie srv_id expires=1h domain=.example.com path=/;
上面的srv_id代表了cookie的名字，而后面的參數(shù)expires、domain、path都是可選的。
(2). Sticky Routes
也是在backend第一次response之后，會(huì)產(chǎn)生一個(gè)route信息，route信息通常會(huì)從cookie/URI信息中提取。
sticky route $route_cookie $route_uri;
這樣Nginx會(huì)按照順序搜索routecookie、route_uri參數(shù)并選擇第一個(gè)非空的參數(shù)用作route，而如果所有的參數(shù)都是空的，就使用上面默認(rèn)的負(fù)載均衡算法決定請(qǐng)求分發(fā)給哪個(gè)backend。
(3). Learn
較為的復(fù)雜也較為的智能，Nginx會(huì)自動(dòng)監(jiān)測request和response中的session信息，而且通常需要回話一致性的請(qǐng)求、應(yīng)答中都會(huì)帶有session信息，這和第一種方式相比是不用增加cookie，而是動(dòng)態(tài)學(xué)習(xí)已有的session。
這種方式需要使用到zone結(jié)構(gòu)，在Nginx中zone都是共享內(nèi)存，可以在多個(gè)worker process中共享數(shù)據(jù)用的。(不過其他的會(huì)話一致性怎么沒用到共享內(nèi)存區(qū)域呢？)
sticky learn
create=$upstream_cookie_examplecookie
lookup=$cookie_examplecookie
zone=client_sessions:1m
timeout=1h;
2.2 Session Draining
主要是有需要關(guān)閉某些backend以便維護(hù)或者升級(jí)，這些關(guān)鍵性的服務(wù)都講求gracefully處理的：就是新的請(qǐng)求不會(huì)發(fā)送到這個(gè)backend上面，而之前分配到這個(gè)backend的會(huì)話的后續(xù)請(qǐng)求還會(huì)繼續(xù)發(fā)送給他，直到這個(gè)會(huì)話最終完成。
讓某個(gè)backend進(jìn)入draining的狀態(tài)，既可以直接修改配置文件，然后按照之前的方式通過向master process發(fā)送信號(hào)重新加載配置，也可以采用Nginx的on-the-fly配置方式。
$ curl http://localhost/upstream_conf?upstream=backend
$ curl http://localhost/upstream_conf?upstream=backend\&id=1\&drain=1
通過上面的方式，先列出各個(gè)bacnkend的ID號(hào)，然后drain指定ID的backend。通過在線觀測backend的所有session都完成后，該backend就可以下線了。
2.3 backend健康監(jiān)測
backend出錯(cuò)會(huì)涉及到兩個(gè)參數(shù)，max_fails=1 fail_timeout=10s;意味著只要Nginx向backend發(fā)送一個(gè)請(qǐng)求失敗或者沒有收到一個(gè)響應(yīng)，就認(rèn)為該backend在接下來的10s是不可用的狀態(tài)。
通過周期性地向backend發(fā)送特殊的請(qǐng)求，并期盼收到特殊的響應(yīng)，可以用以確認(rèn)backend是健康可用的狀態(tài)。通過health_check可以做出這個(gè)配置。
match server_ok {
status 200-399;
header Content-Type = text/html;
body !~ "maintenance mode";
}
server {
location / {
proxy_pass http://backend;
health_check interval=10 fails=3 passes=2 match=server_ok;
}
}
上面的health_check是必須的，后面的參數(shù)都是可選的。尤其是后面的match參數(shù)，可以自定義服務(wù)器健康的條件，包括返回狀態(tài)碼、頭部信息、返回body等，這些條件是&&與關(guān)系。默認(rèn)情況下Nginx會(huì)相隔interval的間隔向backend group發(fā)送一個(gè)”/“的請(qǐng)求，如果超時(shí)或者返回非2xx/3xx的響應(yīng)碼，則認(rèn)為對(duì)應(yīng)的backend是unhealthy的，那么Nginx會(huì)停止向其發(fā)送request直到下次改backend再次通過檢查。
在使用了health_check功能的時(shí)候，一般都需要在backend group開辟一個(gè)zone，在共享backend group配置的同時(shí)，所有backend的狀態(tài)就可以在所有的worker process所共享了，否則每個(gè)worker process獨(dú)立保存自己的狀態(tài)檢查計(jì)數(shù)和結(jié)果，兩種情況會(huì)有很大的差異哦。
2.4 通過DNS設(shè)置HTTP負(fù)載均衡
Nginx的backend group中的主機(jī)可以配置成域名的形式，如果在域名的后面添加resolve參數(shù)，那么Nginx會(huì)周期性的解析這個(gè)域名，當(dāng)域名解析的結(jié)果發(fā)生變化的時(shí)候會(huì)自動(dòng)生效而不用重啟。
http {
resolver 10.0.0.1 valid=300s ipv6=off;
resolver_timeout 10s;
server {
location / {
proxy_pass http://backend;
}
}
upstream backend {
zone backend 32k;
least_conn;
...
server backend1.example.com resolve;
server backend2.example.com resolve;
}
}
如果域名解析的結(jié)果含有多個(gè)IP地址，這些IP地址都會(huì)保存到配置文件中去，并且這些IP都參與到自動(dòng)負(fù)載均衡。
2.5 TCP/UDP流量的負(fù)載均衡
通常，HTTP和HTTPS的負(fù)載均衡叫做七層負(fù)載均衡，而TCP和UDP協(xié)議的負(fù)載均衡叫做四層負(fù)載均衡。因?yàn)槠邔迂?fù)載均衡通常都是HTTP和HTTPS協(xié)議，所以這種負(fù)載均衡相當(dāng)于是四層負(fù)載均衡的特例化，均衡器可以根據(jù)HTTP/HTTPS協(xié)議的頭部(User-Agent、Language等)、響應(yīng)碼甚至是響應(yīng)內(nèi)容做額外的規(guī)則，達(dá)到特定條件特定目的的backend轉(zhuǎn)發(fā)的需求。
除了Nginx所專長的HTTP負(fù)載均衡，Nginx還支持TCP和UDP流量的負(fù)載均衡，適用于LDAP/MySQL/RTMP和DNS/syslog/RADIUS各種應(yīng)用場景。這類情況的負(fù)載均衡使用stream來配置，Nginx編譯的時(shí)候需要支持–with-stream選項(xiàng)。查看手冊(cè)，其配置原理和參數(shù)和HTTP負(fù)載均衡差不多。
因?yàn)門CP、UDP的負(fù)載均衡都是針對(duì)通用程序的，所以之前HTTP協(xié)議支持的match條件(status、header、body)是沒法使用的。TCP和UDP的程序可以根據(jù)特定的程序，采用send、expect的方式來進(jìn)行動(dòng)態(tài)健康檢測。
match http {
send "GET / HTTP/1.0\r\nHost: localhost\r\n\r\n";
expect ~* "200 OK";
}
2.6 其他特性
slow_start=30s：防止新添加/恢復(fù)的主機(jī)被突然增加的請(qǐng)求所壓垮，通過這個(gè)參數(shù)可以讓該主機(jī)的weight從0開始慢慢增加到設(shè)定值，讓其負(fù)載有一個(gè)緩慢增加的過程。
max_conns=30：可以設(shè)置backend的最大連接數(shù)目，當(dāng)超過這個(gè)數(shù)目的時(shí)候會(huì)被放到queue隊(duì)列中，同時(shí)隊(duì)列的大小和超時(shí)參數(shù)也可以設(shè)置，當(dāng)隊(duì)列中的請(qǐng)求數(shù)大于設(shè)定值，或者超過了timeout但是backend還不能處理請(qǐng)求，則客戶端將會(huì)收到一個(gè)錯(cuò)誤返回。通常來說這還是一個(gè)比較重要的參數(shù)，因?yàn)镹ginx作為反向代理的時(shí)候，通常就是用于抗住并發(fā)量的，如果給backend過多的并發(fā)請(qǐng)求，很可能會(huì)占用后端過多的資源(比如線程、進(jìn)程非事件驅(qū)動(dòng))，最終反而會(huì)影響backend的處理能力。
