程序員修神之路--高併發系統設計負載均衡架構

菜菜哥，上次你給我講的分庫分表策略對我幫助很大

有幫助就好，上次請個人咖啡也很好喝~

呵呵，不過隨着訪問量的不斷加大，網站我又加了nginx作負載均衡

好呀，看來要進階高級工程師啦~

負載均衡也很簡單呀，一個nginx就搞定了，如今能夠說我精通負載均衡了吧

其實負載均衡的內容還有不少

一個系統發展初期，每每都是單機系統。應用和數據庫在一臺服務器上，隨着業務的發展，訪問量的增大，一臺服務器性能就會出現天花板，每每已經難以支撐業務量了。這個時候就要考慮把數據庫和應用服務器分開，訪問繼續增長，就會考慮數據庫分庫分表，應用服務器作負載均衡，其實這也屬於分佈式系統的一個範疇。分佈式系統的核心概念就是一個「分」字，一臺服務器支撐不住，那就兩臺，三臺，四臺....固然分以後會帶來其餘問題，好比最多見的數據一致性問題，調用鏈監控等問題，這些不在今日的討論範圍內，有興趣的同窗請移步百度。

不少項目作「分佈式」部署提升系統性能，首期採用的每每是負載均衡策略。

負載均衡

負載均衡，英文名稱爲Load Balance，其含義就是指將負載（工做任務）進行平衡、分攤到多個操做單元上進行運行，例如FTP服務器、Web服務器、企業核心應用服務器和其它主要任務服務器等，從而協同完成工做任務。負載均衡構建在原有網絡結構之上，它提供了一種透明且廉價有效的方法擴展服務器和網絡設備的帶寬、增強網絡數據處理能力、增長吞吐量、提升網絡的可用性和靈活性。

負載均衡既然屬於「分」策略的一種表現形式，就會涉及到任務的分配者，任務執行者，分配算法。這裏的任務分配者就是咱們常說的負載均衡器，任務執行者就是處理任務的服務器，分配算法就是常說的輪訓等分配策略。這裏把任務的分配者叫作負載均衡器實際上是不正確的，負載均衡器這個概念注重的更可能是均勻分配任務，讓每一個任務的計算單元的任務量達到均衡狀態，而現實中任務的分配更可能是出於每一個計算單元的性能或者業務來考慮。讓每一個計算單元處理幾乎相同數量的任務只是分佈式均衡器其中的一部份內容。

以http請求爲例，在一個http請求的過程當中，其實會遇到有不少負載均衡的過程，一個系統在什麼階段作負載均衡取決於它的請求量，這和常說的QPS/TPS/DAU等有直接關係，假設系統的請求量很是少，其實徹底沒有必要作負載均衡，固然有時候爲了達到高可用的目的也作負載均衡，這裏不在展開討論。那一個http請求到底能夠通過哪些負載均衡器呢？http請求的過程以下圖所示

 DNS負載均衡

當一個client向一個url發起請求（這裏不考慮直接請求IP地址的狀況），第一步須要作的就是請求DNS服務器去作域名解析，把請求的域名轉換成IP地址。DNS解析同一個域名能夠根據來源返回不一樣的IP地址，利用這個特性能夠作DNS負載均衡。client請求離本身最近的資源纔是最快的，因此能夠把系統部署在不一樣區域的機房，每一個client通過DNS解析只請求離本身最近的機房資源，比請求異地的機房資源要快的多。例如：一個網站能夠同時部署在北京機房和深圳機房，河北的用戶請求網站的時候都會被導向北京機房，比訪問深圳的速度要快的多。

DNS負載均衡僅限於解析域名的時機，因此它的力度是很粗的，相應的負載均衡算法也有限。可是這種方案實現起來比較簡單，成本也很低，並且在必定程度了縮短了用戶的響應時間，加快了訪問速度。因爲DNS信息都有很長時間的緩存，因此更新的時候會有一段時間的信息差別，會致使部分用戶正常業務的訪問的錯誤。

硬件負載均衡

當一個請求知道了要訪問的目標IP，便會經過層層的網關和路由器到達目標IP的機房，在這以前屬於網絡傳輸的範疇，通常很難進行干預。有不少機房都經過硬件設施來實現負載均衡的目的，這和路由器、交換機相似，也能夠理解爲底層的設備。目前最經常使用的莫過於F5了，這樣的硬件設備通常都出產於大公司，性能都通過嚴格測試，功能強大，可是很貴，通常的中小公司不會更沒有必要使用這種土豪設備。

硬件負載均衡性能很強大，支撐的併發通常都在每秒幾百萬，並且支持的負載算法也不少，並且通常都配套的有安全防禦措施，好比防火牆，防攻擊等安全功能。

軟件負載均衡

相比於硬件負載均衡，如今每一個公司更常見的是軟件負載均衡，基本過程就是獨立出一個負載均衡服務器或者集羣，安裝上有負載均衡功能的軟件來進行分發。最經常使用的4層負載均衡軟件LVS，幾乎全部應用層的負載均衡均可以作，目前LVS已經被集成到Linux內核模塊中。該項目在Linux內核中實現了基於IP的數據請求負載均衡調度方案。還有處於7層的nginx也能夠實現負載均衡，Nginx 支持 HTTP、E-mail協議，固然如今有相應的nginx作4層負載均衡的模塊。

與硬件想比，軟件負載均衡的吞吐量要小不少，就算是4層的LVS的性能也只在幾十萬而已，nginx在幾萬，不過這對於通常公司的業務也足夠了，當一個公司的業務量請求量達到幾百萬，估計也有錢買F5硬件了。軟件負載均衡的最大優點在於配置靈活，可擴展性強，可定製性比較強，並且成本還很低。這也是中小公司首選的方案。

應用

說了這麼多，其實以上幾種方案是基於http請求的途經來解決問題，每種方案都有它本身的缺點和優勢，設計一個系統的時候初期就把以上方案所有采用以達到高性能的要求，也許並非什麼好事，每個系統都是隨着業務的增加而逐漸改變架構形態，而這個過程採用的負載方案通常過程都是 軟件負載->硬件負載->DNS負載，固然這裏的硬件和DNS也許有時候會顛倒過來，可是軟件確定是首當其衝的。隨着業務量的增大，以上三種方案更多的是互相配合，互相補充的，就像微信這種業務，不可能單獨的使用硬件負載就能達到業務要求的。

至於什麼階段採用什麼方案，仍是要根據具體業務的請求量來決定，好比：當前個人QPS在 一萬左右，徹底能夠用nginx或者LVS去解決，當上升到百萬級別，能夠嘗試着用硬件+軟件的方式去解決，當到達千萬甚至更高，就要考慮多機房部署DNS負載均衡了，沒有一種方案是完美的，可是能夠採用多種方案混用的方式來達到近乎完美的狀況。