架構設計：負載均衡層設計方案（8）——負載均衡層總結上篇

一、概述

很明顯經過前面的八篇文章的介紹，並不能覆蓋負載均衡層的全部技術，可是能夠做爲一個引子，告訴各位讀者一個學習和使用負載均衡技術的思路。雖而後面咱們將轉向「業務層」和「業務通訊」層的介紹，可是對負載均衡層的介紹也不會中止。在後續的時間咱們將穿插進行負載均衡層的新文章的發佈，包括Nginx技術的再介紹、HaProxy、LVS新的使用場景等等。

這篇文章咱們對前面的知識點進行總結，並有意進行一些擴展，以便於各位讀者找到新的學習思路。

二、負載均衡層的核心思想

2-一、一致性哈希與Key的選取

在《架構設計：負載均衡層設計方案（2）——Nginx安裝》 文章中咱們詳細介紹了一致性哈希算法。而且強調了一致性Hash算法是現代系統架構中的最關鍵算法之一，在分佈式計算系統、分佈式存儲系統、數據分析等衆多領域中普遍應用。針對個人博文，在負載均衡層、業務通訊層、數據存儲層都會有它的身影。

一致性算法的核心是：

• 使用對象的某一個屬性（這個屬性能夠是服務器的IP地址、開放端口 還能夠是用戶名、某種加密串。凡是你能夠想到的有散列意義的屬性），算出一個整數，讓其分佈在0 至 2的32次方 範圍內。
• 一臺服務器的某個或者某一些屬性固然也能夠進行hash計算，而且根據計算分佈在這個圓環上的某一個點，也就是圖中圓環上的藍色點。
• 一個處理請求到來時，根據這個請求的某一個或者某一些屬性進行hash計算，而且根據計算記過度布在這個圓環上的某一個點上。也就是上圖圓環上的黃色點。
• 咱們約定落在某一個藍點A左側和藍點B右側的黃色點所表明的請求，都有藍點A所表明的服務器進行處理，這樣就完成解決了「誰來處理」的問題。在藍色點穩定存在的前提下，來自於同一個Hash約定的請求所落在的位置都是同樣的，這就保證了服務處理映射的穩定性。
• 當某一個藍色點因爲某種緣由下線，其所影響到的黃色點也是有限的。即下一次客戶端的請求將由其餘的藍色點所表明的服務器進行處理。

2-二、輪詢與權

• 不加權輪詢，就是主控節點（任務來源點）在不考慮目標節點的任何因素的狀況下（例如CPU性能、磁盤性能、網絡性能），按照目標節點的列表順序將任務依次分配下去。這是最簡單的輪詢，也是對主控節點實現複雜性要求最低的輪詢。我以前的博文《架構設計：負載均衡層設計方案（2）——Nginx安裝》、《架構設計：負載均衡層設計方案（4）——LVS原理》 都對這種最簡輪詢進行了介紹：例如LVS中的「rr」參數。

• 加權輪詢中的「權」，您能夠當作是「輪詢」依據的意思。「權」能夠是不少種可能，能夠是目標機器的性能量化值、能夠是一個固定的數字（按照固定數字加權）、能夠是目標節點的網絡速度。例如LVS中的「lc」參數，就是指按照目標機器，如今已有的「鏈接」數量進行加權：鏈接數量越少，越有更大的概率得到這個任務的處理權。

2-三、租約與健康檢查

租約協議主要爲了保證一個事實：若是服務器對客戶端的檢查操做在「最遲時間」失敗後，那麼服務器端確定會註銷客戶端的登陸信息，同時客戶端上服務器的鏈接信息也會消失（而且不在向下提供服務）。每一次檢查成功，這個「最遲時間」都會向後推移。

租約協議和咱們提到的哈希算法一下同樣，也是系統架構設計中最基本的設計思想，而且大量運用在各種型的系統中，它的工做原理是每一位架構師都須要掌握的。例如：zookeeper使用這個協議保證Flow節點和Leader節點的鏈路是正常的；分佈式存儲系統用這個協議保證datanode和namenode的鏈接是正常的；

三、負載均衡層技術彙總

在前面的博文中，我重點介紹了Nginx、LVS、Keepalived技術。因爲時間有限，這裏咱們對博文中提到的幾種技術進行一個總結，而後再擴展介紹一下DNS技術、CDN技術和硬件負載技術。

3-一、Nginx技術

