很全！淺談幾種經常使用負載均衡架構

時間 2019-12-05

標籤淺談幾種經常使用負載均衡架構欄目負載均衡简体版

原文原文鏈接

閱讀本文大概須要 9 分鐘。

做者：Kingreatwill
連接：http://t.cn/Ea8JcrS前端

什麼是負載均衡（Load balancing）程序員

在網站創立初期，咱們通常都使用單臺機器對臺提供集中式服務，但隨着業務量愈來愈大，不管性能仍是穩定性上都有了更大的挑戰。web

這時候咱們就會想到經過擴容的方式來提供更好的服務。咱們通常會把多臺機器組成一個集羣對外提供服務。算法

然而，咱們的網站對外提供的訪問入口都是一個的，好比www.taobao.com。數據庫

那麼當用戶在瀏覽器輸入 www.taobao.com 的時候如何將用戶的請求分發到集羣中不一樣的機器上呢，這就是負載均衡在作的事情。windows

當前大多數的互聯網系統都使用了服務器集羣技術，集羣即將相同服務部署在多臺服務器上構成一個集羣總體對外提供服務，這些集羣能夠是 Web 應用服務器集羣，也能夠是數據庫服務器集羣，還能夠是分佈式緩存服務器集羣等。後端

在實際應用中，在 Web 服務器集羣以前總會有一臺負載均衡服務器，負載均衡設備的任務就是做爲 Web 服務器流量的入口，挑選最合適的一臺 Web 服務器，將客戶端的請求轉發給它處理，實現客戶端到真實服務端的透明轉發。瀏覽器

最近幾年很火的「雲計算」以及分佈式架構，本質上也是將後端服務器做爲計算資源、存儲資源，由某臺管理服務器封裝成一個服務對外提供，客戶端不須要關心真正提供服務的是哪臺機器，在它看來，就好像它面對的是一臺擁有近乎無限能力的服務器，而本質上，真正提供服務的是後端的集羣。
緩存

軟件負載解決的兩個核心問題是：選誰、轉發，其中最著名的是 LVS（Linux Virtual Server）。安全

一個典型的互聯網應用的拓撲結構是這樣的：

負載均衡分類

如今咱們知道，負載均衡就是一種計算機網絡技術，用來在多個計算機（計算機集羣）、網絡鏈接、CPU、磁碟驅動器或其它資源中分配負載，以達到最佳化資源使用、最大化吞吐率、最小化響應時間、同時避免過載的目的。

那麼，這種計算機技術的實現方式有多種。

大體能夠分爲如下幾種，其中最經常使用的是四層和七層負載均衡：

二層負載均衡

負載均衡服務器對外依然提供一個 VIP（虛IP），集羣中不一樣的機器採用相同 IP地址，但機器的 MAC 地址不同。

當負載均衡服務器接受到請求以後，經過改寫報文的目標 MAC 地址的方式將請求轉發到目標機器實現負載均衡。

三層負載均衡

和二層負載均衡相似，負載均衡服務器對外依然提供一個 VIP（虛IP），但集羣中不一樣的機器採用不一樣的 IP 地址。

當負載均衡服務器接受到請求以後，根據不一樣的負載均衡算法，經過 IP 將請求轉發至不一樣的真實服務器。

四層負載均衡

四層負載均衡工做在 OSI 模型的傳輸層，因爲在傳輸層，只有 TCP/UDP 協議，這兩種協議中除了包含源 IP、目標 IP 之外，還包含源端口號及目的端口號。

四層負載均衡服務器在接受到客戶端請求後，之後經過修改數據包的地址信息（ IP+端口號）將流量轉發到應用服務器。

七層負載均衡

七層負載均衡工做在 OSI 模型的應用層，應用層協議較多，經常使用 HTTP、Radius、DNS 等。七層負載就能夠基於這些協議來負載。

這些應用層協議中會包含不少有意義的內容。

好比同一個 Web 服務器的負載均衡，除了根據 IP 加端口進行負載外，還可根據七層的 URL、瀏覽器類別、語言來決定是否要進行負載均衡。

圖：四層和七層負載均衡

對於通常的應用來講，有了 Nginx 就夠了。

