日常開發和學習中經常會聽到或者會看到“負載均衡”這個詞匯，但是對於很多初級每天只面對增刪改代碼的開發人員來說，這個詞匯好像離我們很遙遠又很接近，很多人多多少少都有點一知半解
我結合以前在開發中遇到的場景和通過查閱相關資料來簡單了解一下詞匯之一 ——“負載均衡”
負載均衡的基本理解以及基本概念：
簡單理解：如果你是第一次聽到這個詞，那么你可以這樣簡單的去理解——負載均衡是什么？答：它是一種的技術，具有很多實現方式，可以從軟件（niginx等）或者硬件（負載均衡器）上去實現。負載均衡有啥用？答：主要作用就是用來提升服務器性能，可以處理更多的請求和更大量的數據
基本概念：將負載進行平衡，負載均衡是高可用網絡基礎架構的的一個關鍵組成部分，負載均衡（Load Balance）其意思就是將多個相同功能或者相似功能的服務（如web服務，ftp服務，企業關鍵應用服務等）分攤到多個操作單元上進行執行，共同完成工作任務。
單純從上面的概念去理解負載均衡肯定會讓人有點懵。我們不如先來看一看傳統不使用負載均衡的傳統服務器架構，然后在對比學習使用了負載均衡各種的架構，這樣你可能就會對負載均衡這一概念會有更好的理解。
1 傳統服務器簡單架構
1.1 傳統服務器簡單架構：
傳統服務器架構流程：
1）瀏覽器通過DNS-server，域名解析到ip
2）瀏覽器通過ip訪問web-server
3）web-server處理訪問數據庫數據處理數據並返回到瀏覽器
如圖：
我們常規小型項目可能如上圖一樣只有一台web服務器加上一台數據庫服務器，有的甚至只有一台服務器，所有的web服務，緩存服務，數據庫服務，上傳下載服務等等全都放在一台服務器上面，這樣缺陷顯然很明顯
1：單台服務器面對大量請求和高並發場景會有性能問題；
2：服務一但掛掉會使所有的功能都將無法使用；
3：單台服務器不便於多人維護；
4：單台服務直接暴露后台服務器IP安全也會相對較差
所以需要使用到負載均衡來多個服務器分攤請求和處理上面一系列問題
2 常見的實現負載均衡方案
2.1 DNS輪詢實現負載均衡
那我們可以在上面的服務器架構做一些簡單的優化：用DNS輪詢實現簡單的負載均衡，具體操作如下
1）瀏覽器通過DNS-server，域名解析到ip，這一步我們可以給DNS-server添加多條解析記錄綁定多個服務器IP，然后通過配置記錄的權重來實現負載均衡
2）瀏覽器通過ip訪問web-server
3）web-server處理訪問數據庫數據處理數據並返回到瀏覽器
如圖：
具體實際操作我們以騰訊雲服務器為例，我們先添加兩條主機記錄
然后我們在負載均衡界面配置權重，這樣我們就完成了通過DNS輪詢來實現負載均衡，有一點需要注意的是：同記錄類型、同主機記錄、同線路的記錄才可以實現解析的負載均衡
DNS輪詢實現負載均衡的優缺點：
優點：
- 零成本：只是在DNS服務器上綁定幾個A記錄，域名注冊商一般都免費提供解析服務；
- 部署簡單：就是在網絡拓撲進行設備擴增，然后在DNS服務器上添加記錄。
缺點：
- 可靠性低：假設一個域名DNS輪詢多台服務器，如果其中的一台服務器發生故障，那么所有的訪問該服務器的請求將不會有所回應，這是任何人都不願意看到的。即使從DNS中去掉該服務器的IP，但在Internet上，各地區電信、網通等寬帶接入商將眾多的DNS存放在緩存中，以節省訪問時間，DNS記錄全部生效需要幾個小時，甚至更久。所以，盡管DNS輪詢在一定程度上解決了負載均衡問題，但是卻存在可靠性不高的缺點。
- 負載分配不均勻（有，但不會有那么大的影響）：DNS負載均衡采用的是簡單的輪詢算法，不能區分服務器的差異，不能反映服務器的當前運行狀態，不能做到為性能較好的服務器多分配請求，甚至會出現客戶請求集中在某一台服務器上的情況。DNS服務器是按照一定的層次結構組織的，本地DNS服務器會緩存已解析的域名到IP地址的映射，這會導致使用該DNS服務器的用戶在一段時間內訪問的是同一台Web服務器，導致Web服務器間的負載不均勻。此外，用戶本地計算機也會緩存已解析的域名到IP地址的映射。當多個用戶計算機都緩存了某個域名到IP地址的映射時，而這些用戶又繼續訪問該域名下的網頁，這時也會導致不同Web服務器間的負載分配不均勻。負載不均勻可能導致的后果有：某幾台服務器負荷很低，而另幾台服務器負載很高、處理緩慢；配置高的服務器分配到的請求少，而配置低的服務器分配到的請求多。
- 暴露了太多的外網ip
通過上面的DNS輪詢實現負載均衡是不是對負載均衡這一概念有了簡單的理解，但是我們可以看到DNS輪詢實現負載均衡有很多的缺點，那么我們還有其他的負載均衡方案嗎？
2.2 nginx反向代理實現負載均衡
首先需要搞懂什么是反向代理，可以參考我之前寫的這篇文章里面的相關資料:https://www.cnblogs.com/ruanraun/p/agent.html
具體流程：
1）瀏覽器通過DNS-server，域名解析到代理服務器IP
2）瀏覽器通過ip訪問代理服務器web-server
3）代理服務器web-server根據配置文件分發請求給實際真實的后端服務器
4) 后端實際web-server處理訪問數據庫數據處理數據並返回到代理服務器，最后通過代理服務器返回給瀏覽器
反向代理實現負載均衡的優缺點：
優點：
1）DNS-server不需要動
2）負載均衡：通過nginx來保證
3）只暴露一個外網ip，nginx->tomcat之間使用內網訪問
4）擴容實時：nginx內部可控，隨時增加web-server隨時實時擴容
5）能夠保證站點層的可用性：任何一台tomcat掛了，nginx可以將流量遷移到其他tomcat
缺點：
1）時延增加+架構更復雜了：中間多加了一個反向代理層
2）反向代理層成了單點，非高可用
3）負載能力受服務器本身性能的影響，所有請求響應都需要經過負載均衡服務器，集群最大吞吐量受限於負載均衡服務器網卡帶寬，性能越好，負載能力越大。
4）通過代理服務器返回請求結果而不是實際服務器直接返回請求結果也會有性能上的損耗
2.3 LVS調度實現負載均衡
LVS與nginx在處理請求上面的區別，如下：
LVS：Linux 虛擬機、流量調度，負載均衡
單向的 End user -----> LVS ----->應用集群web-server（如 tomcat或IIS） -----> End user
nginx：高性能代理服務器，系統內部流量分發，反向代理
有來回 End user -----> Ngnix -----> 應用集群web-server（如 tomcat或IIS） -----> Ngnix -----> End user
由於請求處理流程的簡化，LVS直接將請求結果返回給客戶端而不是像nginx還要返回給代理服務器然后再返回給客戶端，所以同量級別的服務器和帶寬LVS抗負載能力肯定是比nginx是要強的
下面是 LVS DR模式直接路由實現負載均衡
數據分發時， 不修改ip地址，只修改目標mac地址，配置真實物理服務器集群所有機器虛擬ip和負載均衡服務器ip地址一致，達到不修改數據包的源地址和目標地址，進行數據分發的目的。
實際處理服務器ip和數據請求目的ip一致，不需要經過負載均衡服務器進行地址轉換，可將響應數據包直接返回給用戶瀏覽器，避免負載均衡服務器網卡帶寬成為瓶頸。
- 配置性低，這里的配置性低不是配置簡單，而是一旦配置好之后不會經常去動它，這通常是一大劣勢同時也是一大優勢，因為沒有太多的可配置的選項，所以除了增減服務器，並不需要經常去觸碰它，大大減少了人為出錯的幾率
- 工作穩定，因為其本身抗負載能力很強，所以穩定性高也是順理成章的事，另外各種 LVS 都有完整的雙機熱備方案，所以一點不用擔心均衡器本身會出什么問題，節點出現故障的話，LVS 會自動判別，所以系統整體是非常穩定的
- 無流量，LVS 僅僅分發請求，而流量並不從它本身出去，所以可以利用它這點來做一些線路分流之用。沒有流量同時也保住了均衡器的 IO 性能不會受到大流量的影響
- LVS 基本上能支持所有應用，因為 LVS 工作在第 4 層，所以它可以對幾乎所有應用做負載均衡，包括 http、數據庫、聊天室等
缺點：
- 安裝配置是比nginx復雜
- 對網絡依賴性高，所以很多配置失敗一般都是網絡的問題
- 如果僅僅使用 lvs 作為負載均衡的話，一旦后端接受到請求的服務器出了問題，那么這次請求就失敗了，不能像nginx那樣流量遷移
- nginx 工作在網絡的第 7 層，可以作為網頁靜態服務器，而LVS工作在網絡的第 4 層，固不能針對上層協議分析，處理請求場景比相對nginx少，沒有nginx靈活
2.4 負載均衡器硬件實現負載均衡
直接在服務器和外部網絡間安裝負載均衡硬件設備，這種設備我們通常稱之為負載均衡器。由專門的設備完成，獨立於操作系統，整體性能得到大量提高，加上更多的負載均衡策略，智能化的流量管理，可達到最佳的負載均衡需求。 一般來說，硬件負載均衡在功能、性能上優於軟件方式，不過成本昂貴，幾十萬到上百萬不等，適合不差錢的土豪公司，很常見的有 F5負載均衡器：
通過F5平衡負載的去訪問服務器群的每台機器。訪問過程如下圖所示
硬件實現負載均衡優缺點：
優點：能夠直接通過智能交換機實現,處理能力更強，性能應該是最優的，而且與系統無關，負載性能強更適用於一大堆設備、大訪問量、簡單應用
缺點：成本高，貴貴貴，重要的事情說三遍，幾十萬甚至幾上百萬對於一些一個項目做下來還掙不到這么多錢的小型企業來說也不是小數目，除設備價格高昂之外，它的配置相對復雜冗余，而且很難想象后面服務器做一個集群，但最關鍵的負載均衡設備卻是單點配置;無法有效掌握服務器及應用狀態，硬件負載均衡，一般都不管實際系統與應用的狀態，而只是從網絡層來判斷，所以有時候系統處理能力已經不行了，但網絡可能還來得及反應(這種情況比較典型，比如應用服務器后面內存已經占用很多，但還沒有徹底不行，如果網絡傳輸量不大就未必在網絡層能反映出來)
上面總結這這么多負載均衡的處理方案，貌似都有各自的優點和缺點，那么就沒有最優解嗎？
3 混合型負載均衡
最優解就是把上面的負載均衡方案混合起來，由於多個服務器群內硬件設備、各自的規模、提供的服務等的差異，可以考慮給每個服務器群采用最合適的負載均衡方式，然后又在這多個服務器群間再一次負載均衡或群集起來以一個整體向外界提供服務（即把這多個服務器群當做一個新的服務器群），從而達到最佳的性能。將這種方式稱之為混合型負載均衡。
我們可以根據自己開發的實際情況合理的進行混合方案
如圖是混合型負載均衡的一種：
流程：
1）通過DNS輪詢來線性擴展入口lvs層的性能
2）通過keepalived來保證高可用
3）通過lvs來擴展多個nginx
4）通過nginx負載均衡，業務七層路由，來分發請求，最大限度的提高單次請求的成功率；
總結：
基礎擴展：
負載均衡算法決定了后端的哪些健康服務器會被選中。下面是幾個常用的算法，這里只是簡單介紹，不具體研究其算法實現了：
- 輪詢：為第一個請求選擇健康池中的第一個后端服務器，然后按順序往后依次選擇，直到最后一個，然后循環。
- 最小連接：優先選擇連接數最少，也就是壓力最小的后端服務器，在會話較長的情況下可以考慮采取這種方式。
- 散列：根據請求源的 IP 的散列（hash）來選擇要轉發的服務器。這種方式可以一定程度上保證特定用戶能連接到相同的服務器。如果你的應用需要處理狀態而要求用戶能連接到和之前相同的服務器，可以考慮采取這種方式。
實戰配置和nginx的請求原理學習
https://www.cnblogs.com/jiekzou/p/4486447.html
https://juejin.im/post/5821c24e570c350060bef4c3
LVS相關資料
https://superproxy.github.io/docs/lvs/index.html
有軟件負載均衡，也有硬件負載均衡，選擇哪個： https://cloud.tencent.com/developer/news/343236