在負載均衡層這個大的章節中，我有三篇文章都在直接介紹Nginx的原理和使用。可是以後有朋友給我反映還想了解更多的Nginx知識，特別點名要求我再作一篇文章介紹Nginx的動態緩存。是的，我在後面的時間裏是有計劃介紹Nginx的動態緩存技術，還會介紹Nginx和多款主流的反向代理軟件的性能對比。但這須要時間，特別是我不想去網上找一些已有的性能對比圖，仍是本身一邊作這樣的性能測試，一邊作性能報告比較靠譜。

下面這些技術是我在博文中已經重點介紹過得，咱們再作一下總結：

• Nginx中的鏈接數限制問題

重要的配置項包括：worker_processes、worker_connections。可是光是配置這些屬性是不夠的，最關鍵的是咱們要打開操做系統級別的「最大文件數」限制問題。使用「ulimit -n 65535」設置本次會話的「最大文件數」限制；還要使用「vim /etc/security/limits.conf」命令，修改內核的配置信息。主要是如下兩項：

* soft nofile 65535 * hard nofile 65535

• 1
• 2

• 1
• 2

另外，還要注意和nginx配置項中的「worker_rlimit_nofile」屬性共同使用：

user root root; 
worker_processes 4; worker_rlimit_nofile 65535; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; events { use epoll; worker_connections 65535; }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13

• Nginx中的Gzip技術

gzip是Nginx進行HTTP Body數據壓縮的技術。下面這段Nginx配置信息是啓用gzip壓縮的實例：

#開啓gzip壓縮服務， gzip on; #gzip壓縮是要申請臨時內存空間的，假設前提是壓縮後大小是小於等於壓縮前的。例如，若是原始文件大小爲10K，那麼它超過了8K，因此分配的內存是8 * 2 = 16K;再例如，原始文件大小爲18K，很明顯16K也是不夠的，那麼按照 8 * 2 * 2 = 32K的大小申請內存。若是沒有設置，默認值是申請跟原始數據相同大小的內存空間去存儲gzip壓縮結果。 gzip_buffers 2 8k; #進行壓縮的原始文件的最小大小值，也就是說若是原始文件小於5K，那麼就不會進行壓縮了 gzip_min_length 5K; #gzip壓縮基於的http協議版本，默認就是HTTP 1.1 gzip_http_version 1.1; # gzip壓縮級別1-9，級別越高壓縮率越大，壓縮時間也就越長CPU越高 gzip_comp_level 5; #須要進行gzip壓縮的Content-Type的Header的類型。建議js、text、css、xml、json都要進行壓縮；圖片就不必了，gif、jpge文件已經壓縮得很好了，就算再壓，效果也很差，並且還耗費cpu。 gzip_types text/HTML text/plain application/x-javascript text/css application/xml;

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17

http返回數據進行壓縮的功能在不少場景下都實用：

a、 若是瀏覽器使用的是3G/4G網絡，那麼流量對於用戶來講就是money。

b、 壓縮可節約服務器機房的對外帶寬，爲更多用戶服務。按照目前的市場價良好的機房帶寬資源的通常在200RMB/Mbps，而服務器方案的壓力每每也來自於機房帶寬。

c、 不是Nginx開啓了gzip功能，HTTP響應的數據就必定會被壓縮，除了知足Nginx設置的「須要壓縮的http格式」之外，客戶端（瀏覽器）也須要支持gzip（否則它怎麼解壓呢），一個好消息是，目前大多數瀏覽器和API都支持http壓縮。

• Nginx中的rewrite（重寫）技術

Nginx的強大在於其對URL請求的重寫（重定位）。Nginx的rewrite功能依賴於PCRE Lib，請必定在Nginx編譯安裝時，安裝Pcre lib。

Nginx的rewrite功能在我《架構設計：負載均衡層設計方案（3）——Nginx進階》 這邊博客中進行了講解。

下面是一段rewrite的示例：

#示例1： location ~* ^/(.+)/(.+)\.(jpg|gif|png|jpeg)$ { rewrite ^/orderinfo/(.+)\.(jpg|gif|png|jpeg)$ /img/$1.$2 break; root /cephclient; } #location在不進行大小寫區分的狀況下利用正則表達式對$url進行匹配。當匹配成功後進行rewrite重定位。 #rewrite進行重寫url的規則是：regex表達式第一個括號中的內容對應$1，regex表達式第二個括號中的內容對應$2，以此類推。 #這樣重定位的意義就很明確了：將任何目錄下的文件名重定位到img目錄下的對應文件名， #而且立刻在這個location中（注意是Nginx，而不是客戶端）執行這個重寫後的URL定位。 #示例2： server { 。。。。 。。。。 location ~* ^/orderinfo/(.+)\.(jpg|gif|png|jpeg)$ { rewrite ^/orderinfo/(.+)\.(.+)$ /img/$1.$2 last; } location / { root /cephclient; } } #在server中，有兩個location位置，當url須要訪問orderinfo目錄下的某一個圖片時，rewrite將重寫這個url， #而且從新帶入這個url到server執行，這樣「location /」這個location就會執行了，並找到圖片存儲的目錄。

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26