Nginx 能夠用於七層負載均衡。

可是對於一些大的網站，通常會採用 DNS+四層負載+七層負載的方式進行多層次負載均衡。

經常使用負載均衡工具

硬件負載均衡性能優越，功能全面，但價格昂貴，通常適合初期或者土豪級公司長期使用。

所以軟件負載均衡在互聯網領域大量使用。經常使用的軟件負載均衡軟件有 Nginx、LVS、HaProxy 等。

Nginx/LVS/HAProxy 是目前使用最普遍的三種負載均衡軟件。

一、 LVS

LVS（Linux Virtual Server），也就是 Linux 虛擬服務器，是一個由章文嵩博士發起的自由軟件項目。

使用 LVS 技術要達到的目標是：經過 LVS 提供的負載均衡技術和 Linux 操做系統實現一個高性能、高可用的服務器羣集，它具備良好可靠性、可擴展性和可操做性。

從而以低廉的成本實現最優的服務性能。

LVS 主要用來作四層負載均衡。

LVS 架構

LVS 架設的服務器集羣系統由三個部分組成：最前端的負載均衡層（Loader Balancer），中間的服務器羣組層，用 Server Array 表示，最底層的數據共享存儲層，用 Shared Storage 表示。

在用戶看來全部的應用都是透明的，用戶只是在使用一個虛擬服務器提供的高性能服務。

LVS 的各個層次的詳細介紹：

Load Balancer 層：位於整個集羣系統的最前端，有一臺或者多臺負載調度器（Director Server）組成，LVS 模塊就安裝在 Director Server上，而 Director 的主要做用相似於一個路由器，它含有完成 LVS 功能所設定的路由表，經過這些路由表把用戶的請求分發給 Server Array 層的應用服務器（Real Server）上。

同時，在 Director Server 上還要安裝對 Real Server 服務的監控模塊 Ldirectord，此模塊用於監測各個 Real Server 服務的健康情況。在 Real Server 不可用時把它從 LVS 路由表中剔除，恢復時從新加入。

Server Array 層：由一組實際運行應用服務的機器組成，Real Server 能夠是 Web 服務器、Mail 服務器、FTP 服務器、DNS 服務器、視頻服務器中的一個或者多個，每一個 Real Server 之間經過高速的 LAN 或分佈在各地的 WAN 相鏈接。

在實際的應用中，Director Server 也能夠同時兼任 Real Server 的角色。

Shared Storage 層：是爲全部 Real Server 提供共享存儲空間和內容一致性的存儲區域，在物理上通常由磁盤陣列設備組成，爲了提供內容的一致性，通常能夠經過 NFS 網絡文件系統共享數據，但 NFS 在繁忙的業務系統中，性能並非很好，此時能夠採用集羣文件系統，例如 Redhat 的 GFS 文件系統、Oracle 提供的 OCFS2 文件系統等。

從整個 LVS 結構能夠看出，Director Server 是整個 LVS 的核心，目前用於 Director Server 的操做系統只能是 Linux 和 FreeBSD，Linux 2.6 內核不用任何設置就能夠支持 LVS 功能，而 FreeBSD 做爲 Director Server 的應用還不是不少，性能也不是很好。

對於 Real Server，幾乎能夠是全部的系統平臺，Linux、windows、Solaris、AIX、BSD 系列都能很好地支持。

二、Nginx

Nginx（發音同 engine x）是一個網頁服務器，它能反向代理 HTTP、HTTPS,、SMTP、POP三、IMAP的協議連接，以及一個負載均衡器和一個HTTP緩存。

Nginx 主要用來作七層負載均衡。

併發性能：官方支持每秒 5 萬併發，實際國內通常到每秒 2 萬併發，有優化到每秒 10 萬併發的。具體性能看應用場景。

特色：

模塊化設計：良好的擴展性，能夠經過模塊方式進行功能擴展。
高可靠性：主控進程和 worker 是同步實現的，一個 worker 出現問題，會馬上啓動另外一個 worker。
內存消耗低：一萬個長鏈接（keep-alive）,僅消耗 2.5 MB 內存。
支持熱部署：不用中止服務器，實現更新配置文件，更換日誌文件、更新服務器程序版本。
併發能力強：官方數據每秒支持 5 萬併發；
功能豐富：優秀的反向代理功能和靈活的負載均衡策略

