全棧必備：負載均衡

時間 2019-11-05

標籤必備負載均衡欄目負載均衡简体版

原文原文鏈接

來源：伯樂在線專欄做者 - abel_caojavascript

連接：http://blog.jobbole.com/106851/java

點擊 → 瞭解如何加入專欄做者mysql

一個了不得的創意會產生一個很棒的產品，若是它一炮走紅，你發現手中的是下一個facebook 或者twitter，並且隨着用戶愈來愈多，會變得愈來愈慢，該怎麼辦呢？對全棧而言，解決這類問題的一個重要技能就是——負載均衡。nginx

什麼是負載均衡

負載（load）一詞起源於典型系統，指鏈接在電路中消耗電能的裝置，負載（用電器）的功能是把電能轉變爲其餘形式能。引伸出來，一個是實體，一個轉化。web

因而，對於實體，有了通訊幀或者報文中數據字段的內容被稱爲信息負載（payload），網絡負載指的就是網絡中繼承載的流量以及網絡設備承載的用戶量。算法

轉化被進一步闡釋爲資源的使用狀況，系統平均負載是CPU的Load 即workload，它所包含的信息不是CPU的使用率情況，而是在一段時間內CPU正在處理以及等待CPU處理的進程數之和的統計信息。sql

瞭解了負載，那麼負載均衡就容易理解了。wiki百科給出的定義是這樣的：數據庫

負載均衡（Load balancing）是一種計算機網絡技術，用來在多個計算機（計算機集羣）、網絡鏈接、CPU、磁盤驅動器或其餘資源中分配負載，以達到最佳化資源使用、最大化吞吐率、最小化響應時間、同時避免過載的目的。使用帶有負載平衡的多個服務器組件，取代單一的組件，能夠經過冗餘提升可靠性。負載平衡服務一般是由專用軟件和硬件來完成。後端

而且，wiki百科自身的系統就使用了負載均衡。緩存

每一種技術都有它應用的場景和領域，負載均衡主要解決的是系統性能問題。可是，瞭解了根源，就能夠知道不可以一提到性能問題就非負載均衡莫屬，若是負載減小了，可能少一點均衡也能夠解決問題，這樣的技術例如緩存。

基於DNS的負載均衡

基於DNS的負載均衡是負載均衡的最簡方法，能夠說是窮人的負載均衡。

DNS會將域名映射爲IP地址，反之亦然。全部核心DNS服務器都是集羣，用的最多的DNS服務器大概就是BIND了。查詢DNS服務器時，推薦使用dig；查詢DNS解析時，推薦使用nslookup。使用DNS緩存能夠提升DNS解析的性能。Dig 在mac上的使用示例以下：

對於DNS實現的負載均衡很是簡單，採用輪轉的方式，只要爲所要服務的域名增長多個A記錄便可。
例如:

abel.com. IN A 168.168.168.168

abel.com. IN A 168.168.168.168

abel.com. IN A 168.168.168.168

abel.com. IN A 168.168.168.168

基於DNS的負載均衡簡單，易於調試且容易擴展。缺陷在於它有慢性失憶症，沒法將會話信息從一個請求保留到下一個請求。並且，只是對目標服務地址進行了均衡，沒法考慮請求處理的負載強度進行均衡，同時容錯性較差。

支持DNS 負載均衡的服務商有AWS Route 53 以及dnspod。

HTTP 負載均衡

負載均衡解決的是性能問題，要先了解單個服務器的情況。通常地，nginx 的應答率比Apache 高，因此，有時更換Web 服務器就能夠提升性能。

提升Apache Http的方法有禁用空載模塊，禁用DNS查詢，採用壓縮模塊，不使用SymLinksIfOwnerMatch選項，而且在Directory選項中啓用FollowSymLinks，等等。

Nginx自己就是高性能的，但能夠經過worker_processes 和worker_cpu_affinity調整來匹配服務器的硬件平臺，還能夠對壓縮進行區分對待，使用其緩存的能力。例如

Http{

        gzip on;

        gzip_static on;

        gzip_comp_level 2;

        gzip_types application/javascript;

}

HTTP的負載均衡至關於7層負載均衡，不論Apache 仍是 Nginx 均可以充當HTTP的負載均衡器。

以基於權重的負載均衡爲例，能夠配置Nginx把請求更多地分發到高配置的後端服務器上，把相對較少的請求分發到低配服務器。配置的示例以下：

