SpringCloud微服務系列- 服務間通訊之負載均衡
概要
負載均衡是我們處理高併發、緩解網路壓力和進行伺服器擴容的重要手段之一
負載均衡通器常有兩種實現手段，一種是服務端負載均衡器，另一種是客戶端負載均衡器。
一、負載均衡的作用
1. 服務端負載均衡
在服務叢集內設定一箇中心化負載均衡器，比如Nginx。發起服務間呼叫的時候，服務請求並不直接發向目標伺服器，而是發給這個全域性負載均衡器，它再根據配置的負載均衡策略將請求轉發到目標服務。
優缺點分析：
1）優點
服務端負載均衡應用範圍非常廣，它不依賴於服務發現技術，客戶端並不需要拉取完整的服務列表；同時，發起服務呼叫的客戶端也不用操心該使用什麼負載均衡策略。
2）缺點
網路消耗(多出了10-20ms)、複雜度和故障率提升
2. 客戶端負載均衡
Spring Cloud Loadbalancer 採用了客戶端負載均衡技術，每個發起服務呼叫的客戶端都存有完整的目標服務地址列表，根據配置的負載均衡策略，由客戶端自己決定向那臺伺服器發起呼叫。
優缺點分析：
1）優點
網路開銷小、配置靈活
2）缺點
需要滿足一個前置條件，發起服務呼叫的客戶端需要獲取所有目標服務的地址，這樣它才能使用負載均衡規則選取要呼叫的服務。
也就是說，客戶端負載均衡技術往往需要依賴服務發現技術來獲取服務列表。
3. 總結
總的來說，服務端負載均衡器的問題是，它提供了更強的流量控制權，但無法滿足不同的消費者希望使用不同負載均衡策略的需求，而使用不同負載均衡策略的場景確實是存在的，所以客戶端負載均衡就提供了這種靈活性。 然而客戶端負載均衡也有其缺點，如果配置不當，可能會導致服務提供者出現熱點，或者壓根就拿不到任何服務的情況。
二、負載均衡需要解決兩個最基本的問題
1. 從哪裡選服務例項
答案：從服務治理中心來
2. 如何選擇服務例項
透過負載均衡的策略（輪詢、ip雜湊、輪詢等）從服務例項清單列表中選擇具體例項。
比如：Eureka和Loadbalancer搭配使用，一個透過服務發現獲取服務列表，另一個使用負載均衡規則選出目標伺服器。
3. 什麼是Spring Cloud Ribbon(客戶端負載均衡器)
是Netfix釋出的負載均衡器，它有助於Http和Tcp的客戶端行為。可以根據負載均衡演算法（輪詢、隨機或自定義）自動幫助消費者請求，預設就是輪詢。
由於Spring Cloud Ribbon目前處於停更維護的狀態，所以有了替代方案：Spring Cloud Loadbalancer
4. 什麼是Spring Cloud Loadbalancer？
由於Spring Cloud Ribbon已經進入維護模式，並且Ribbon2並不與Ribbon1相互相容，所以Spring Cloud全家桶在Spring Cloud Commons 專案中，新增了Spring cloud Loadbalancer作為新的負載均衡器，並且做了向前相容，就算你的專案中繼續用Spring Cloud Netflix套裝(包括Ribbon、Eureka、Zuul、Hystrix等等)讓你的專案中有這些依賴，你也可以透過簡單的配置，把Ribbon替換成Spring Cloud LoadBalancer。
三、負載均衡策略
一、Ribbon
Ribbon 是 Spring Cloud 技術棧中非常重要的基礎框架，它為 Spring Cloud 提供了負載均衡的能力，比如 Fegin 和 OpenFegin 都是基於 Ribbon 實現的，就連 Nacos 中的負載均衡也使用了 Ribbon 框架。
Ribbon 框架的強大之處在於，它不僅內建了 7 種負載均衡策略，同時還支援使用者自定義負載均衡策略，所以其開放性和便利性也是它得以流行的主要原因。
1. RandomRule 隨機策略
2. RoundRobinRule 輪詢策略
3. RetryRule 重試策略
說明：按照輪詢策略來獲取服務，如果獲取的服務例項為 null 或已經失效，則在指定的時間之內不斷地進行重試來獲取服務，如果超過指定時間依然沒獲取到服務例項則返回 null。
4. WeightedResponseTimeRule 權重策略
這個Rule繼承自RoundRibbonRule,他會根據服務節點的響應時間計算權重，響應時間越長權重就越低，響應越快則權重越高，權重的高低決定了機器被選中機率的高低。也就是說，響應時間越小的機器，被選中的機率越大。
是對輪詢的擴充套件。
5. BestAvailableRule 最小連線數策略
應該說這個Rule有點智慧的味道了，在過濾掉故障服務以後，它會基於過去30分鐘的統計結果選取當前併發量最小的服務節點，也就是最"閒"的節點作為目標地址。如果統計結果尚未生成，則採用輪詢的方式選定節點。
6. AvailabilityFilteringRule 可用性敏感策略
兩步檢查：1. 是否處於不可用 2.節點當前的active請求連線數超過閾值
說明：每次AvailabilityFilteringRule(簡稱AFR都會請求RobinRule挑選一個節點，然後對這個節點做以下兩步檢查：是否處於不可用，節點當前的active請求連線數超過閾值，超過了則表示節點目前太忙，
不適合提供服務，如果被選中的server不幸掛掉了檢查，那麼AFR會自動重試（次數最多1O次），讓RobinRule重新選擇一個服務節點。
7. ZoneAvoidanceRule 區域敏感策略
根據服務所在區域的效能和服務的可用性選擇服務例項。在沒有區域的環境下，該策略和輪詢策略類似。
四、Spring Cloud Loadbalancer
RandomLoadBalancer 隨機 和 RoundRibbonLoadBalancer 輪詢
不指定的時候預設用的是輪詢。