Nginx 的基本工做模式

一個 master 進程，生成一個或者多個 worker 進程。但這裏 master 是使用 root 身份啓動的，由於 Nginx 要工做在 80 端口。而只有管理員纔有權限啓動小於低於 1023 的端口。

master 主要是負責的做用只是啓動 worker，加載配置文件，負責系統的平滑升級。其它的工做是交給 worker。

那當 worker 被啓動以後，也只是負責一些 web 最簡單的工做，而其它的工做都是由 worker 中調用的模塊來實現的。

模塊之間是以流水線的方式實現功能的。流水線，指的是一個用戶請求，由多個模塊組合各自的功能依次實現完成的。

好比：第一個模塊只負責分析請求首部，第二個模塊只負責查找數據，第三個模塊只負責壓縮數據，依次完成各自工做。來實現整個工做的完成。

它們是如何實現熱部署的呢？是這樣的，咱們前面說 master 不負責具體的工做，而是調用 worker 工做，它只是負責讀取配置文件，所以當一個模塊修改或者配置文件發生變化，是由 master 進行讀取，所以此時不會影響到 worker 工做。

在 master 進行讀取配置文件以後，不會當即把修改的配置文件告知 worker 。而是讓被修改的 worker 繼續使用老的配置文件工做，當 worker 工做完畢以後，直接當掉這個子進程，更換新的子進程，使用新的規則。

三、HAProxy

HAProxy 也是使用較多的一款負載均衡軟件。HAProxy 提供高可用性、負載均衡以及基於 TCP 和 HTTP 應用的代理，支持虛擬主機，是免費、快速而且可靠的一種解決方案。

特別適用於那些負載特大的 Web站點。運行模式使得它能夠很簡單安全的整合到當前的架構中，同時能夠保護你的web服務器不被暴露到網絡上。

HAProxy 是一個使用 C 語言編寫的自由及開放源代碼軟件，其提供高可用性、負載均衡，以及基於 TCP 和 HTTP 的應用程序代理。
Haproxy 主要用來作七層負載均衡。

常見負載均衡算法

上面介紹負載均衡技術的時候提到過，負載均衡服務器在決定將請求轉發到具體哪臺真實服務器時，是經過負載均衡算法來實現的。

負載均衡算法能夠分爲兩類：靜態負載均衡算法和動態負載均衡算法。

靜態負載均衡算法包括：輪詢、比率、優先權。
動態負載均衡算法包括：最少鏈接數、最快響應速度、觀察方法、預測法、動態性能分配、動態服務器補充、服務質量、服務類型、規則模式。

輪詢（Round Robin）：順序循環將請求一次順序循環地鏈接每一個服務器。當其中某個服務器發生第二到第 7 層的故障，BIG-IP 就把其從順序循環隊列中拿出，不參加下一次的輪詢，直到其恢復正常。

以輪詢的方式依次請求調度不一樣的服務器；實現時，通常爲服務器帶上權重；這樣有兩個好處：針對服務器的性能差別可分配不一樣的負載；當須要將某個結點剔除時，只須要將其權重設置爲0便可；

優勢：實現簡單、高效；易水平擴展
缺點：請求到目的結點的不肯定，形成其沒法適用於有寫的場景（緩存，數據庫寫）
應用場景：數據庫或應用服務層中只有讀的場景

隨機方式：請求隨機分佈到各個結點；在數據足夠大的場景能達到一個均衡分佈；

優勢：實現簡單、易水平擴展
缺點：同 Round Robin，沒法用於有寫的場景
應用場景：數據庫負載均衡，也是隻有讀的場景

哈希方式：根據 key 來計算須要落在的結點上，能夠保證一個同一個鍵必定落在相同的服務器上；

優勢：相同 key 必定落在同一個結點上，這樣就可用於有寫有讀的緩存場景
缺點：在某個結點故障後，會致使哈希鍵從新分佈，形成命中率大幅度降低
解決：一致性哈希 or 使用 keepalived 保證任何一個結點的高可用性，故障後會有其它結點頂上來
應用場景：緩存，有讀有寫

