1. 程式人生 > >程式設計師修神之路--高併發系統設計負載均衡架構

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

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

有幫助就好,上次請我的咖啡也很好喝~

呵呵,不過隨著訪問量的不斷加大,網站我又加了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負載均衡了,沒有一種方案是完美的,但是可以採用多種方案混用的方式來達到近乎完美的情況。