負載均衡之總結篇
須要考慮的問題
在提出詳細的負載平衡解決方式之前，我們須要首先解說一下在設計負載平衡系統時我們所須要考慮的一些事情。
首先要說的就是要在負載平衡系統設計時留意它的高可用性及擴展性。在一開始的解說中。我們就已經提到過通過使用負載平衡。由眾多server實例所組成的服務具有非常高的可用性及擴展性。當當中一個服務實例失效的時候，其他服務實例能夠幫助它分擔一部分工作。
而在總服務容量顯得有些緊張的時候，我們能夠向服務中加入新的服務實例以擴展服務的總容量。
可是因為全部的傳輸數據都須要經過負載平衡server。因此負載平衡server一旦失效，那麽整個系統就將無法使用。也就是說，負載平衡server的可用性影響著整個系統的高可用性。
解決問題的方法要依據負載平衡server的類型來討論。對於L3/4負載平衡server而言，為了能夠讓整個系統不失效，業界中的經常用法是在系統中使用一對負載平衡server。當當中一個負載平衡server失效的時候，還有一個還能夠為整個系統提供負載平衡服務。
這一對負載平衡server能夠依照Active-Passive模式使用，也能夠依照Active-Active模式使用。
在Active-Passive模式中。一個負載平衡server處於半休眠狀態。其將會通過向另外一個負載平衡server發送心跳消息來探測對方的可用性。
當正在工作的負載平衡server不再響應心跳的時候，那麽心跳應用將會把負載平衡server從半休眠狀態喚醒。接管負載平衡server的IP並開始執行負載平衡功能。
而在Active-Active模式中。兩臺負載平衡server會同一時候工作。
假設當中一臺server發生了故障。那麽還有一臺server將會承擔全部的工作：
能夠說，兩者各有千秋。相較而言，Active-Active模式具有較好的抵抗訪問量大幅波動的情況。比如在通常情況下，兩個server的負載都在30%左右，可是在服務使用的高峰時間，訪問量可能是平時的兩倍，因此兩個server的負載就將達到60%左右，仍處於系統能夠處理的範圍內。假設我們使用的是Active-Passive模式，那麽平時的負載就將達到60%。而在高峰時間的負載將達到負載平衡server容量的120%。進而使得服務無法處理全部的用戶請求。
反過來，Active-Active模式也有不好的地方，那就是easy導致管理上的疏忽。比如在一個使用了Active-Active模式的系統中，兩個負載平衡server的負載常年都在60%左右。
那麽一旦當中的一個負載平衡server失效了，那麽剩下的唯一一個server相同將無法處理全部的用戶請求。
也許您會問：L3/4負載平衡server一定要有兩個麽？事實上主要由各負載平衡server產品自身來決定的。
在前面我們已經講過。實際上探測負載平衡server的可用性實際上須要非常復雜的測試邏輯。
因此假設一旦我們在一個負載平衡系統中使用了過多的L3/4負載平衡server，那麽這些負載平衡server之間所發送的各種心跳測試將消耗非常多的資源。同一時候因為非常多L3/4負載平衡server本身是基於硬件的，因此它能夠非常高速地工作。甚至能夠達到與其所支持的網絡帶寬所匹配的處理能力。因此在普通情況下，L3/4負載平衡server是成對使用的。
假設L3/4負載平衡server真的接近其負載極限，那麽我們還能夠通過DNS負載平衡來分散請求：
這樣的方法不僅僅能夠解決擴展性的問題。更能夠利用DNS的一個特性來提高用戶體驗：DNS能夠依據用戶所在的區域選擇距離用戶近期的server。
這在一個全球性的服務中尤為有效。
畢竟一個中國用戶訪問在中國架設的服務實例要比訪問在美國架設的服務實例快得多。
反過來因為L7負載平衡server主要是基於軟件的。因此非常多L7負載平衡server同意用戶創建較為復雜的負載平衡server系統。比如定義一個具有兩個啟用而有一個備用的一組L7負載平衡server。
解說完了高可用性，我們就來介紹一下負載平衡server的擴展性。
事實上在上面我們剛剛介紹過，L3/4負載平衡server擁有非常高的性能，因此一般的服務所使用的負載平衡系統不會遇到須要擴展性的問題。可是一旦出現了須要擴展的情況，那麽使用DNS負載平衡就能夠達到較好的擴展性。而L7負載平衡則更為靈活，因此擴展性更不是問題。
可是一個負載平衡系統不可能都是由L3/4負載平衡server組成的，也不可能僅僅由L7負載平衡server組成的。
這是因為兩者在性能和價格上都具有非常大的差異。一個L3/4負載平衡server實際上價格非常昂貴。經常達到上萬美元。而L7負載平衡server則能夠使用便宜server搭建。L3/4負載平衡server經常具有非常高的性能，而L7負載平衡server則經常通過組成一個集群來達到較高的總體性能。
在設計負載平衡系統時，還有一點須要考慮的那就是服務的動靜分離。
我們知道，一個服務經常由動態請求和靜態請求共同組成。這兩種請求具有非常不同的特點：一個動態請求經常須要大量的計算而傳輸的數據經常不是非常多，而一個靜態的請求經常須要傳輸大量的數據而不須要太多的計算。不同的服務容器對這些請求的表現差異非常大。因此非常多服務經常將其所包括的服務實例分為兩部分，分別用來處理靜態請求和動態請求，並使用適合的服務容器提供服務。
在這樣的情況下，靜態請求經常被置於特定的路徑下，如“/static”。
這樣負載平衡server就能夠依據請求所發送到的路徑而將動態請求和靜態請求進行適當地轉發。
最後要提到的就是L3/4負載平衡server的一個軟件實現LVS（Linux Virtual Server）。相較於硬件實現，軟件實現須要做非常多額外的工作。比如對數據包的解碼，為處理數據包分配內存等等呢個。因此其性能經常僅僅是具有相同硬件能力的L3/4負載平衡server的1/5到1/10。
鑒於其僅僅具有有限的性能可是搭建起來成本非常低，如利用已有的在Lab裏閑置的機器等。因此其經常在服務規模不是非常大的時候作為暫時替代方案使用。
負載平衡解決方式
在文章的最後，我們將給出一系列常見的負載平衡解決方式，以供大家參考。
在普通情況下。一個服務的負載經常是通過某些方式逐漸增長的。對應地。這些服務所擁有的負載平衡系統經常是從小到大逐漸演化的。因此我們也將會依照從小到大的方式逐次介紹這些負載平衡系統。
首先是最簡單的包括一對L7負載平衡server的系統：
假設服務的負載逐漸增大，那麽該系統中唯一的L7負載平衡server非常easy變成瓶頸。此時我們能夠通過加入一個SSL Farm以及執行LVS的server來解決問題：
假設我們還要應對增長的負載，那麽就須要使用真正的基於硬件的L3/4負載平衡server來替代LVS，並添加各層的容量：
因為該解決方式的以下三層基本都有理論上無限的擴展性。因此最easy出現過載的就是最上面的L3/4負載平衡server。
在這樣的情況下，我們就須要使用DNS來分配負載了：
負載均衡之總結篇