• Nginx的圖片處理模塊

http_image_filter_module 是nginx的圖片處理模塊，是使用nginx進行靜態資源和動態資源分開管理的關鍵引用技術。經過這個模塊能夠對靜態資源進行縮放、旋轉、驗證。

須要注意的是，http_image_filter_module模塊所處理的縮率圖片是不進行保存的，徹底使用節點的CPU性能進行計算，使用節點的內存進行臨時存儲。因此若是要使用http_image_filter_module進行圖片處理，必定要根據客戶端的請求規模進行nginx節點的調整。而且當站點的PV達到必定的規模時，必定要使用CDN技術進行訪問加速、對圖片的訪問處理手段進行規劃。

因爲咱們在以前涉及Nginx的文章中，並無詳細講解Nginx的圖片處理模塊，只是說了要進行介紹，因此這裏我給出一個較爲詳細的安裝和配置示例：

nginx的http_image_filter_module模塊由GD library進行支持，因此要使用這個圖片處理模塊，就必須進行第三方依賴包的安裝：

yum install gd-devel

• 1

• 1

而後，Nginx要進行從新編譯：

configure --with-http_image_filter_module make && make install

• 1
• 2

• 1
• 2

使用圖片處理模塊的配置示例：

location ~* /(.+)_(\d+)_(\d+)\.(jpg|gif|png|ioc|jpeg)$ {
    set $h $3; set $w $2; rewrite /(.+)_(\d+)_(\d+)\.(jpg|gif|png|ioc|jpeg)$ /$1.$4 break; image_filter resize $w $h; image_filter_buffer 2M; }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

其中關於正則表達式的語法和已經介紹過的rewrite的語法就再也不進行介紹了，主要看http_image_filter_module相關的屬性設置：

image_filter test：測試圖片文件合法性 
image_filter rotate：進行圖片旋轉，只能按照90 | 180 | 270進行旋轉 
image_filter size：返回圖片的JSON數據 
image_filter resize width height：按比例進行圖片的等比例縮小，注意，是隻能縮小，第二縮小是等比例的。 
image_filter_buffer：限制圖片最大讀取大小，沒有設置就是1M；根據不一樣的系統最好設置爲2M—3M 
image_filter_jpeg_quality：設置jpeg圖片的壓縮比例（1-99，越高越好） 
image_filter_transparency：禁用gif和png圖片的透明度。

• 和Nginx相似的其餘技術/軟件

目前行業內也有不少與Nginx解決同類問題的軟件，他們分別是Apache基金會的 Apache HTTP Server、淘寶開源的Tengine、Haproxy、包括Windows 下運行的IIS，也支持反向代理 。

這裏筆者再次重點提到Tengine，建議各位讀者有時間的時候可使用一下，這個對Nginx進行了深度再開發的軟件。

3-二、LVS技術

LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集羣系統。本項目在1998年5月由章文嵩博士成立。

LVS集羣採用IP負載均衡技術和基於內容請求分發技術。調度器具備很好的吞吐率，將請求均衡地轉移到不一樣的服務器上執行，且調度器自動屏蔽掉服務器的故障，從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集羣的結構對客戶是透明的，並且無需修改客戶端和服務器端的程序。

在個人系列文章中，《架構設計：負載均衡層設計方案（4）——LVS原理》 、《架構設計：負載均衡層設計方案（5）——LVS單節點安裝》 、《負載均衡層設計方案（7）——LVS + Keepalived + Nginx安裝及配置》 都涉及到LVS的講解。

這裏咱們再總結一下LVS中的三種工做模式：

3-2-一、NAT模式

NAT方式是一種由LVS Master服務節點收到數據報，而後轉給下層的Real Server節點，當Real Server處理完成後回發給LVS Master節點而後又由LVS Master節點轉發出去的工做方式。LVS的管理程序IPVSADMIN負責綁定轉發規則，並完成IP數據報文和TCP數據報文中屬性的重寫。

LVS-NAT模式的優勢在於：

• 配置管理簡單。LVS-NAT的工做方式是LVS三種工做模式中最容易理解、最容易配置、最容易管理的工做模式。

• 節省外網IP資源，通常機房分配給使用者的IP數量是有限的，特別是您購買的機架的數量很少時。LVS-NAT工做方式將您的系統架構封裝在局域網中，只須要LVS有一個外網地址或外網地址映射就能夠實現訪問了。

