負載均衡

GSLB

全域性負載均衡。

如：張三訪問某應用，先請求了邊緣排程節點，邊緣排程節點由中心排程節點調控，然後再去請求應用服務。

SLB

排程節點和服務節點通常在一個邏輯地域。

四層負載均衡和七層負載均衡

四層負載均衡

傳輸層控制，對客戶端的請求，進行TCP/IP協議的包轉發，效能快。

七層負載均衡

可以處理應用層，如改寫HTTP的頭資訊、重定向等。
Nginx就是一個典型的七層負載均衡的SLB。

Nginx負載均衡

Nginx提供一個服務池（upstream server），配置了很多相同的服務節點，進行輪詢訪問。

配置語法

syntax：upstream name{ ... }
Default：
Context：http
 

簡單場景測試

在/etc/nginx/conf.d/下配置三個服務節點，監聽不同埠，模擬遠端服務節點。
server1.conf

server {
    listen       8001;
    server_name  localhost;

    #charset koi8-r;
    #access_log  /var/log/nginx/host.access.log  main;

    location / {
        root   /opt/app/code1;
        index  index.html index.htm;
    }
    #......
}

server2.conf和server3.conf類似，埠分別為8002、8003。

在此目錄下配置負載均衡節點，upstream_test.conf

    upstream server-pool{
        server 192.168.174.132:8001;
        server 192.168.174.132:8002;
        server 192.168.174.132:8003;
    }

server {
    listen       80;
    server_name  localhost;

    #charset koi8-r;
    #access_log  /var/log/nginx/host.access.log  main;

    location / {
        proxy_pass http://server-pool;
        include proxy_params;
    }
    #.....
}
 

注意：由於upstream需要配置在http結點下，而conf.d目錄下的配置檔案都在nginx.conf中屬於http節點，股配置在最外層，這裡配置了3個服務節點，服務開啟時，Nginx會自動進行檢測伺服器的連通性，若開啟前不連通，則Nginx無法開啟。
使用proxy_pass，基本原理也就是代理轉發，這裡應該是反向代理。
注：
upstream名稱，在某些條件下，可以當成主機名傳給後端Java應用。當upstream名稱中含有下劃線的時候，Java會把主機名當做域名來按照[RFC2396]解析，結果就會返回Null，在某些版本的Spring框架裡就會觸發伺服器內部錯誤，此類問題相當隱蔽。
域名命名規則
domainlabel = alphanum | alphanum *( alphanum | “-” ) alphanum
建議：upstream名稱不包含下劃線，實踐中使用駝峰命名規範貌似比較合適

效果

主機訪問http://192.168.174.132:80，訪問到Server1，重新整理訪問到Server2，重新整理訪問到Server3，再重新整理訪問到Server1，可見Nginx以輪詢策略進行負載均衡訪問。
使用iptables -I INPUT -p tcp --dport 8002 -j DROP，宕掉8002的伺服器，主機重新整理訪問只能訪問到Server1和Server3。

upstream舉例

    upstream name{
		server backend1.example.com weight=5;
		server backend2.example.com:8080;
		server unix:/tmp/backend3;

		server backup1.example.com:8080 backup;
		server backup2.example.com:8080 backup;
    }

（1）server後可加IP、域名、Socket
（2）server後可以加一些引數

backup演示

將upstream_test.conf修改如下：

    upstream server_pool{
        server 192.168.174.132:8001 down;
        server 192.168.174.132:8002 backup;
        server 192.168.174.132:8003 max_fails=1 fail_timeout=10s;
    }

其中8001不參與負載均衡，8002留作後備機，8003正常節點（失敗次數1，失敗後的暫停時間10s）
服務啟動後，重新整理頁面訪問Server3，使用iptables -I INPUT -p tcp --dport 8003 -j DROP阻止8003埠訪問，再重新整理，等N秒後訪問到Server2，使用iptables -F清空訪問規則，再重新整理立馬可以訪問Server3。

排程演算法

加權輪詢

    upstream server_pool{
        server 192.168.174.132:8001;
        server 192.168.174.132:8002 weight=5;
        server 192.168.174.132:8003;
    }

理論上，7個請求中會有5個訪問到Server2。

ip_hush

為了讓使用者的Cookie有效，不造成頻繁掉線，出現了ip_hash策略。

    upstream server_pool{
    	ip_hash;
        server 192.168.174.132:8001;
        server 192.168.174.132:8002;
        server 192.168.174.132:8003;
    }

注意關鍵字放的位置。
缺點：無法取到使用者的IP

least_conn

    upstream server_pool{
    	least_conn;
        server 192.168.174.132:8001;
        server 192.168.174.132:8002;
        server 192.168.174.132:8003;
    }

注意關鍵字放的位置。

url_hush

syntax：hash key [consistent];
Default：預設無
Context：upstream
This directive appeared in version 1.7.2.

配置

    upstream server_pool{
    	hash $request_uri;
        server 192.168.174.132:8001;
        server 192.168.174.132:8002;
        server 192.168.174.132:8003;
    }

效果

訪問同一個URL的時候，訪問的是同一個伺服器。

自定義Key

使用正則提取出響應的key，然後對該值進行hash即可。