【摘要】負載均衡是分布式系統中不可或缺的重要環節，通過負載均衡按照指定的調度算法將請求分發至網絡中多個節點進行處理。本文將介紹基於開源軟體HAProxy實現負載均衡並且通過Keepalived實現高可用的配置方法，希望讀者通過參考本文的探索成果可以快速實現高可用的軟體負載均衡，也希望讀者能夠舉一反三、觸類旁通，通過自我驅動進行更深入的研究來配置更多的功能來滿足自身需求。
【作者】某銀行系統支持部 鄭宇光
【來源】talkwithtrend
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
daemon
log設置全局日誌配置，語法為log <address> <facility> <msglevel>，上例中指定使用本機上的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 10s
mode表示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 nginx
frontend前端代理配置段定義一組前端服務並啟動服務監聽，同時設置代理名稱。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 check
backend後端代理配置段定義一組後端伺服器，同時設置代理名稱。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，擴展後端工作節點數量，降低整體工作節點負載壓力。從現有的實踐經驗來看，該軟負載方案具備了良好的穩定性、靈活性和可擴展性。
原題：Keepalived+HAProxy 實現高可用負載均衡申明：感謝原創作者的辛勤付出。本號轉載的文章均會在文中註明，若遇到版權問題請我們聯繫我們處理。
更多架構師技術關知識請參考「架構師技術全店資料打包匯總(全)」電子書(32本技術資料打包匯總、詳解目錄和內容請通過「閱讀原文」獲取)。
溫馨提示：
請識別二維碼關注公眾號，點擊原文連結獲取「架構師技術全店資料打包匯總(全)」電子書資料詳情。