一致性哈希：在服務器一個結點出現故障時，受影響的只有這個結點上的 key，最大程度的保證命中率；如 twemproxy 中的 ketama方案；生產實現中還能夠規劃指定子 key 哈希，從而保證局部類似特徵的鍵能分佈在同一個服務器上；

優勢：結點故障後命中率降低有限
應用場景：緩存

根據鍵的範圍來負載：根據鍵的範圍來負載，前 1 億個鍵都存放到第一個服務器，1~2 億在第二個結點。

優勢：水平擴展容易，存儲不夠用時，加服務器存放後續新增數據
缺點：負載不均；數據庫的分佈不均衡；
（數據有冷熱區分，通常最近註冊的用戶更加活躍，這樣形成後續的服務器很是繁忙，而前期的結點空閒不少）
適用場景：數據庫分片負載均衡

根據鍵對服務器結點數取模來負載：根據鍵對服務器結點數取模來負載；好比有 4 臺服務器，key 取模爲 0 的落在第一個結點，1 落在第二個結點上。

優勢：數據冷熱分佈均衡，數據庫結點負載均衡分佈；
缺點：水平擴展較難；
適用場景：數據庫分片負載均衡

純動態結點負載均衡：根據 CPU、IO、網絡的處理能力來決策接下來的請求如何調度。

優勢：充分利用服務器的資源，保證個結點上負載處理均衡
缺點：實現起來複雜，真實使用較少

不用主動負載均衡：使用消息隊列轉爲異步模型，將負載均衡的問題消滅；負載均衡是一種推模型，一直向你發數據，那麼將全部的用戶請求發到消息隊列中，全部的下游結點誰空閒，誰上來取數據處理；轉爲拉模型以後，消除了對下行結點負載的問題。

優勢：經過消息隊列的緩衝，保護後端系統，請求劇增時不會沖垮後端服務器；水平擴展容易，加入新結點後，直接取 queue 便可；
缺點：不具備實時性；
應用場景：不須要實時返回的場景；好比，12036 下訂單後，馬上返回提示信息：您的訂單進去排隊了...等處理完畢後，再異步通知；

比率（Ratio）：給每一個服務器分配一個加權值爲比例，根椐這個比例，把用戶的請求分配到每一個服務器。當其中某個服務器發生第 2 到第 7 層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

優先權（Priority）：給全部服務器分組，給每一個組定義優先權，BIG-IP 用戶的請求，分配給優先級最高的服務器組（在同一組內，採用輪詢或比率算法，分配用戶的請求）；當最高優先級中全部服務器出現故障，BIG-IP 纔將請求送給次優先級的服務器組。這種方式，實際爲用戶提供一種熱備份的方式。

最少的鏈接方式（Least Connection）：傳遞新的鏈接給那些進行最少鏈接處理的服務器。當其中某個服務器發生第 2 到第 7 層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

最快模式（Fastest）：傳遞鏈接給那些響應最快的服務器。當其中某個服務器發生第二到第7 層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

觀察模式（Observed）：鏈接數目和響應時間以這兩項的最佳平衡爲依據爲新的請求選擇服務器。當其中某個服務器發生第二到第 7 層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

預測模式（Predictive）：BIG-IP 利用收集到的服務器當前的性能指標，進行預測分析，選擇一臺服務器在下一個時間片內，其性能將達到最佳的服務器相應用戶的請求。(被 BIG-IP 進行檢測)

動態性能分配(Dynamic Ratio-APM):BIG-IP 收集到的應用程序和應用服務器的各項性能參數，動態調整流量分配。

動態服務器補充(Dynamic Server Act.):當主服務器羣中因故障致使數量減小時，動態地將備份服務器補充至主服務器羣。

服務質量(QoS）:按不一樣的優先級對數據流進行分配。

服務類型(ToS): 按不一樣的服務類型（在 Type of Field 中標識）負載均衡對數據流進行分配。

規則模式：針對不一樣的數據流設置導向規則，用戶可自行。

·END·

程序員的成長之路

路雖遠，行則必至