Keepalived-HAProxy 搭建高可用負載均衡
負載均衡是分佈式系統中不可或缺的重要環節，通過負載均衡按照指定的調度算法將請求分發至網絡中多個節點進行處理。本文將介紹基於開源軟件 HAProxy 實現負載均衡並且通過 Keepalived 實現高可用的配置方法，希望讀者通過參考本文的探索成果可以快速實現高可用的軟件負載均衡，也希望讀者能夠舉一反三、觸類旁通，通過自我驅動進行更深入的研究來配置更多的功能來滿足自身需求。
1. 概述
軟件負載均衡技術是指可以爲多個後端服務器節點提供前端 IP 流量分發調度服務的軟件技術。Keepalived 和 HAProxy 是衆多軟負載技術中的兩種，其中 Keepalived 既可以實現負載均衡也可以實現高可用，而 HAProxy 則更加專注於提供高性能 TCP 和 HTTP 反向代理和負載均衡能力。
1.1 Keepalived
Keepalived 工作在 OSI 模型中的四層傳輸層。最初它是爲了管理並監控 Linux 虛擬服務器（LVS）集羣中各服務節點的狀態，後來又加入了路由冗餘協議（VRRP）來實現高可用功能，所以 Keepalived 除了可以管理配置 LVS 外，還可以作爲 Nginx、HAProxy 等的高可用解決方案。
Keepalived 同時運行於主服務器（Master）和備服務器（Backup）之上，所有的服務器上運行的 Keepalived 之間通過 VRRP 交互，VRRP 設計目的是爲了解決靜態路由單點故障問題，保證個別節點宕機時，整個網絡可以不間斷的運行。
Keepalived 不但可以實現主備服務器的高可用性，同時還可以管理 LVS 實現後端服務器的負載均衡並進行後端服務器節點的健康檢查。它啓動核心進程時讀取 keepalived.conf 配置文件。在主服務器上 keepalived 進程按照配置文件配置的負載均衡策略開啓 LVS 轉發並對後端服務進行健康檢查。利用 VRRP 協議主服務器週期性的發送廣播至備服務器，備服務器將會判斷主器服務器的狀態，如果在配置的同步超時時間內主服務器節點未能發出廣播，那麼 keepalived 將啓動高可用切換機制選出新的主服務器。切換過程中，原有主服務器上的虛擬地址（VIP）及負載能力將由新的主服務器來接替承載。
1.2 HAProxy
HAProxy 是一款 TCP/HTTP 反向代理負載均衡服務器軟件，可工作在 OSI 模型中的四層傳輸層以及七層應用層。HAProxy 特別適用於那些負載壓力大的 web 站點，這些站點通常需要會話保持或七層處理。HAProxy 運行在時下的服務器上，可以支持數以萬計的併發連接。並且它的運行模式使得它可以很簡單安全地整合進現有的系統架構中，同時可以保護 web 服務器不被暴露到網絡上。HAproxy 允許用戶定義多組服務代理，代理由前端和後端組成，前端定義了服務監聽的 IP 及端口，後端則定義了一組服務器及負載均衡的算法。通過服務代理將流量由前端負載均衡至後端服務器節點上。
1.3 Keepalived 和 HAProxy 組合
由於 HAProxy 會存在單點故障問題，可以由 Keepalived 來爲 HAProxy 提供高可用服務，而 HAProxy 提供四層或七層高性能負載均衡及反向代理服務，兩者共同實現高可用負載均衡，結構如圖 1 所示。
圖 1 Keepalived+HAProxy
2. Keepalived 功能及安裝配置
2.1 核心功能
1．管理 LVS 負載均衡軟件
Keepalived 最初是專爲解決 LVS 的問題而誕生的。因此，Keepalived 和 LVS 可緊密結合。
2．實現對 LVS 集羣節點健康檢查
當 LVS 集羣中某個節點服務器發生故障時，Keepalived 服務會自動將失效的節點從正常隊列中剔除，並將請求調度到別的正常的節點服務器上，從而保證用戶訪問不受影響。當故障節點被修復後，Keepalived 服務又會自動切換回來。
3．網絡服務高可用功能
Keepalived 可以實現任意兩臺主機之間，如 Master 服務器和 Backup 服務器間的故障轉移和自動切換。假設某個服務是不能停機的，如 LVS 負載均衡、Nginx 反向代理服務器等，可以利用 Keepalived 保證其高可用性。
2.2 高可用原理
Keepalived 高可用服務的故障切換轉移是通過 VRRP 機制來實現的。在 Keepalived 服務正常運行時，Master 節點會不斷向 Backup 節點發送（多播方式）心跳信息，用以通知 Master 節點的存活狀態。當 Master 節點發生故障時，就無法發送心跳信息，Backup 節點也就無法檢測到來自 Master 的心跳信息，於是調用自身的接管程序，接管 Master 的資源和服務。當 Master 恢復時，Backup 又會釋放 Master 故障時自身接管的資源和服務，恢復到原來的備用角色。無論 Master 如何切換，對外都應該提供相同的服務 IP 地址，該 IP 也稱作虛擬地址 VIP。客戶端並不需要因 Master 的改變而修改自己的配置，對他們來說這種切換是透明的。
路由冗餘協議 VRRP（Virtual Router Redundancy Protocol）早期是用來解決交換機、路由器等設備單點故障。VRRP 通過競選機制來實現虛擬路由器的功能，所有的協議報文都是通過 IP 多播（Multicast）包形式來發送。在一組 VRRP 路由器集羣中，有多臺物理路由器，但並不是同時工作，而是由一臺 Master 路由器負責路由工作，其他都是 Backup，Master 有一些特權，比如擁有 VIP 地址等，擁有系統資源的 Master 負責轉發發送給網關地址的包和響應 ARP 請求。只有 Master 路由器會一直髮送心跳信息，此時 Backup 不會搶佔 Master。當 Master 不可用時，Backup 就收不到來自 Master 的心跳信息，此時多臺 Backup 中優先級最高的路由器會搶佔爲 Master，這種搶佔非常快速，以保證服務的連續性。
2.3 安裝與配置
由於本文引用的技術構架中 Keepalived 將僅爲 HAProxy 提供高可用服務，所以管理配置 LVS 負載均衡及節點健康檢查功能將不準備展開篇幅，僅對高可用功能進行介紹演示。
2.3.1 安裝
Keepalived 支持源碼安裝，同時也可以通過不同操作系統安裝工具進行安裝，本文以 CentOS 的 yum 工具爲例進行安裝介紹。此時應該準備兩臺服務器分別作爲 Master 節點和 Backup 節點，分別在兩臺服務器上執行以下命令進行安裝。
yum install -y keepalived
2.3.2 高可用配置
yum 安裝後，Keepalived 將生成配置文件：/etc/keepalived/keepalived.conf，可利用文本編輯器進行配置修改。
vi /etc/keepalived/keepalived.conf
配置文件中主要由全局段、VRRP 實例段、腳本段組成。
1．全局段定義（global_defs）
全局段定義允許用戶設置全局相關信息，例如通知信息、關鍵參數配置等，該段配置在 Master 節點和 Backup 節點上應當一致。
global_defs {
notification_email {
sysadmin@example.com
}
notification_email_from noreply@example.com
smtp_server 127.0.0.1
smtp_connect_timeout 60
vrrp_mcast_group4 224.0.0.18
}notification_email 定義報警郵件地址，當服務切換時發送報警郵件。notification_email_from 定義發件人信息，smtp_server 和 smtp_connect_timeout 分別定義了 SMTP 服務器及相應的連接超時時間，vrrp_mcast_group4 爲 VRRP IPv4 多播地址，默認爲 224.0.0.18，如果同一局域網內有多組 Keepalived 時需要指定不同多播地址。
2．VRRP 實例段定義（vrrp_instance）
這部分主要用來定義具體服務的實例配置，包括 Keepalived 主備狀態、接口、優先級、認證方式和 VIP 信息等, 每個 VRRP 實例可以認爲是 Keepalived 服務的一個實例或作爲一個業務服務，在一組 Keepalived 服務配置中，VRRP 實例可以有多個。
注意，存在於 Master 節點中的 VRRP 實例配置在 Backup 節點中也要有一致的配置（除了節點角色、優先級不同），這樣才能實現故障切換轉移。
vrrp_instance R1{
state MASTER
interface eth0
virtual_router_id 50
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass passwd
}
virtual_ipaddress {
10.230.137.100
}
track_script {
chk_haproxy
}
nopreempt
preempt_delay 2
}vrrp_instance 配置段定義了一個 VRRP 實例並設定實例名稱；
state 設定初始 VRRP 實例角色，配置先要爲該實例所在的 Keepalived 服務器設定其角色，在 Master 服務器上設置爲 “MASTER”，在 Backup 服務器上則設置爲 “BACKUP”；
priority 優先級設定，範圍 1-254，數字越大，表示實例優先級越高，在同一個 VRRP 實例裏，Master 節點優先級要高於 Backup 節點；
virtual_router_id 虛擬路由 ID 標識，範圍 0-255，Master 和 Backup 節點配置中相同 VRRP 實例的虛擬路由 ID 標識必須一致，否則將出現腦裂問題；
advert_int 用來同步通知間隔，Master 節點和 Backup 節點之間通信檢查的時間間隔，單位是秒。
角色相關信息設定完畢後就要開始配置 VIP 並綁定至指定的網絡接口上，在 virtual_ipaddress 中配置 VIP，可以配置多個 VIP，VIP 將綁定至 interface 參數配置的網絡接口上。
authentication 認證配置段作用於同一個 VRRP 實例的 MASTER 和 BACKUP 之前的通信，具體的配置內容有 auth_type 認證類型，auth_pass 認證密碼，認證類型有 PASS(Simple Passwd) 和 AH(IPSEC)，官方推薦 PASS，驗證密碼爲明文方式，最多 8 位。同一個 VRRP 實例的 MASTER 和 BACKUP 使用相同的密碼才能正常通信。
當添加 nopreemp 關鍵字時表示設置高可用模式爲非搶佔模式，如果去掉此關鍵字則爲默認的搶佔模式。搶佔模式是指當高優先級節點恢復後會搶佔低優先級節點成爲 MASTER，非搶佔模式允許低優先級節點繼續擔任 MASTER，preempt_delay 用來設置搶佔延遲，單位秒，範圍 0~1000，發現低優先級 MASTER 後多少秒開始搶佔。
track_script 配置段是用於調用指定腳本，腳本相關配置請參考下一節。
3．腳本段定義（vrrp_script）
默認情況下，Keepalived 僅僅在節點宕機或 Keepalived 進程停掉的時候纔會啓動切換機制。但在實際工作中，有業務服務停止而 Keepalived 服務還存在的情況，這就會導致用戶訪問的 VIP 無法找到對應的服務，這時可以利用 Keepalived 觸發預製的監測腳本，實現 VIP 漂移來繼續提供服務。
vrrp_script chk_haproxy {
script "killall -0 haproxy"
interval 2
weight -2
fall 3
rise 1
}vrrp_script 配置段定義一段腳本配置並設定腳本段名稱。script 用雙引號設置引用的 shell 語句或者 shell 腳本，通過該語句或腳本執行結果來判斷是否觸發指定動作，成功的結果不會觸發動作，執行失敗會觸發動作。interval 設置監控間隔時間，單位爲秒，weight 設置當監控腳本執行結果爲失敗時觸發 priority 值調整，正數爲增加優先級，負數爲降低優先級，範圍 - 255~255，fall 設置認定結果爲失敗時的執行失敗次數，rise 設置判定結果爲成功時的執行成功次數。
2.3.3 啓動
Keepalived 配置完成後，在 Master 節點和 Backup 節點上使用以下命令開啓 Keepalived 服務。
systemctl start keepalived
如果需要設置開機啓動，則執行以下命令。
systemctl enable keepalived
3. HAProxy 功能及安裝配置
3.1 核心功能
1．負載均衡、會話保持
在多個服務器間實現四層或七層負載均衡，支持多種負載均衡算法，並且根據 Hash 或者 cookies 方式實現會話保持。
2．健康檢查
支持 TCP、HTTP 兩種後端服務器健康檢查模式。
3．統計監控
接受訪問特定端口實現服務監控，並提供帶有用戶認證機制的服務狀態報告頁面。
4．SSL 卸載
可以解析 HTTPS 報文並將請求解密爲 HTTP 向後端服務器傳輸。
5．其他功能
在 HTTP 請求或響應報文中添加、修改、刪除首部信息；HTTP 請求重寫與重定向；根據訪問控制路由或阻斷請求。
3.2 負載均衡調度算法
HAProxy 負載均衡調度算法可以在 HAProxy 配置文件中設定。支持配置多組後端服務組，每個組可以分別指定一種調度算法。以下是 HAProxy 支持的幾種調度算法。
1．輪詢
帶有權重的輪詢調度算法。支持權重的運行時調整，支持慢啓動（在剛啓動時緩慢接收大量請求），僅支持最大 4095 個後端活動主機。
2．靜態輪詢
靜態輪詢算法，不支持權重的運行時調整及慢啓動，但後端主機數量無限制。
3．最少連接
帶權重的最少連接調度算法，將訪問請求動態調度至連接數較少的後端服務節點上。
4．源地址哈希
該算法保證在後端服務器組沒有減少或增加的情況下，能將來自同一客戶端 IP 的請求分配至同一個服務端，該算法適合在無法使用 cookie 插入的四層模式下使用。
5．URI 哈希
該算法保證訪問同一 URI 請求分配至同一服務端，適用於後端爲緩存服務器的情況，以提高緩存命中率。
6．URL 參數哈希
該算法對請求 URL 中的指定的參數的值作哈希計算。該算法適用於有用戶識別參數的 URL ，例如保證同一用戶 ID 的請求分配至同一服務節點。如果指定的參數沒有值，則降級至輪詢調度算法。
7．HTTP 首部哈希
該算法將 HTTP 首部中指定的字段取出做哈希計算。如果 HTTP 首部字段缺失，則降級至輪詢調度算法。
3.3 安裝與配置
3.3.1 安裝
HAProxy 支持源碼安裝，同時也可以通過不同操作系統安裝工具進行安裝，本文以 CentOS 的 yum 工具爲例進行安裝介紹，分別在兩臺已安裝並配置好 kkeepalived 的服務器上執行以下命令進行安裝。
yum install -y haproxy
3.3.2 基本配置
yum 安裝後，HAProxy 將生成配置文件：/etc/haproxy/haproxy.cfg，利用文本編輯器進行配置修改。
vi /etc/haproxy/haproxy.cfg
1．全局段定義（global）
全局參數配置將配置於所有 HAProxy 服務器上。
global
log /dev/log local0 info
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemonlog 設置全局日誌配置，語法爲 log ，上例中指定使用本機上的 syslog 服務中的 local0 日誌設備，記錄日誌等級爲 info 的日誌。chroot 設置 HAProxy 工作目錄，pidfile 設置 HAProxy 的 pid 文件位置，maxconn 設置每個 HAProxy 進程可用的最大連接數，user 及 group 設置 HAProxy 進程所屬的用戶及用戶組，daemon 關鍵字表示以守護進程方式運行 haproxy。
2．默認段定義（defaults）
默認段的作用是爲後續前端代理及後端代理設置默認值。
defaults
mode http
log global
option httplog
option dontlognull
option http-server-close
option forwardfor except 127.0.0.0/8
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10smode 表示 HAProxy 的工作模式，設置 tcp 時爲 4 層模式，設置 http 時爲 7 層模式。log 設置日誌輸出方式，配置爲 global 表示將採用全局段 log 的配置。
option httplog 關鍵字表示記錄 HTTP 詳細日誌，包括 HTTP 請求、session 狀態、連接數等。
option dontlognull 關鍵字表示日誌中將不會記錄空連接。所謂空連接就是在上游的負載均衡器或者監控系統爲了探測該服務是否存活可用時，需要定期的連接或者獲取某一固定的組件或頁面，或者探測掃描端口是否在監聽或開放等動作被稱爲空連接，官方文檔中標註，如果該服務上游沒有其他的負載均衡器的話，建議不要設置該參數，因爲設置後互聯網上的惡意掃描或其他動作就不會被記錄下來。
option http-server-close 關鍵字表示每次請求完畢後主動關閉 HTTP 通道。
option forwardfor 關鍵字表示應用程序想記錄發起請求的客戶端的 IP 地址，需要在 HAProxy 上配置此選項，這樣 HAProxy 會把客戶端的 IP 信息發送給服務器，在 HTTP 請求中添加 "X-Forwarded-For" 字段啓用 X-Forwarded-For，在 requests 頭部插入客戶端 IP 發送給後端的 server，使後端 server 獲取到客戶端的真實 IP。
option redispatch 關鍵字表示當使用了 cookie 時，HAProxy 將會將其請求的後端服務器信息插入到 cookie 中，以保證會話的持久性，如果後端的服務器服務不可用，但客戶端的 cookie 是不會刷新的，設置此參數會將客戶的請求強制定向到另外一個後端服務器上，以保證服務的正常。
retries 定義連接後端服務器的失敗重連次數，連接失敗次數超過此值後將會將對應後端服務器標記爲不可用。
timeout 爲前綴的關鍵字指定了一些關於請求、連接、響應的最大超時時間，單位默認爲毫秒，也可以加入後綴 s(秒)，m(分鐘)，h(小時)，d(天) 來指定。http-request 設置 HTTP 請求超時時長，queue 設置一個請求在隊列裏的超時時間，connect 設置最大與服務端建立連接的時長，client 設置客戶端最大非活動時長，server 設置服務端最大非活動時長，http-keep-alive 設置最大等待新請求的空閒時長，check 設置檢測超時時長。
3．前端代理定義（frontend）
前端代理配置定義一個服務監聽，用於接收用戶請求並將請求轉發給後端代理，可以定義多個前端代理。
frontend main
mode http
bind :80
default_backend nginxfrontend 前端代理配置段定義一組前端服務並啓動服務監聽，同時設置代理名稱。mode 設置工作模式，如果此參數未被設定則引用默認配置段配置的模式。bind 設置監聽地址及端口，地址爲空或者表示綁定至所有服務器的網絡接口。default_backend 指定默認後端代理進行流量轉發。
4．後端代理定義（backend）
用於接收前端代理請求並根據設置的負載均衡策略將流量轉發至指定後端並對後端執行健康檢查，一個前端可以指向多個後端；同時一個後端可以被多個調用。
backend nginx
mode http
balance roundrobin
server web1 host1:80 check inter 3s rise 1 fall 2
server web2 host2:80 checkbackend 後端代理配置段定義一組後端服務器，同時設置代理名稱。mode 設置工作模式如果此參數未被設定則引用默認配置段的模式。balance 設置後端負載均衡轉發策略，策略取值請參考表 1。
表 1 balance 取值
server 配置了相應的後端服務集羣地址，是真實的服務器，一個 backend 對應一個或者多個實體服務器。配置依次爲節點名稱、節點 IP 和端口、啓用四層健康檢查，在上述示例中 web1 服務器還設定了檢查的相關參數表示每 3 秒 (inter) 檢查一次，執行兩次 (fall) 失敗認爲故障，執行一次 (rise) 成功即爲服務可用。
3.3.3 啓動
HAProxy 配置完成後，使用以下命令開啓 HAProxy 服務。
systemctl start haproxy
如果需要設置開機啓動，則執行以下命令。
systemctl enable haproxy
修改配置文件後可以通過刷新配置的方式熱加載配置。
systemctl reload haproxy
3.3.4 會話保持
HAProxy 在會話保持功能上可以分爲四層會話保持和七層會話保持。四層會話保持是基於源地址的會話保持，是指 HAProxy 在負載均衡時根據訪問請求的源地址作爲判斷關聯會話的依據，對於同一 IP 地址的所有訪問請求在作負載均衡時均會被保持到後端的同一臺服務器上。七層會話保持是基於 cookie 的會話保持，當客戶端 HTTP 請求進入 HAProxy 時，根據負載均衡策略選擇後端的一臺服務器，後端服務器將 HTTP 響應返回 HAProxy，此時 HAproxy 會插入該服務器的 cookie 並將插入 cookie 的 HTTP 響應返回至客戶端，當該客戶端再次發出請求時，帶有上次插入 cookie 的 HTTP 請求進入 HAProxy，HAProxy 解析出 cookie 中服務器信息並將請求發送至相同的後端服務器。
四層會話保持的配置方式實際只需要將配置文件中後端代理段的負載均衡策略設置爲基於源地址哈希並將工作模式設置爲 tcp 即可，配置文件如下。
backend nginx
mode tcp
balance source
server web1 10.230.150.68:80 check cookie web1
server web3 10.230.150.70:80 check cookie web3七層會話保持配置方式則需要在配置文件後端代理段中設置 cookie 並確保工作模式爲 http，配置文件如下。
backend nginx
mode http
balance roundrobin
cookie WEBSRV insert indirect nocache
server web1 10.230.150.68:80 check cookie web1
server web3 10.230.150.70:80 check cookie web3以上配置文件中的 cookie 設置了以 WEBSRV 爲名稱的 cookie，然後在 server 配置中分別定義了不同的 cookie 值，通過瀏覽器訪問 HAProxy 前端代理地址可以看到該 cookie，利用該 cookie 實現會話保持，如圖 2 所示。
圖 2 cookie 信息
3.3.5 SSL 卸載
利用 HAProxy 可以實現 SSL 卸載功能，從而使客戶端到 HAProxy 的訪問採用 SSL 封裝後的 HTTPS，而 HAProxy 至後端服務器之間的通信則採用 HTTP（圖 3），從而消除服務器端的 SSL 加密運算開銷。
圖 3 SSL 卸載
實現 SSL 卸載需要在配置文件全局定義段加入 SSL 參數調整，以及在前端代理段加入 SSL 配置，涉及的配置如下。
global
maxconn 20000
log 127.0.0.1 local0 info
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
user haproxy
group haproxy
daemon
tune.ssl.default-dh-param 2048
stats socket /var/lib/haproxy/stats
frontend main
bind :80
bind :443 ssl crt /etc/ssl/certs/web.pem
redirect scheme https if !{ ssl_fc }
default_backend nginx全局段配置中增加了 SSL 參數 tune.ssl.default-dh-param，設置值爲 2048，表示使用 2048bit 加密，和 SSL 祕鑰加密位數保持一致。
前端代理配置 bind 加入 443 端口、SSL 支持並綁定指定證書，證書文件內容爲網站的證書和私鑰通過命令（cat web.crt web.key | tee web.pem）拼接合成。配置段中還加入了 HTTP 到 HTTPS 的自動跳轉功能（redirect scheme https if !{ssl_fc}），在瀏覽器中輸入域名或者 IP 地址，無需指定協議類型，如果導入根證書後的瀏覽器顯示的狀態是安全的則表示配置成功（圖 4）。
圖 4 開啓 HTTPS
3.3.6 流量路由
HAProxy 可以爲數據庫、郵件、頁面等服務提供四層負載均衡機制，也可以從 HTTP 請求報文中提取指定數據並通過特定的訪問控制列表（ACL）提供基於七層的流量轉發機制。
1．基於 URL 路徑轉發。HAProxy 可以根據請求的 URL 路徑做路由，通過配置不同的路徑將不同的 URL 路徑分發至不同的後端服務器，在以下的例子中我們在兩個頁面服務器上分別配置了兩個測試頁面 test1.html、test2.html，頁面內容簡單標識了所在服務器的信息，並利用轉發機制實現基於 URL 的路徑分發，涉及的相關配置如下。
frontend main
bind :80
bind :443 ssl crt /etc/ssl/certs/web.pem
redirect scheme https if !{ ssl_fc }
acl is_test1 path_beg /test1
acl is_test2 path_beg /test2
use_backend test1 if is_test1
use_backend test2 if is_test2
default_backend nginx
backend nginx
balance roundrobin
server web1 10.230.150.68:80 check
backend test1
balance roundrobin
server web2 10.230.150.69:80 check
backend test2
balance roundrobin
server web3 10.230.150.70:80 check前端代理配置段中加入 acl 配置，設置的路由規則爲匹配路徑的前綴（path_beg）test1 及 test2，並配置 use_backend 參數將指定 acl 作用於指定後端服務器，is_test1 規則匹配後路由至 test1，is_test2 規則匹配後路由至 test2。
定義兩組後端代理配置，分別配置 test1 及 test2 後端代理，指向相應的頁面服務器。通過訪問不同的路徑 HAProxy 可以正確路由轉發到指定後端頁面服務器，沒有命中 acl 的請求將轉發至默認後端服務器，如圖 5 所示。
圖 5 URL 路徑轉發
2．基於 HTTP 首部信息轉發。HAProxy 可以根據 HTTP 首部信息來執行路由分發操作，例如通過首部信息中的 User-Agent 來判斷請求方的設備類型是 iPhone 還是 Android，以此作爲依據進行路由分發至不同的後端服務器上，或者通過首部信息中的 Host 字段實現以域名爲依據進行路由分發。以 Host 爲例，涉及的相關配置如下。
frontend main
bind :80
bind :443 ssl crt /etc/ssl/certs/web.pem
redirect scheme https if !{ ssl_fc }
acl is_test1 hdr_beg(host) www.test1.com
acl is_test2 hdr_beg(host) www.test2.com
use_backend test1 if is_test1
use_backend test2 if is_test2
default_backend nginx
backend nginx
balance roundrobin
cookie WEBSRV insert indirect nocache
server web1 10.230.150.68:80 check cookie web1
backend test1
balance roundrobin
server web2 10.230.150.69:80 check
backend test2
balance roundrobin
server web2 10.230.150.70:80 check前端代理配置段中加入 acl 配置，通過 hdr_beg(host) 關鍵字設置的路由規則匹配 HTTP 首部信息中 Host 前綴 www.test1.com 及 www.test2.com，並配置 use_backend 參數將指定 acl 作用於指定後端服務器，is_test1 規則匹配後路由至 test1，is_test2 規則匹配後路由至 test2。
定義兩組後端代理配置，分別配置 test1 及 test2 後端代理，指向相應的頁面服務器。通過不同的域名訪問可以正確路由轉發到指定後端頁面服務器，沒有命中 acl 的請求將轉發至默認後端服務器，如圖 6 所示。
圖 6 域名轉發
4. 總結
負載均衡可以由專業硬件設備提供，由服務器集羣服務節點之上架設專業負載均衡器來完成集羣節點的負載均衡工作。硬件負載均衡優勢明顯，設備獨立於操作系統、強大的性能、豐富的功能、多樣化的負載均衡策略、智能化流量管理，由專業維護團隊提供維護，缺點是價格昂貴、配置複雜，部署難度大時間長，不適於中小規模的網絡服務。
軟負載則在一臺或多臺服務器操作系統之上安裝附加軟件來實現負載均衡。採用軟負載方案後系統構架內無需額外部署專用於負載均衡的硬件設備以降低成本，同時能夠更好地根據系統與應用的狀態來分配負載，無縫的嵌入系統架構中，也可以根據實際需求靈活擴展，互聯網公司大多都有自己的軟負載方案。相比硬件負載來說軟件負載具有配置簡單、快速部署、使用靈活、成本低廉、高性價比等諸多優勢。
在建設某銀行應用基礎雲 PaaS 平臺的實踐中，採用 Keepalived+HAproxy 組合搭建了高可用軟負載方案，爲平臺內多組控制節點、多組工作節點、以及雙副本鏡像倉庫提供服務接口聚合負載和高可用性保障。首先，平臺的業務流量入口指向 Keepalived 高可用 VIP 地址，經過 Haproxy 負載調度至後端工作節點中，這樣一旦其中任意一個負載均衡節點或者後端工作節點宕機，高可用 VIP 地址和剩餘存活的後端工作節點仍可對外提供服務。其次，隨着後期業務流量的上升，後端工作節點出現負載壓力時，可以根據實際需要靈活配置 Haproxy，擴展後端工作節點數量，降低整體工作節點負載壓力。從現有的實踐經驗來看，該軟負載方案具備了良好的穩定性、靈活性和可擴展性。
原文鏈接：https://zhuanlan.zhihu.com/p/420031058
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/MqkmFdnmrA6TLzTVNWRE0A