• 系統架構相對封閉。在內網環境下咱們對防火牆的設置要求不會很高，也相對容易進行物理服務器的運維。您能夠設置來源於外網的請求須要進行防火牆過濾，而對內網請求開放訪問。

• 另外改寫後轉給Real Server的數據報文，Real Server並不會關心它的真實性，只要TCP校驗和IP校驗都能經過，Real Server就能夠進行處理。因此LVS-NAT工做模式下Real Server能夠是任何操做系統，只要它支持TCP/IP協議便可。

3-2-二、DR模式

LVS的DR工做模式，是目前生產環境中最經常使用的一種工做模式，網上的資料也是最多的，有的文章對DR工做模式的講解仍是比較透徹的：

LVS-DR模式的優勢在於：

• 解決了LVS-NAT工做模式中的轉發瓶頸問題，可以支撐規模更大的負載均衡場景。

• 比較耗費網外IP資源，機房的外網IP資源都是有限的，若是在正式生產環境中確實存在這個問題，能夠採用LVS-NAT和LVS-DR混合使用的方式來緩解。

LVS-DR固然也有缺點：

• 配置工做較LVS-NAT方式稍微麻煩一點，您至少須要瞭解LVS-DR模式的基本工做方式才能更好的指導本身進行LVS-DR模式的配置和運行過程當中問題的解決。

• 因爲LVS-DR模式的報文改寫規則，致使LVS節點和Real Server節點必須在一個網段，由於二層交換是無法跨子網的。可是這個問題針對大多數系統架構方案來講，實際上並無本質限制。

3-2-三、TUN模式

LVS-DR模式和LVS-TUN模式的工做原理徹底不同，工做場景徹底不同。DR基於數據報文重寫，TUN模式基於IP隧道，後者是對數據報文的從新封裝：

IPIP隧道。將一個完整的IP報文封裝成另外一個新的IP報文的數據部分，並經過路由器傳送到指定的地點。在這個過程當中路由器並不在乎被封裝的原始協議的內容。到達目的地點後，由目的地方依靠本身的計算能力和對IPIP隧道協議的支持，打開封裝協議，取得原始協議：

能夠說LVS-TUN方式基本上具備LVS-DR的優勢。在此基礎上又支持跨子網間穿透。

3-三、CDN技術

CDN技術Content Delivery Network：內容分發網絡。爲何有時咱們訪問互聯網上的視頻資源、圖片資源會比較慢，甚至訪問失敗。其中有一個重要的緣由，是資源的物理位置離客戶端太遠了，可能其中有4層NAT設備（至關於使用網通的線路訪問電信服務器上的資源）。

咱們試想一下，若是將咱們要訪問的資源放到離咱們客戶端最近的一個服務上（例如在廣州的客戶端訪問的資源就在廣州的機房）。那麼是否是就解決了這個問題（這個點稱爲「邊緣節點」）。這就是CDN網絡解決的問題，以下圖所示：

目前CDN服務不須要咱們進行開發，市面上有不少公司都提供免費的/付費的 CDN服務（請直接在google或者百度上面輸入：CDN，就會有不少「推廣」信息了，在個人博文中不打廣告^_^）。固然若是您想自行搭建CDN網絡，能夠參考如下技術方案：

Squid：Squid是一個緩存internet數據的一個軟件，它接收用戶的下載申請，並自動處理所下載的數據。目前，國內不少CDN服務商的網絡都是基於Squid搭建的

利用Nginx的proxy_cache搭建：Nginx中的rewrite技術實際上就能夠實現URL請求重寫，實現請求轉發。而Nginx中的proxy_cache組件可使得從遠端請求的源數據保存在本地，從而實現一個CDN網絡的搭建。

本身寫：CDN網絡沒有特別複雜的技術門檻，若是您有特別的需求，能夠本身寫一個。固然上圖中所介紹的CDN網絡屬於第一代CDN網絡，將第二代/第三代P2P技術加入到CDN原理中，能夠造成第二代CDN網絡：以下圖所示：

第三代P2P技術又被稱爲混合型P2P技術主要是爲了解決元數據服務器的處理壓力，加速資源的本地化速度。關於P2P技術我會在講完「業務系統設計」、「業務通訊系統設計」後，專門作一個新的專題進行介紹。另外提一下，YouTube的P2P網絡就是本身作的。

四、後文介紹

要總結的內容實在太多了，我決定再開一篇文章《架構設計：負載均衡層設計方案（9）——負載均衡層總結下篇》，繼續進行負載均衡層技術的總結。咱們將總結Keepalived、DNS技術、硬件負載，而且向你們介紹更廣義的負載均衡技術。