快速理解高性能HTTP服務端的負載均衡技術原理(轉)

一、前言 在一個典型的高併發、大用戶量的Web互聯網系統的架構設計中，對HTTP集羣的負載均衡設計是做爲高性能系統優化環節中必不可少的方案。HTTP負載均衡的本質上是將Web用戶流量進行均衡減壓，所以在互聯網的大流量項目中，其重要性不言而喻。 本文將以簡潔通俗的文字，爲你講解主流的HTTP服務端實現負載均衡的常見方案，以及具體到方案中的負載均衡算法的實現原理。理解和掌握這些方案、算法原理，有助於您從此的互聯網項的技術選型和架構設計，由於沒有哪種方案和算法能解決全部問題，只有針對特定的場景使用合適的方案和算法纔是最明智的選擇。 即時通信網注：本文中所說起的HTTP負載均衡方案和算法，並不徹底適用IM即時通信Socket長鏈接的負載均衡，由於IM長鏈接、有狀態的特性，跟HTTP這種短鏈接、無狀態的特徵是矛盾的，因此請勿盲目套用。但，一個完整的IM系統是由HTTP短鏈接+IM長鏈接組成，於是本文內容雖不能套用於IM長鏈接的負載均衡方案，但能夠用於您IM的高併發、大用戶量的HTTP短鏈接的方案設計。 二、相關文章 深刻閱讀如下文章，有助於您更好地理解本篇內容： 《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》 《以微博類應用場景爲例，總結海量社交系統的架構設計步驟》 《IM開發基礎知識補課(四)：正確理解HTTP短鏈接中的Cookie、Session和Token》 三、什麼是負載均衡？ 早期的互聯網應用，因爲用戶流量比較小，業務邏輯也比較簡單，每每一個單服務器就能知足負載需求。隨着如今互聯網的流量愈來愈大，稍微好一點的系統，訪問量就很是大了，而且系統功能也愈來愈複雜，那麼單臺服務器就算將性能優化得再好，也不能支撐這麼大用戶量的訪問壓力了，這個時候就須要使用多臺機器，設計高性能的集羣來應對。 那麼，多臺服務器是如何去均衡流量、如何組成高性能的集羣的呢？ 此時就須要請出 「負載均衡器」 入場了。 負載均衡（Load Balancer）是指把用戶訪問的流量，經過「負載均衡器」，根據某種轉發的策略，均勻的分發到後端多臺服務器上，後端的服務器能夠獨立的響應和處理請求，從而實現分散負載的效果。負載均衡技術提升了系統的服務能力，加強了應用的可用性。 負載均衡的基本原理就像下圖這樣： <ignore_js_op>  四、主流負載均衡方案有幾種？ 目前市面上最多見的負載均衡技術方案主要有三種： 1）基於DNS負載均衡； 2）基於硬件負載均衡：好比F5 3）基於軟件負載均衡：好比Nginx、Squid。 三種方案各有優劣，DNS負載均衡能夠實如今地域上的流量均衡，硬件負載均衡主要用於大型服務器集羣中的負載需求，而軟件負載均衡大可能是基於機器層面的流量均衡。在實際場景中，這三種是能夠組合在一塊兒使用。 下面分別來詳細講講這些方案。 4.1基於DNS負載均衡 <ignore_js_op>  基於DNS來作負載均衡實際上是一種最簡單的實現方案，經過在DNS服務器上作一個簡單配置便可。 其原理就是：當用戶訪問域名的時候，會先向DNS服務器去解析域名對應的IP地址，這個時候咱們可讓DNS服務器根據不一樣地理位置的用戶返回不一樣的IP。好比南方的用戶就返回咱們在廣州業務服務器的IP，北方的用戶來訪問的話，我就返回北京業務服務器所在的IP。 在這個模式下，用戶就至關於實現了按照「就近原則」將請求分流了，既減輕了單個集羣的負載壓力，也提高了用戶的訪問速度。 使用DNS作負載均衡的方案，自然的優點就是配置簡單，實現成本很是低，無需額外的開發和維護工做。 可是它也有一個明顯的缺點：當配置修改後，生效不及時。這個是因爲DNS的特性致使的，DNS通常會有多級緩存，因此當咱們修改了DNS配置以後，因爲緩存的緣由，會致使IP變動不及時，從而影響負載均衡的效果。 另外，使用DNS作負載均衡的話，大可能是基於地域或者乾脆直接作IP輪詢，沒有更高級的路由策略，因此這也是DNS方案的侷限所在。 4.2基於硬件負載均衡 <ignore_js_op>  硬件的負載均衡那就比較牛逼了，好比大名鼎鼎的 F5 Network Big-IP，也就是咱們常說的 F5，它是一個網絡設備，你能夠簡單的理解成相似於網絡交換機的東西，徹底經過硬件來抗壓力，性能是很是的好，每秒能處理的請求數達到百萬級，即 幾百萬/秒 的負載，固然價格也就很是很是貴了，十幾萬到上百萬人民幣都有。 由於這類設備通常用在大型互聯網公司的流量入口最前端，以及政府、國企等不缺錢企業會去使用。通常的中小公司是不捨得用的。 採用 F5 這類硬件作負載均衡的話，主要就是省心省事，買一臺就搞定，性能強大，通常的業務不在話下。並且在負載均衡的算法方面還支持不少靈活的策略，同時還具備一些防火牆等安全功能。可是缺點也很明顯，一個字：貴。 4.3基於軟件負載均衡 <ignore_js_op>  軟件負載均衡是指使用軟件的方式來分發和均衡流量。軟件負載均衡分爲7層協議 和 4層協議。 網絡協議有七層，基於第四層傳輸層來作流量分發的方案稱爲4層負載均衡，例如 LVS；而基於第七層應用層來作流量分發的稱爲7層負載均衡，例如 Nginx。這兩種在性能和靈活性上是有些區別的。 基於4層的負載均衡性能要高一些，通常能達到 幾十萬/秒 的處理量，而基於7層的負載均衡處理量通常只在 幾萬/秒 。 基於軟件的負載均衡的特色也很明顯，便宜。在正常的服務器上部署便可，無需額外採購，就是投入一點技術去優化優化便可，所以這種方式是互聯網公司中用得最多的一種方式。 五、經常使用的均衡算法有哪些？ 上面講完了常見的負載均衡技術方案，那麼接下來我們看一下，在實際方案應用中，通常可使用哪些均衡算法？ 主要的均衡算法有： 1）輪詢策略； 2）負載度策略； 3）響應策略； 4）哈希策略。 下面來分別介紹一下這幾種均衡算法/策略的特色。 5.1輪詢策略 輪詢策略其實很好理解，就是當用戶請求來了以後，「負載均衡器」將請求輪流的轉發到後端不一樣的業務服務器上。這個策略在DNS方案中用的比較多，無需關注後端服務的狀態，只藥有請求，就日後端輪流轉發，很是的簡單、實用。 在實際應用中，輪詢也會有多種方式，有按順序輪詢的、有隨機輪詢的、還有按照權重來輪詢的。前兩種比較好理解，第三種按照權重來輪詢，是指給每臺後端服務設定一個權重值，好比性能高的服務器權重高一些，性能低的服務器給的權重低一些，這樣設置的話，分配流量的時候，給權重高的更多流量，能夠充分的發揮出後端機器的性能。 5.2負載度策略 負載度策略是指當「負載均衡器」日後端轉發流量的時候，會先去評估後端每臺服務器的負載壓力狀況，對於壓力比較大的後端服務器轉發的請求就少一些，對於壓力比較小的後端服務器能夠多轉發一些請求給它。 這種方式就充分的結合了後端服務器的運行狀態，來動態的分配流量了，比輪詢的方式更爲科學一些。 可是這種方式也帶來了一些弊端，由於須要動態的評估後端服務器的負載壓力，那這個「負載均衡器」除了轉發請求之外，還要作不少額外的工做，好比採集 鏈接數、請求數、CPU負載指標、IO負載指標等等，經過對這些指標進行計算和對比，判斷出哪一臺後端服務器的負載壓力較大。 所以這種方式帶來了效果優點的同時，也增長了「負載均衡器」的實現難度和維護成本。 5.3響應策略 響應策略是指，當用戶請求過來的時候，「負載均衡器」會優先將請求轉發給當前時刻響應最快的後端服務器。 也就是說，無論後端服務器負載高不高，也無論配置如何，只要以爲這個服務器在當前時刻能最快的響應用戶的請求，那麼就優先把請求轉發給它，這樣的話，對於用戶而言，體驗也最好。 那「負載均衡器」是怎麼知道哪一臺後端服務在當前時刻響應能力最佳呢？ 這就須要「負載均衡器」不停的去統計每一臺後端服務器對請求的處理速度了，好比一分鐘統計一次，生成一個後端服務器處理速度的排行榜。而後「負載均衡器」根據這個排行榜去轉發服務。 那麼這裏的問題就是統計的成本了，不停的作這些統計運算自己也會消耗一些性能，同時也會增長「負載均衡器」的實現難度和維護成本。 5.4哈希策略 Hash策略也比較好理解，就是將請求中的某個信息進行hash計算，而後根據後端服務器臺數取模，獲得一個值，算出相同值的請求就被轉發到同一臺後端服務器中。 常見的用法是對用戶的IP或者ID進行這個策略，而後「負載均衡器」就能保證同一個IP來源或者同一個用戶永遠會被送到同一個後端服務器上了，通常用於處理緩存、會話等功能的時候特別好用。 六、本文小結 基於運營成本的考慮，目前在互聯網項目中，HTTP服務端的負載均衡的具體解決方案，用的最多的仍是Nginx（及其分支，好比淘寶的Tengin），若是有時間，建議能夠把Nginx下載下來，仔細研究研究它的負載均衡原理，以及它所提供的幾種負載均衡算法，理論聯繫實際來學習就更能促進你對相關知識的理解和掌握了。 得益於Nginx這種開源免費的高性能方案，它們間接地促進了互聯網的繁榮，感謝這些偉大開源方案背後的無私貢獻者們！ 附錄：更多架構設計方案的文章精選 《淺談IM系統的架構設計》 《簡述移動端IM開發的那些坑：架構設計、通訊協議和客戶端》 《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》 《一套原創分佈式即時通信(IM)系統理論架構方案》 《從零到卓越：京東客服即時通信系統的技術架構演進歷程》 《蘑菇街即時通信/IM服務器開發之架構選擇》 《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》 《微信後臺基於時間序的海量數據冷熱分級架構設計實踐》 《微信技術總監談架構：微信之道——大道至簡(演講全文)》 《如何解讀《微信技術總監談架構：微信之道——大道至簡》》 《快速裂變：見證微信強大後臺架構從0到1的演進歷程（一）》 《17年的實踐：騰訊海量產品的技術方法論》 《移動端IM中大規模羣消息的推送如何保證效率、實時性？》 《現代IM系統中聊天消息的同步和存儲方案探討》 《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》 《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》 《IM開發基礎知識補課(四)：正確理解HTTP短鏈接中的Cookie、Session和Token》 《WhatsApp技術實踐分享：32人工程團隊創造的技術神話》 《微信朋友圈千億訪問量背後的技術挑戰和實踐總結》 《王者榮耀2億用戶量的背後：產品定位、技術架構、網絡方案等》 《IM系統的MQ消息中間件選型：Kafka仍是RabbitMQ？》 《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》 《以微博類應用場景爲例，總結海量社交系統的架構設計步驟》 《快速理解高性能HTTP服務端的負載均衡技術原理》 >> 更多同類文章 ……

來源：即時通信網 - 即時通信開發者社區！