什么是負載均衡

負載(load)一詞起源于典型系統(tǒng)，指連接在電路中消耗電能的裝置，負載(用電器)的功能是把電能轉(zhuǎn)變?yōu)槠渌问侥堋Ｒ瓿鰜?，一個是實體，一個轉(zhuǎn)化。

于是，對于實體，有了通信幀或者報文中數(shù)據(jù)字段的內(nèi)容被稱為信息負載(payload)，網(wǎng)絡負載指的就是網(wǎng)絡中繼承載的流量以及網(wǎng)絡設備承載的用戶量。

轉(zhuǎn)化被進一步闡釋為資源的使用情況，操作系統(tǒng)的平均負載是CPU的Load 即workload，它所包含的信息不是CPU的使用率狀況，而是在一段時間內(nèi)CPU正在處理以及等待CPU處理的進程數(shù)之和的統(tǒng)計信息。

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

負載均衡(Load balancing)是一種計算機網(wǎng)絡技術(shù)，用來在多個計算機(計算機集群)、網(wǎng)絡連接、CPU、磁盤驅(qū)動器或其他資源中分配負載，以達到最佳化資源使用、最大化吞吐率、最小化響應時間、同時避免過載的目的。使用帶有負載平衡的多個服務器組件，取代單一的組件，可以通過冗余提高可靠性。負載平衡服務通常是由專用軟件和硬件來完成。

并且，wiki百科自身的系統(tǒng)就使用了負載均衡, 后段系統(tǒng)使用了elasticsearch。

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

基于DNS的負載均衡

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

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

對于DNS實現(xiàn)的負載均衡非常簡單，采用輪轉(zhuǎn)的方式，只要為所要服務的域名增加多個A記錄即可。

例如:

abel.com. IN A 192.168.23.101 abel.com. IN A 192.168.23.102 abel.com. IN A 192.168.23.103 abel.com. IN A 192.168.23.104

基于DNS的負載均衡簡單，易于調(diào)試且容易擴展。缺陷在于它有慢性失憶癥，無法將會話信息從一個請求保留到下一個請求。而且，只是對目標服務地址進行了均衡，無法考慮請求處理的負載強度進行均衡，同時容錯性較差。支持DNS 負載均衡的服務商有AWS Route 53 以及dnspod。

HTTP 負載均衡

負載均衡解決的是性能問題，要先了解單個服務器的狀況。一般地，nginx 的應答率比Apache 高，所以，有時更換Web 服務器就可以提高性能。

提高Apache Http的方法有禁用空載模塊，禁用DNS查詢，采用壓縮模塊，不使用SymLinksIfOwnerMatch選項，并且在Directory選項中啟用FollowSymLinks，等等。

Nginx本身就是高性能的，但可以通過worker_processes 和worker_cpu_affinity調(diào)整來匹配服務器的硬件平臺，還可以對壓縮進行區(qū)分對待，使用其緩存的能力。例如

Http{ gzip on; gzip_static on; gzip_comp_level 2; gzip_types application/javascript;}

HTTP的負載均衡相當于7層負載均衡，不論Apache 還是 Nginx 都可以充當HTTP的負載均衡器。

以基于權(quán)重的負載均衡為例，可以配置Nginx把請求更多地分發(fā)到高配置的后端服務器上，把相對較少的請求分發(fā)到低配服務器。配置的示例如下：

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層，可以對做正則規(guī)則處理(如針對域名、目錄進行分流等) ，配置簡單，能ping通就能進行負載功能，可以通過端口檢測后端服務器狀態(tài)，不支持url檢測。Nginx 負載均衡抗高并發(fā)，采用epoll網(wǎng)絡模型處理客戶請求，但應用范圍受限。

數(shù)據(jù)庫負載均衡

數(shù)據(jù)庫負載均衡的一般用法是從讀寫分離開始的，因為一般的應用都是讀多寫少的緣故吧。將數(shù)據(jù)庫做成主從，主數(shù)據(jù)用于寫操作，從數(shù)據(jù)庫用于讀操作，事務一般在主庫完成。

數(shù)據(jù)庫集群是數(shù)據(jù)庫負載均衡的典型方式，集群管理服務器作為負載均衡器，例如 MySQL cluster。

更簡單的方式是通過Haproxy 來完成負載均衡的調(diào)度。

HAProxy能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作，支持url檢測后端的服務器，對于問題的排查會有很好的幫助。

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

網(wǎng)絡連接的負載均衡

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

