全棧必備——負載均衡的應用

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

什麼是負載均衡

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

於是，對於實體，有了通訊幀或者報文中資料欄位的內容被稱為資訊負載（payload），網路負載指的就是網路中繼承載的流量以及網路裝置承載的使用者量。

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

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

負載均衡（Load balancing）是一種計算機網路技術，用來在多個計算機（計算機叢集）、網路連線、CPU、磁碟驅動器或其他資源中分配負載，以達到最佳化資源使用、最大化吞吐率、最小化響應時間、同時避免過載的目的。使用帶有負載平衡的多個伺服器元件，取代單一的元件，可以通過冗餘提高可靠性。負載平衡服務通常是由專用軟體和硬體來完成。

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

wikipedia

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

基於DNS的負載均衡

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

DNS會將域名對映為IP地址，反之亦然。所有核心DNS伺服器都是叢集，用的最多的DNS伺服器大概就是BIND了。查詢DNS伺服器時，推薦使用dig；查詢DNS解析時，推薦使用nslookup。 使用DNS快取可以提高DNS解析的效能。Dig 在mac上的使用示例如下：

dig 用法

對於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 均衡資料庫

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的原理圖：

KeepLived 的原理圖

SSL負載均衡

信任是網際網路的基石，出於安全性的考量，服務中往往需要SSL的連線。SSL 有兩種認證方式：雙向認證 SSL 協議要求伺服器和使用者雙方都有證照；單向認證 SSL 協議不需要客戶擁有CA證照。一般Web應用，配置SSL單向認證即可。但部分金融行業使用者的應用對接，可能會要求對客戶端(相對而言)做身份驗證。這時就需要做SSL雙向認證。

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

SSL 負載均衡

壓力和負載測試

測試負載的狀況，一般要涉及負載或壓力測試。

負載測試是模擬實際軟體系統所承受的負載條件的系統負荷，通過不斷增加負載載（如逐漸增加模擬使用者的數量）或其它載入方式來觀察不同負載下系統的響應時間和資料吞吐量、系統佔用的資源等，以檢驗系統的行為和特性，並發現系統可能存在的效能瓶頸、記憶體洩漏、不能實時同步等問題。

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

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

簡單地，httperf 或者Apache AB 就可以測量HTTP 伺服器的負載效能。

雲服務的負載均衡

雲時代的到來，使負載均衡成了平臺級的服務，幾乎所有的雲服務提供商都提供了負載均衡服務。下面是阿里雲的負載均衡基礎框架圖：

阿里雲的slb

特別的，qingcloud 的vpc 也是挺有特點的，私有網路 用於主機之間互聯，類似於使用交換機（L2 Switch）自組區域網。彈性IP還好，管理路由器就顯得很貼心了。

AWS 的負載均衡還是業界典範，官方給出的示意圖如下：

AWS ELB

高可用性

高可用性是負載均衡帶來的另一價值, 即負載均衡經常被用於實現故障轉移。當一個或多個元件出現故障時，能持續提供服務的這些元件都在持續監控中，當一個元件沒有響應，負載均衡器就會發現它，並不再向其傳送資料。同樣當一個元件重新上線，負載均衡器會重新開始向其傳送資料。

SLA 作為高可用性的指標，一般有3個時間標準：99.9%,99.99%,99.999%. 表示不間斷執行的離線時間不超過：

• 3個9： 8.76 小時
• 4個9：52.26 小時
• 5個9：5.26 分鐘

三點兩地的災備方案並不是誰都做的起的，有了雲服務就顯得不那麼苦難了。下面是阿里雲給出的容災示意圖，多可用區部署，機房當機後，仍能正常工作。

系統的監控在系統高可用性上作用很大，個人推薦zabbix。

總體來看， 負載均衡是系統架構和DevOps 中的重要技術，對系統效能影響巨大。當然，如果有更高需求的話，就需要考慮硬體的負載均衡方案了，比如說F5。