上一個章節，我們搭建了一個最簡單的單體服務專案，單體架構就是把所有的功能都放在一個工程專案中，
但是當訪問量不斷增加，我們只部署一套環境就有些吃不消了，這時候有什么解決方案么？
如果我們去一個超市購物，當客戶數量不多的時候，超市只開通一個結賬通道就可以滿足需要，但是當客戶數量增加，只有一個結賬通道的話，會造成客戶等待時間過長，最簡單的解決方法就是多開幾個結賬通道，
在軟體架構中也會有相似的問題：
如果專案的用戶量少、訪問量不大、資料量也不多的時候，一臺服務器足以支撐，那么直接專案部署一套，直接訪問使用就可以了，但是當用戶和資料量不斷增多，訪問量（并發量）不斷增加，一臺服務器不在能夠支撐業務的時候，就需要使用多臺機器，設計高性能的集群來應對，
那么當我部署了多臺服務器（這里假如是兩臺），那么呼叫方是如何訪問的呢？服務方如何均衡訪問的流量呢？這時候就需要引出負載均衡了，
負載均衡就是通過一定的策略，把用戶的訪問量均勻地轉發給后端的服務器；負載均衡可以提高系統的服務能力和高可用性，
1. 負載均衡分類
1.1 按照型別分類
1. DNS 負載均衡
大概的原理是，當用戶訪問域名的時候，需要先通過 DNS 決議域名，找到對應的 IP 地址，在這個程序中，可以讓 DNS 服務器，根據用戶的地理位置，回傳不同的 IP，這樣就可以實作負載均衡，同時也可以提升用戶的訪問速度，
2. 軟體負載均衡
用軟體來實作流量的分發，有基于傳輸層實作的負載均衡，比如 LVS，也有基于應用層來實作的，比如 Nginx；軟體負載均衡實作起來很簡單，只需要在服務器上部署并進行配置就可以實作；
3. 硬體負載均衡
用硬體來實作負載均衡，比如F5（F5 Network Big-IP），這是一臺網路設備，性能很高，同時價格非常的貴，
1.2 按照誰來負載進行分類
1. 服務端負載均衡
呼叫方只訪問負載均衡的IP，不需要管后面有多少臺服務器，
服務端負載均衡有點兒像我們打客服電話，很多人可以同時撥打同一個客服電話號碼，我們不關心實際上有多少個客服，也不關心是哪個客服人員接聽電話，
2. 客戶端負載均衡
服務端部署多臺服務器，客戶端知道每臺服務器的地址，并通過一定的路由規則，均衡地訪問，比如 Spring Cloud Ribbon，當然客戶端的負載均衡，通常是需要服務注冊發現的配合，
客戶端負載均衡更像是去超市購物結賬，我們可以看到有幾個結賬柜臺，我們可以自己選擇在哪個柜臺結賬，
我們會在后面的章節中，詳細介紹 Spring Cloud 中的客戶端負載均衡組件 Ribbon ，
1.3 按照網路模型分類
最常用的網路模型 OSI 模型共有 7 層結構：
1. 二層負載均衡
基于資料鏈路層的負載均衡；讓負載均衡服務器和應用服務器系結同一個虛擬 IP，客戶端通過這個虛擬 IP 進行請求，負載均衡服務器接受到請求后，再根據 MAC 地址進行分配轉發，
2. 三層負載均衡
基于網路層的負載均衡；也是采用虛擬 IP 的方式，不過負載均衡服務器在接收到到請求后，按照實際 IP 進行分配轉發，
3. 四層負載均衡
基于 IP + port 的負載均衡；用 IP + port 接受請求，再轉發到后臺的應用服務器上，
比如 TCP 應用實體，負載均衡服務器在接受到第一個 SNY 請求時（建立連接請求），會通過負載均衡演算法找到服務器 A，然后將報文中的目標 IP 修改成服務器 A 的 IP，然后轉發給服務器 A；
這就好像我們去銀行辦理業務，先領一個號之后（建立連接請求），銀行的叫號系統會通知你：“請 101 號到 3 號視窗辦理業務”（轉發你的請求給 3 號服務器），真正辦理業務的是 3 號視窗的小姐姐，
在這個程序中，負載均衡服務器相當于一個路由器，
4. 七層負載均衡
基于虛擬 URL 或主機 IP 的負載均衡；七層就是應用層，支持多種應用協議，比如 HTTP、FTP 等等，七層負載均衡服務器可以根據請求報文中的真正有意義的內容，加上負載均衡演算法，來選擇轉發到哪個應用服務器；因此七層負載均衡服務器也被稱為“內容交換機”；
比如七層負載均衡服務器，將圖片類的請求轉發到圖片服務器，將文字內容類的請求轉發到應用服務器；
這就好像我們去銀行辦理業務，在領號的時候，大廳經理看看你的銀行卡，普通卡給一個 B101，金卡給一個 A101，如果是理財業務，那么就領你去理財視窗，這就相當于根據你的具體業務或銀行卡型別（報文），講請求轉發到不同的服務器，
在這個程序中，負載均衡服務器相當于一個代理服務器，
2. 常用負載均衡工具
2.1. LVS
四層負載均衡；LVS 是使用Linux內核集群實作一個高性能、高可用的負載均衡服務器；性能比較強，有完整的雙機熱備方案，如 LVS + Keepalived；因為四層負載均衡只分發請求，所以 LVS 的 IO 性能不會受到流量影響，
2.2 Nginx
七層負載均衡；因為是七層，所以可以針對 HTTP 做一些分流策略，Nginx 的正則規則更加強大和靈活；Nginx 的安裝、配置和測驗都比較簡單；可以承擔高負載壓力，不過會比 LVS 稍差；Nginx 還可以檢測后端應用服務器的運行情況，可以根據處理請求的狀態碼或超時，把錯誤的請求提交到另外的服務節點；
Nginx 支持 HTTP, HTTPS, SMTP, POP3, IMAP 等協議，在較高的版本中開始支持 TCP 協議，
2.3 HAProxy
七層負載均衡；單純從性能上看，HAProxy 比 Nginx 有更出色的速度，在并發處理上也是優于 Nginx 的；HAProxy 支持 TCP 協議，比如可以對 MySQL 的讀操作進行負載均衡，
3. 常見的負載均衡調度演算法
3.1 輪詢法
輪詢法就是按照順序把請求輪流分配到每臺服務器上；
輪訓法簡單高效，易于水平擴展，不過因為只求平均，不關心每臺服務實際的負載；所以如果某一臺服務器性能不好，極有可能產生木桶效應，
3.2 隨機法
隨機分配請求到每臺服務器上，如果請求數量足夠多，從概率學角度看，實際效果會接近平均分配，
3.3 隨機輪詢法
隨機法和輪詢法相結合，隨機找到一個服務器作為起點，然后開始輪詢發送請求，(隨機只體現在尋找第一個服務器的時候，剩余的作業和輪訓法一樣)
3.4 源地址哈希法
對客戶端的 IP 地址進行哈希運算得到一個值 X，服務器數量為 N，通過 X % N 的結果，決定訪問哪臺服務器，
地址哈希法可以讓相同的 IP 每次都落在同一臺服務器上，這樣不需要考慮 Session 共享的問題，但是可能會導致流量的分布不均勻，并且當某一臺服務器出現故障，會導致這個服務器上的客戶端無法使用，無法保證集群的高可用，
3.5 加權輪詢法
加權輪詢法是對輪詢法的一個改進，因為每臺服務器的配置不一樣，所以它們的抗壓能力也不一樣，配置高的機器可以分配更高的權重，這樣就可以處理更多的請求；
加權輪詢法將機器的性能也納入考量范圍，集群性能可以發揮到最大，
3.6 加權隨機法
和加權輪詢法類似；這里就不再贅述了，
3.7 最小連接數法
根據每個服務器節點的連接數，動態地選擇當前連接數最少的服務器轉發請求；
最小連接數法根據實時狀態變化進行調整，最大限度地利用每一臺機器的資源，提高集群整體的可用性；不過復雜度也高，需要計算每臺服務器的連接數量，
3.8 最快回應速度法
根據每個服務器節點的回應時間（請求的往返延遲），動態地選擇當前回應速度最快的服務器轉發請求；
和最小連接數法類似，最快回應速度法也是動態調整的，控制粒度更細，能者多勞；同時復雜度也高，需要計算每臺服務器的回應速度，
4. 總結
但是當訪問量不斷增加，只部署一臺環境有些吃不消的時候，我們可以采用部署多臺環境，通過負載均衡的方式將請求分配到不同的服務器上，以達到橫向擴展的目的，
這個在架構中就叫做【集群部署】，
在這節課，我們了解到了：
會點代碼的大叔 | 原創
【從單體架構到分布式架構】本系列文章希望用淺顯直白的語言介紹架構發展程序中遇到的各種問題，以及對應的解決方案和優缺點，
適合人群：
想從事 JavaWeb 開發的學生，建議要有一定的 Java 語言基礎；
新手程式員，想要了解現在 JavaWeb 開發比較流行的中間件和框架；
技術堆疊長期為 SSH、SSM ，但是想尋求改變的程式員，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/170360.html
標籤：Java