作者 | 菜菜
YY妹：菜菜哥，上次你給我講的分庫分表策略對我幫助很大。
菜菜：有幫助就好，上次請我的咖啡也很好喝。
YY妹：不過隨著訪問量的不斷加大，網站我又加了Nginx做負載均衡。
菜菜：哇哦，看來要進階高級工程師啦。
YY妹：負載均衡也很簡單吧，一個Nginx就搞定了！現在可以說我精通負載均衡了吧：）
菜菜：其實負載均衡的內容還有很多......
一個系統發展初期，往往都是單機系統。應用和數據庫在一臺服務器上，隨著業務的發展，訪問量的增大，一臺服務器性能就會出現天花板，往往已經難以支撐業務量了。這個時候就要考慮把數據庫和應用服務器分開，訪問繼續增加，就會考慮數據庫分庫分表，應用服務器做負載均衡，其實這也屬於分佈式系統的一個範疇。
分佈式系統的核心概念就是一個“分”字，一臺服務器支撐不住，那就兩臺，三臺，四臺......當然分之後會帶來其他問題，比如最常見的數據一致性問題、調用鏈監控等問題，不過限於篇幅，這些不在今日的討論範圍內。
很多項目做“分佈式”部署提高系統性能，首期採用的往往是負載均衡策略。
負載均衡
負載均衡，英文名稱為Load Balance，其含義就是指將負載（工作任務）進行平衡、分攤到多個操作單元上進行運行，例如FTP服務器、Web服務器、企業核心應用服務器和其它主要任務服務器等，從而協同完成工作任務。
負載均衡構建在原有網絡結構之上，它提供了一種透明且廉價有效的方法擴展服務器和網絡設備的帶寬、加強網絡數據處理能力、增加吞吐量、提高網絡的可用性和靈活性。
負載均衡既然屬於“分”策略的一種表現形式，就會涉及到任務的分配者，任務執行者，分配算法。這裡的任務分配者就是我們常說的負載均衡器，任務執行者就是處理任務的服務器，分配算法就是常說的輪訓等分配策略。這裡把任務的分配者叫做負載均衡器其實是不正確的，負載均衡器這個概念注重的更多是均勻分配任務，讓每個任務的計算單元的任務量達到均衡狀態，而現實中任務的分配更多是出於每個計算單元的性能或者業務來考慮。讓每個計算單元處理幾乎相同數量的任務只是分佈式均衡器其中的一部分內容。
以
HTTP請求為例，在一個HTTP請求的過程中，其實會遇到有很多負載均衡的過程，一個系統在什麼階段做負載均衡取決於它的請求量，這和常說的QPS/TPS/DAU等有直接關係。假設系統的請求量非常少，其實完全沒有必要做負載均衡，當然有時候為了達到高可用的目的也做負載均衡。那一個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負載均衡了。沒有一種方案是完美的，但是可以採用多種方案混用的方式來達到近乎完美的情況。
作者：菜菜，一個奔走在通往互聯網更高之路的工程師，熱衷於互聯網技術。目前就職於某互聯網教育公司，應用服務端主要負責人。擁有10年+互聯網開發經驗，熱衷於高性能、高併發、分佈式技術領域的研究，主要工作語言為C#和Golang。
【END】
閱讀更多 CSDN 的文章