LVS抗負載能力強，使用IP負載均衡技術(shù)，只做分發(fā)，所以LVS本身并沒有多少流量產(chǎn)生。 LVS的穩(wěn)定性和可靠性都很好應用范圍比較廣，可以對所有應用做負載均衡，缺陷是不支持正則處理，不能做動靜分離。

通過LVS+Keepalived構(gòu)建的LVS集群，LVS負載均衡用戶請求到后端服務器，Keepalived的作用是檢測web服務器的狀態(tài)，如果有一臺web服務器死機，或工作出現(xiàn)故障，Keepalived將檢測到，并將有故障的web服務器從系統(tǒng)中剔除，當web服務器工作正常后Keepalived自動將web服務器加入到服務器群中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復故障的web服務器。

下圖是Keepalived的原理圖：

SSL負載均衡

信任是互聯(lián)網(wǎng)的基石，出于安全性的考量，服務中往往需要SSL的連接。SSL 有兩種認證方式：雙向認證 SSL 協(xié)議要求服務器和用戶雙方都有證書;單向認證 SSL 協(xié)議不需要客戶擁有CA證書。一般Web應用，配置SSL單向認證即可。但部分金融行業(yè)用戶的應用對接，可能會要求對客戶端(相對而言)做身份驗證。這時就需要做SSL雙向認證。

SSL 屬于應用層的協(xié)議，所以只能在 7 層上來做，而 HAProxy 也是支持 SSL 協(xié)議的，所以一種方式是只需簡單的讓 HAProxy 開啟 SSL 支持完成對內(nèi)解密對外加密的處理, 但引入 SSL 處理是有額外的性能開銷的(如上面談到的認證), 所以 一般采用SSL proxy farm， 典型的架構(gòu)如下：

壓力和負載測試

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

負載測試是模擬實際軟件系統(tǒng)所承受的負載條件的系統(tǒng)負荷，通過不斷增加負載載(如逐漸增加模擬用戶的數(shù)量)或其它加載方式來觀察不同負載下系統(tǒng)的響應時間和數(shù)據(jù)吞吐量、系統(tǒng)占用的資源等，以檢驗系統(tǒng)的行為和特性，并發(fā)現(xiàn)系統(tǒng)可能存在的性能瓶頸、內(nèi)存泄漏、不能實時同步等問題。

負載測試更多地體現(xiàn)了一種方法或一種技術(shù)。壓力測試是在強負載(大數(shù)據(jù)量、大量并發(fā)用戶等)下的測試，查看應用系統(tǒng)在峰值使用情況下操作行為，從而有效地發(fā)現(xiàn)系統(tǒng)的某項功能隱患、系統(tǒng)是否具有良好的容錯能力和可恢復能力。壓力測試分為高負載下的長時間(如24小時以上)的穩(wěn)定性壓力測試和極限負載情況下導致系統(tǒng)崩潰的破壞性壓力測試。

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

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

云服務的負載均衡

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

特別的，qingcloud 的vpc 也是挺有特點的，私有網(wǎng)絡 用于主機之間互聯(lián)，類似于使用交換機(L2 Switch)自組局域網(wǎng)。彈性IP還好，管理路由器就顯得很貼心了。

AWS 的負載均衡還是業(yè)界典范，官方給出的示意圖如下：

高可用性

高可用性是負載均衡帶來的另一價值, 即負載均衡經(jīng)常被用于實現(xiàn)故障轉(zhuǎn)移。當一個或多個組件出現(xiàn)故障時，能持續(xù)提供服務的這些組件都在持續(xù)監(jiān)控中，當一個組件沒有響應，負載均衡器就會發(fā)現(xiàn)它，并不再向其發(fā)送數(shù)據(jù)。同樣當一個組件重新上線，負載均衡器會重新開始向其發(fā)送數(shù)據(jù)。

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

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

三點兩地的災備方案并不是誰都做的起的，有了云服務就顯得不那么苦難了。下面是阿里云給出的容災示意圖，多可用區(qū)部署，機房宕機后，仍能正常工作。

系統(tǒng)的監(jiān)控在系統(tǒng)高可用性上作用很大，個人推薦zabbix。

總體來看， 負載均衡是系統(tǒng)架構(gòu)和DevOps 中的重要技術(shù)，對系統(tǒng)性能影響巨大。當然，如果有更高需求的話，就需要考慮硬件的負載均衡方案了，比如說F5。

【本文來自51CTO專欄作者老曹的原創(chuàng)文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】