負載均衡方式的對比選擇
- 2019 年 12 月 15 日
- 筆記
寫在前面
負載均衡，並不是人人平等。而是每個人都盡其所能，得其所需。
每個伺服器的配置會有差異，可能某個伺服器還需要兼顧其他應用服務。所以它也許不能像同集群里的其他機器一樣完成一樣大小的任務。
通過某種負載分擔技術，將外部發送來的請求均勻分配到對稱結構中的某一台伺服器上，而接收到請求的伺服器獨立地回應客戶的請求。均衡負載能夠分配客戶請求到伺服器列陣，藉此提供快速獲取重要數據，解決大量並發訪問服務問題。
負載均衡主要解決的問題
- 處理高並發等服務，單機並發量不足以支撐，利用負載均衡分攤到多台伺服器。
- 提高用戶響應，如果單機一直保持高負載運行，假設最多處理1K個並發，第1K個也需要排隊等候處理。分攤到多台機器，增加處理者，平均響應速度也就提升了。
負載均衡的幾種實現方式
- 硬體實現
- DNS負載均衡
- Linux Virtual Server(LVS)負載均衡
- 反向代理負載均衡
硬體實現
從網上的資料找到的主要是F5這一方面的介紹，具體也可以在這篇百度百科中看看方案：
我主要講講其中我理解的一個比較貼合本篇主題的點：
鏈接聚合
每個人訪問網站都會建立一個TCP連接，這個TCP連接是不斷建立又關閉的，當快速建立又關閉的時候，對伺服器的壓力很大。而且伺服器能夠維持的並發連接是有限的，比如IIS伺服器，它的標準並發連接是2048個，阿帕奇伺服器是1024個，如果一個網站有幾萬個並發連接，單個伺服器就崩潰了。但是把這些短連接匯聚到一起，集中F5的設備上，通過F5與伺服器建立平滑的長連接，就解決了不斷增大的並發連接。比如說前台有15萬個並發連接，經過F5的優化，在伺服器上只有不到5000個並發連接，而且在此過程中，每個人的請求是不會被丟掉的。
F5方案中還有其他幾個點可以加速應用，有興趣的小夥伴可以去看看了解一下。
DNS負載均衡
首先簡單講一下我們訪問網站的過程（不一定準確 大概流程如此）
1.瀏覽器輸入網址回車,瀏覽器判斷自己是否有快取該域名指向哪台伺服器Ip 2.若沒有瀏覽器快取，則查詢系統hosts配置 3.系統配置則提交網卡,發送到路由器,路由器也可能快取 4.路由器也沒有,發送到網路運營商的dns伺服器查詢 5.運營商也沒有快取,再向域名解析伺服器發送請求查詢 6.查詢到指向ip,原路返回,發送http請求
如果我們在域名解析伺服器上配置dns負載均衡，則可以實現不同用戶的請求打到不同的伺服器上，從而出現請求分攤處理。
策略：輪詢、距離就近、權重設置等等
LVS負載均衡
LVS的全稱是Linux Virtual Server，主要有三種策略方案
- LVS-NAT
- LVS-DR
- LVS-TUN
舉例一下LVS-DR 在這種方案中，域名解析是指向一台中轉伺服器。
1.用戶請求到中轉伺服器 2.中轉伺服器不做任何解析和判斷，只修改數據包的目標IP地址為同一區域網的其他網卡IP(關於此處，可以查看網路OSI模型的百度百科，網路請求的傳遞等等。)，然後發給路由器中轉 3.假設上一步驟的目標網卡IP是同一條寬頻(內網)A機器，則A機器收到用戶請求數據，解析執行，然後返回數據給路由器（目標ip是客戶端的ip），路由器再發給外網返回客戶。
反向代理負載均衡
經常聽到的是nginx負載均衡，nginx的反向代理也是一個很重要的模組，也自帶了負載均衡的配置支援
用戶請求到nginx中轉伺服器，然後根據配置的不同策略分配到集群內其他機器。
客戶端與中轉伺服器比較常見是建立長鏈接。 中轉伺服器與集群內其他處理伺服器一般是建立短鏈接。
1.用戶請求到中轉伺服器 2.中轉伺服器做一些記錄和分配判斷等，然後通過TCP鏈接轉發到集群其他機器， 3.集群的機器都是完整的應用，可以提供完整的服務，此時相當於有一個客戶端直接請求過來(該客戶端是nginx中轉伺服器這台電腦)，處理 輸出結果 4.中轉伺服器拿到結果，再進行一些記錄和處理，返回給用戶。
總結
負載均衡有幾種不同思路的方案。
需要根據自己的用戶體系、業務邏輯做選擇合適方案。
反向代理負載均衡適用集群內，如果外網機器反向代理，則需要巨大的網路IO開銷，多此一舉，比單機並發量還低，得不償失。
