系統架構之負載均衡

7 層負載均衡，對應的是 http 的 7 層協議
4 層負載均衡對應的是 tcp 的 4 層協議
Nginx 現在也支持 4 層協議

核心概念

二層負載均衡

通過改寫報文的目標 MAC 地址為上游服務器 MAC 地址，源 IP 地址和目標 IP 地址是沒有變的，負載均衡服務器和真實服務器共享同一個 VIP，如LVS DR作業模式

三層負載均衡

一般采用虛擬 IP 地址方式，外部對虛擬的 IP 地址請求，負載均衡接收后分配后端實際的 IP 地址回應，（即一個 ip 對一個 ip 的轉發, 埠全放開）

四層負載均衡

根據埠將報文轉發到上游服務器（不同的 IP 地址 + 埠），如 LVS NAT 模式、HaProxy

在三次負載均衡的基礎上，即從第四層“傳輸層”開始, ****使用“虛擬 ip + port”接收請求，再轉發到對應的機器****，四層通過虛擬 IP + 埠接收請求，然后再分配到真實的服務器

七層負載均衡

是根據埠號和應用層協議如 HTTP 協議的主機名、URL，轉發報文到上游服務器（不同的 IP 地址+埠），如 HaProxy、Nginx

LVS DR 作業模式

作業在資料鏈路層，LVS 和上游服務器共享同一個 VIP，通過改寫報文的目標 MAC 地址為上游服務器 MAC 地址實作負載均衡，上游服務器直接回應報文到客戶端，不經過 LVS，從而提升性能

但是 LVS 和上游服務器必須在同一個子網，為了解決跨子網問題而又不影響負載性能，可以選擇在 LVS 后邊掛 HaProxy，通過四層到七層負載均衡器 HaProxy 集群來解決跨網和性能問題

DNS + LVS + NGINX + REAL-SERVER 四層負載均衡

負載均衡要素

• 上游服務器配置：使用 upstream server 配置上游服務器
• 負載均衡演算法：配置多個上游服務器時的負載均衡機制
• 失敗重試機制：配置當超時或上游服務器不存活時，是否需要重試其他上游服務器
• 服務器心跳檢查：上游服務器的健康檢查

總結其倆就是，負載均衡、故障轉移、失敗重試、容錯、健康檢查

上游服務器配置

upstream backend {
    server [ip]:[port] [weight=1];
}

負載均衡演算法

• round-robin
• ip_hash
• hash key [consistent]
• least_conn

upstream backend {
    # round-robin
    # ip_hash
    # hash key [consistent]
    # least_conn
    server [ip]:[port] [weight=1];
}

失敗重試

upstream backend {
    server [ip]:[port] [weight=1] max_fails=2 fail_timeout=10s;
}

通過配置上游服務器的 max_fails 和 fail_timeout，來指定每個上游服務器，當 fail_timeout 時間內失敗了 max_fails 次請求，則認為該上游服務器不可用/不存活，然后將摘掉該上游服務器，fail_timeout 時間后會再次將該服務器加入到存活上游服務器串列進行重試

location /test {
    proxy_connect_timeout 5s;
    proxy_read_timeout 5s;
    proxy_send_timeout 5s;
    # 遇到配置錯誤時，會重試下一臺上游服務器
    proxy_next_upstream error timeout;
    proxy_next_upstream_timeout 10s;
    proxy_next_upstream_tries 2;
    proxy_pass http://backend;
    add_header upstream_addr $upstream_addr
}

健康檢查

Nginx 對上游服務器的健康檢查默認采用的是惰性策略，可以使用 nginx_upstream_check_module 模塊來進行主動健康檢查

TCP檢查

upstream backend {
    server 192.168.1.1:8090 weight=1;
    check interval=3000 rise=1 fall=3 timeout=2000 type=tcp;
}

• interval: 檢測間隔時間
• fall：檢測失敗多少次后，上游服務器被標識為不存活
• rise：檢測充公多少次后，上游服務器被標識為存活，并可以處理請求
• timeout：檢測請求超時時間配置

HTTP 檢查

upstream backend {
    server 192.168.1.1:8090 weight=1;
    check interval=3000 rise=1 fall=3 timeout=2000 type=http
    check_http_send "HEAD /status HTTP/1.0\r\n\r\n";
    check_http_expect_alive http_2xx http_3xx;
}

• check_http_send：即檢查時發的 HTTP 請求內容
• check_http_expect_alive：當上游服務器回傳匹配的回應狀態碼時，則認為上游服務器存活

備份上游服務器

upstream backend {
    server [ip]:[port] [weight=1];
    server [ip]:[port] [weight=1] backup;
}

使用場景：對上游服務器進行壓測時，要摘掉一些上游服務器進行壓測，但是為了保險起見會配置一些后備上游服務器，當壓測的上游服務器都掛掉時，流量可以轉發到備用上游服務器，從而不影響用戶請求處理

不可用上游服務器

upstream backend {
    server [ip]:[port] [weight=1];
    server [ip]:[port] [weight=1] down;
}

長連接

upstream backend {
    server [ip]:[port] [weight=1];
    server [ip]:[port] [weight=1] backup;
    keepalive 100;
}
location / {
    # 支持keep-alive
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_pass http://backend;
}

如果是http/1.0，則需要配置發送“Connection: Keep-Alive”請求頭

建議

• 空閑連接池太小，鏈接不夠用，需要不斷建鏈接
• 空閑鏈接池太大，空閑鏈接太多，還沒有使用就超時

建議對于小報文開啟長連接

HTTP 反向代理

# 全域配置(proxy cache)
proxy_buffering on;
proxy_buffer_size 4;
proxy_buffers 512 4k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 256k;
proxy_cache_lock on;
proxy_cache_lock_timeout 200ms;
proxy_temp_path /tmpfs/proxy_temp;
proxy_cache_path /tmp/fs/proxy_cache levels=1:2 keys_zone=cache:512m inactive=5m max_size=8g;
proxy_connect_timeout 3s;
proxy_read_timeout 5s;
proxy_send_timeout 5;
# location 配置
# 請求上游服務器使用 GET 方法（不管請求是什么方法）
proxy_method GET;
# 不給上游服務器傳遞請求體
proxy_pass_request_body off;
# 不給上游服務器傳遞請求頭
proxy_pass_request_headers off;
# 設定上游服務器的哪些回應頭不發送給客戶端
proxy_hide_header Vary;
# 支持 keep-alive
proxy_http_version 1.1;
proxy_set_header Connect "";
# 給上游服務器傳遞 Referer、Cookie 和 Host（按需傳遞）
proxy_set_header Referer $http_referer;
proxy_set_header Coolie $http_cookie;
proxy_set_header Host web.c.3.local;
proxy_pass http://backend /$1$is_args$args;
# gzip
gzip on;
gzip_min_length 1k;
gzip_buffers 16 16k;
gzip_http_version 1.0;
gzip_proxied any;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css application/xml;
gzip_vary on;

對于內容型回應建議開啟 gzip，gzip_comp_lever 壓縮級別要根據實際壓測來決定（帶寬和吞度量之間的抉擇）

HTTP 動態負載均衡

Nginx 四層負載均衡

./configure --prefix=/usr/servers --with-stream
stream {
    upstream mysql_backend {
        ......
    }
    server {
        ......
    }
}

ref: 億級流量網站架構核心技術