老曹眼中的負載均衡
什么是負載均衡
負載(load)一詞起源于典型系統，指連接在電路中消耗電能的裝置，負載(用電器)的功能是把電能轉變為其他形式能。引申出來，一個是實體，一個轉化。
于是，對于實體，有了通信幀或者報文中數據字段的內容被稱為信息負載(payload)，網絡負載指的就是網絡中繼承載的流量以及網絡設備承載的用戶量。
轉化被進一步闡釋為資源的使用情況，操作系統的平均負載是CPU的Load 即workload，它所包含的信息不是CPU的使用率狀況，而是在一段時間內CPU正在處理以及等待CPU處理的進程數之和的統計信息。
了解了負載，那么負載均衡就容易理解了。wiki百科給出的定義是這樣的：
負載均衡(Load balancing)是一種計算機網絡技術，用來在多個計算機(計算機集群)、網絡連接、CPU、磁盤驅動器或其他資源中分配負載，以達到最佳化資源使用、最大化吞吐率、最小化響應時間、同時避免過載的目的。使用帶有負載平衡的多個服務器組件，取代單一的組件，可以通過冗余提高可靠性。負載平衡服務通常是由專用軟件和硬件來完成。
并且，wiki百科自身的系統就使用了負載均衡, 后段系統使用了elasticsearch。
每一種技術都有它應用的場景和領域，負載均衡主要解決的是系統性能問題。但是，了解了根源，就可以知道不能夠一提到性能問題就非負載均衡莫屬，如果負載減少了，可能少一點均衡也可以解決問題，這樣的技術例如緩存。
基于DNS的負載均衡
基于DNS的負載均衡是負載均衡的最簡方法，可以說是窮人的負載均衡。
DNS會將域名映射為IP地址，反之亦然。所有核心DNS服務器都是集群，用的最多的DNS服務器大概就是BIND了。查詢DNS服務器時，推薦使用dig;查詢DNS解析時，推薦使用nslookup。 使用DNS緩存可以提高DNS解析的性能。Dig 在mac上的使用示例如下：
對于DNS實現的負載均衡非常簡單，采用輪轉的方式，只要為所要服務的域名增加多個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的負載均衡簡單，易于調試且容易擴展。缺陷在于它有慢性失憶癥，無法將會話信息從一個請求保留到下一個請求。而且，只是對目標服務地址進行了均衡，無法考慮請求處理的負載強度進行均衡，同時容錯性較差。支持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 服務器的負載性能。
云服務的負載均衡
云時代的到來，使負載均衡成了平臺級的服務，幾乎所有的云服務提供商都提供了負載均衡服務。下面是阿里云的負載均衡基礎框架圖：
特別的，qingcloud 的vpc 也是挺有特點的，私有網絡 用于主機之間互聯，類似于使用交換機(L2 Switch)自組局域網。彈性IP還好，管理路由器就顯得很貼心了。
AWS 的負載均衡還是業界典范，官方給出的示意圖如下：
高可用性
高可用性是負載均衡帶來的另一價值, 即負載均衡經常被用于實現故障轉移。當一個或多個組件出現故障時，能持續提供服務的這些組件都在持續監控中，當一個組件沒有響應，負載均衡器就會發現它，并不再向其發送數據。同樣當一個組件重新上線，負載均衡器會重新開始向其發送數據。
SLA 作為高可用性的指標，一般有3個時間標準：99.9%,99.99%,99.999%. 表示不間斷運行的離線時間不超過：
- 3個9： 8.76 小時
- 4個9：52.26 小時
- 5個9：5.26 分鐘
三點兩地的災備方案并不是誰都做的起的，有了云服務就顯得不那么苦難了。下面是阿里云給出的容災示意圖，多可用區部署，機房宕機后，仍能正常工作。
系統的監控在系統高可用性上作用很大，個人推薦zabbix。
總體來看， 負載均衡是系統架構和DevOps 中的重要技術，對系統性能影響巨大。當然，如果有更高需求的話，就需要考慮硬件的負載均衡方案了，比如說F5。
【本文來自51CTO專欄作者老曹的原創文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】
