負載均衡方式的對比選擇
- 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開銷，多此一舉，比單機並發量還低，得不償失。
