2.1.3 負載均衡架構設計

負載均衡架構是一種應用較為廣泛的高可用手段，可以快速地為其他服務提供水平擴展能力。

1.什么是負載均衡架構？

如圖2-4所示，無冗余結構服務端發生故障時，會直接導致系統無法訪問；而使用負載均衡冗余結構，一個服務端發生故障后，依然有一個節點可以對外提供服務。如果服務端的壓力過大，則可以通過增加多個服務節點來分擔系統壓力，這也是提高系統并發能力的直接手段。

負載設備可以使用硬件或軟件實現，因此負載均衡可以分為硬負載（硬件設備）和軟負載（軟件）兩種。硬負載主要使用F5、Radware等硬件設備，軟負載主要使用Nginx、LVS、HAProxy等軟件。

硬負載具有性能高、穩定性強的特點，但是價格昂貴，而且不利于開發人員維護。軟負載具有靈活性強，易于配置的特點，但是由于軟負載工具運行在操作系統之上，所以性能和穩定性受操作系統限制，相較于硬負載要略差一些。

2.負載均衡高可用方案

這種架構方式雖然解決了服務端的單節點風險，但是負載設備本身又變為了單節點。下面介紹幾種常用的負載均衡高可用方案。

（1）Nginx+Keepalive雙機主備方案。

如圖2-5所示，部署主備兩臺Nginx服務器，它們各自都有自己的IP地址（10.1.8.3和10.1.8.4），在兩臺服務器上分別安裝Keepalive服務，并綁定同一個虛擬IP（Virtual IP，VIP）地址（10.1.8.8），此IP地址要求沒有被占用，客戶端訪問時通過VIP進行訪問。

當主節點存活時，請求將發送至主節點處理。當主節點宕機后，VIP會自動漂移到備份節點，由備機接管負載服務，成為新的主機，從而達到主備自動切換，具備自動故障轉移的能力。當故障節點恢復后，這個新的主機自動變為備機使用。

雙機主備需要注意時刻保持主備Nginx的配置完全相同，避免發生系統切換后，服務無法正常使用的情況。

（2）F5+LVS/HAProxy+Nginx多級負載方案。

Nginx+Keepalive的方案雖然可以保證Nginx的高可用，但缺點是只能由一個節點對外服務，單個節點的Nginx連接數和服務能力有限，如果想對Nginx進行水平擴展就無法滿足。

可以使用開源免費的LVS或HAProxy+Nginx形成二級負載結構，從而讓Nginx支持水平擴展，支持超高并發請求。LVS和HAProxy都可以使用Keepalive搭建雙機主備高可用模式，如圖2-6所示。

也可以使用硬負載+LVS/HAProxy+Nginx形成三級負載結構，從而讓LVS/HAProxy也支持水平擴展，并發能力將再上升一個數量級。F5和Radware可以搭建雙機主備模式，保證高可用，如圖2-7所示。

3.四層與七層負載

LVS和HAProxy的性能比Nginx強很多，因為LVS和HAProxy專門用于四層負載，而Nginx多用于七層負載（新版本Nginx可以通過添加Stream模塊，支持四層負載）。

LVS和HAProxy工作在第4層，而Nginx可以工作在第4層和第7層，如圖2-8所示。

LVS和HAProxy更接近于操作系統底層，使用IP加端口的方式進行路由負載，讓客戶端和上游服務器直接建立通信，通過TCP、UDP的請求報文頭中的IP地址或MAC地址，來達到轉發的目的，對網絡性能幾乎無損耗。

使用Nginx的七層負載時，當客戶端要與服務器建立連接時，必須先和Nginx建立連接，然后Nginx再和上游服務器建立連接，所有的請求和應答都由Nginx先接收再轉發出去，所以存在一定的網絡和性能損耗，對CPU和內存資源損耗較大，如圖2-9所示。

LVS和HAProxy可以工作在四層網絡之上，當客戶端發起請求后，LVS/HAProxy會將請求報文的IP和端口直接修改為上游服務器的IP和端口，讓客戶端和服務器直接建立連接，因此幾乎不占用流量，對CPU和內存的消耗微乎其微，從而才具有更高的性能，如圖2-10所示。

4.既然LVS和HAProxy這么強大，為什么還要使用Nginx呢？

由于LVS和HAProxy工作在四層網絡之上，功能也比較單一，只負責請求分發，因此流量本身并不穿過它們。不支持URL路徑匹配，不能做動靜分離，可配置性不強。由于更接近于操作系統和網絡層面，所以一般開發人員難以配置，需要專門的運維人員負責。

Nginx工作在七層網絡之上，可以作為靜態資源服務器、文件服務器，支持POP、SMTP協議，支持HTTP緩存、URL路徑匹配，在服務器配置較好的情況下，也能夠承載單機2萬以上的并發，穩定性很好，配置文件簡單、語法友好，開發人員可以直接配置。同時，插件眾多，社區活躍度較高，通過插件可支持TCP反向代理、訪問限流等功能。基于以上原因，Nginx具有極高的市場覆蓋率。當然，LVS、HAProxy、Nginx都在不斷地發展，未來功能差異可能會進一步縮小。

F5、Radware等硬負載設備，也是工作在四層網絡之上，借助獨立硬件的能力，性能最為出眾，但是價格也十分高昂。

5.負載策略

客戶端請求到達負載設備，需要根據一定的算法決定分發給哪一個上游服務器，這個分發算法就是負載策略，如圖2-11所示。

對于不同的負載軟件，支持的負載策略稍有差異，但是大體相同，有如下10種。

（1）輪詢策略：請求被依次循環分發給上游服務器，一般屬于默認策略，最常用。

（2）權重輪詢策略：可以設置權重，權重越大，分發的請求越多，配置高的服務器權重應該大一些，配置低的服務器權重應該小一些。例如，如果設置4:1的權重，則配置高的服務器會收到4次請求，配置低的服務器會收到1次請求。

（3）動態權重策略：請求分發交由系統控制，負載均衡器會收集每個上游服務器的狀態，如CPU、內存、磁盤I/O、繁忙程度等各項指標，從而計算出權重，給相對空閑的服務器分發更多請求，給繁忙的服務器分發少量請求。

（4）最小連接數策略：由于所有的連接都經過負載設備，所以它可以統計出每個上游服務器的連接數情況，每次都將請求轉發給連接數最小的服務器。

（5）最短響應時長策略：將請求分發給響應時間最短的服務器。

（6）IP哈希策略：將相同來源IP的請求轉發到同一個上游服務器，可用于Session保持等場景。

（7）URL哈希策略：與IP哈希策略類似，使用請求URL進行哈希計算，將相同哈希值的請求轉發到相同的上游服務器。

（8）最小會話策略：根據當前的Session保持情況，將請求分發給會話最小的服務器。

（9）趨勢分析策略：根據一段時間內的請求分發情況、連接數、會話、服務器狀態等信息判斷出每個上游服務器未來的流量上升和下降趨勢，將請求轉發給趨勢上升的服務器。

（10）隨機策略：將請求隨機分發給某一個上游服務器。