http{

   upstream sampleapp {

     server 192.168.1.23 weight=2;

     server 192.168.1.24;

  }

....

server{

listen 80;

...

   location / {

     proxy_pass http://myapp;

   }

}

Nginx 做爲負載均衡工做在7層，能夠對作正則規則處理（如針對域名、目錄進行分流等），配置簡單，能ping通就能進行負載功能，能夠經過端口檢測後端服務器狀態，不支持url檢測。Nginx 負載均衡抗高併發，採用epoll網絡模型處理客戶請求，但應用範圍受限。

數據庫負載均衡

數據庫負載均衡的通常用法從讀寫分離開始的，由於通常的應用都是讀多寫少的緣故吧。將數據庫作成主從，主數據用於寫操做，從數據庫用於讀操做，事務通常在主庫完成。

數據庫集羣是數據庫負載均衡的典型方式，集羣管理服務器做爲負載均衡器，例如mysql cluster。

更簡單的方式是經過Haproxy 來完成負載均衡的調度。

HAProxy可以補充Nginx的一些缺點好比Session的保持，Cookie的引導等工做，支持url檢測後端的服務器出問題的檢測會有很好的幫助。

HAProxy擁有更多的負載均衡策略好比：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash）等，單純從效率上來說HAProxy更會比Nginx有更出色的負載均衡速度。

網絡鏈接的負載均衡

LVS(IPVS，IP虛擬服務器)是在四層交換上設置Web服務的虛擬IP地址，對客戶端是可見的。當客戶訪問此Web應用時，客戶端的Http請求會先被第四層交換機接收到，它將基於第四層交換技術實時檢測後臺Web服務器的負載，根據設定的算法進行快速交換。常見的算法有輪詢、加權、最少鏈接、隨機和響應時間等。

LVS抗負載能力強，使用IP負載均衡技術，只作分發，因此LVS自己並無多少流量產生。 LVS的穩定性和可靠性都很好應用範圍比較廣，能夠對全部應用作負載均衡，缺陷是不支持正則處理，不能作動靜分離。

經過LVS+Keepalived構建的LVS集羣，LVS負載均衡用戶請求到後端服務器，Keepalived的做用是檢測web服務器的狀態，若是有一臺web服務器死機，或工做出現故障，Keepalived將檢測到，並將有故障的web服務器從系統中剔除，當web服務器工做正常後Keepalived自動將web服務器加入到服務器羣中，這些工做所有自動完成，不須要人工干涉，須要人工作的只是修復故障的web服務器。

下圖是Keepalived的原理圖：

SSL負載均衡

信任是互聯網的基石，出於安全性的考量，服務中每每須要SSL的鏈接。SSL 有兩種認證方式：雙向認證 SSL 協議要求服務器和用戶雙方都有證書；單向認證 SSL 協議不須要客戶擁有CA證書。通常Web應用，配置SSL單向認證便可。但部分金融行業用戶的應用對接，可能會要求對客戶端(相對而言)作身份驗證。這時就須要作SSL雙向認證。

SSL 屬於應用層的協議，因此只能在 7 層上來作，而 HAProxy 也是支持 SSL 協議的，因此一種方式是隻需簡單的讓 HAProxy 開啓 SSL 支持完成對內解密對外加密的處理, 但引入 SSL 處理是有額外的性能開銷的（如上面談到的認證）, 因此通常採用SSL proxy farm，典型的架構以下：

壓力和負載測試

測試負載的情況，通常要涉及負載或壓力測試。

負載測試是模擬實際軟件系統所承受的負載條件的系統負荷，經過不斷增長負載載（如逐漸增長模擬用戶的數量）或其它加載方式來觀察不一樣負載下系統的響應時間和數據吞吐量、系統佔用的資源等，以檢驗系統的行爲和特性，並發現系統可能存在的性能瓶頸、內存泄漏、不能實時同步等問題。

負載測試更多地體現了一種方法或一種技術。壓力測試是在強負載（大數據量、大量併發用戶等）下的測試，查看應用系統在峯值使用狀況下操做行爲，從而有效地發現系統的某項功能隱患、系統是否具備良好的容錯能力和可恢復能力。壓力測試分爲高負載下的長時間（如24小時以上）的穩定性壓力測試和極限負載狀況下致使系統崩潰的破壞性壓力測試。

壓力測試能夠被看做是負載測試的一種，即高負載下的負載測試，或者說壓力測試採用負載測試技術。

簡單地，httperf 或者Apache AB 就能夠測量HTTP 服務器的負載性能。