須要考慮的問題
在提出詳細的負載平衡解決方式之前，我們須要首先解說一下在設計負載平衡系統時我們所須要考慮的一些事情。
首先要說的就是要在負載平衡系統設計時留意它的高可用性及擴充套件性。在一開始的解說中。我們就已經提到過通過使用負載平衡。由眾多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來分配負載了：
全域性負載均衡GSLB之「部署篇」
前言 隨著web應用的不斷發展，客戶對於業務的穩定性 可靠性等也提出更高的要求，已不再侷限於idc內部的伺服器虛擬化。很多人都清楚，國內各大運營商之間資料互訪的效果不盡如意，而作為使用者，特別是要求業務及時響應的企業使用者，一方面要考慮異地idc的資料容災，另一方面要實現就近性訪問，提高客戶訪問體驗...
nginx負載均衡篇（二）
需要模組 ngx http upstream module ngx http proxy module 或者 ngx http upstream module ngx http fastcgi module 小知識 upstream 只能應用於http上下文，而proxy pass可以應用於loca...
負載均衡 概念認識篇
客串 屌絲的坑人表單神器 走過的那些事兒 資料庫那點事兒 文章開始，先吐槽一下 部落格的文章都是技術文章，尼瑪就不能多點心路歷程，xx管理，處事態度，傳說中的求職的事兒以及那些年所遇到的萌人萌事。一說到負載均衡，很多人都認為高 大 上。所以那些開發就把它供得高高在上，想去觸控，又不敢去。接下來的課程...