Spring Cloud Ribbon是一個基於HTTP和TCP的客戶端負載均衡工具，基於Netflix Ribbon實現。
下面我們來看看在 Ribbon 中都提供了哪些負載均衡的策略實現。
RandomRule
該策略實現從服務實例名單中隨機選擇一個服務實例的功能。根據選擇邏輯的實現， 正常情況下每次選擇都應該選出一個服務實例， 如果出現死循環獲取不到服務實例時，則很有可能存在併發的 Bug。
RoundRobinRule
該策略按照線性輪詢的方式選擇服務實例。該策略實現與 RandomRule 類似，在循環條件中增加了一個 count 計數器，如果一直選擇不到服務實例持續10次，則結束嘗試。
RetryRule
該策略具備重試機制的實例選擇功能。其中實現了對內部定義的策略進行反覆嘗試的策略， 若期間能夠選擇到具體的服務實例就返回，若選擇不到就根據設置的嘗試直到結束時間，結束時間爲閾值（maxRetryMillis 參數定義的值 + choose 方法開始執行的時間戳），當超過該閾值後就返回 null。
WeightedResponseTimeRule
對 RoundRobinRule 的擴展，增加根據實例運行情況來計算權重，根據權重選擇服務實例，以達到最有分配效果。它的主要實現包含三個內容：
-
定時任務：通過設定定時任務計算服務實例權重，默認 30 秒執行一次。
-
權重計算：通過 List 維護負載均衡器維護的服務實例清單中所有實例的權重值。
權重計算規則：weightSoFar + totalResponseTime - 實例的平均響應時間，其中 weightSoFar 初始化爲零， 並且每計算好一個權重需要累加到 weightSoFar 上供下一次計算使用。這裏計算的權重值只表示每個服務實例的權重區間的上限，並不是實例優先級。
ETC: 假設有4個實例A、 B、 C、 D , 它們的平均響應時間爲10、40、 80、100, 所以總響應時間是10 + 40 + 80 + 100 = 230, 每個實例的權重爲總響應時間與實例自身的平均響應時間的差的累積所得，所以實例A、B、C、D 的權重分別如下所示。
- 實例A: 230-10 = 220
- 實例B: 220 + (230 - 40) = 410
- 實例C: 410 + (230 - 80) = 560
- 實例D: 560 + (230 - 100) = 690
因此所得實例區間：
- 實例 A ：[0, 220]
- 實例 B ：(220, 410]
- 實例 C ：(410， 560]
- 實例 D ：(560， 690)
實際上每個區間寬度是：總的響應時間 - 實例平均響應時間，所以平均響應時間越短，權重區間越大，被選中的機率也越大。
-
實例選擇
ClientConfigEnabledRoundRobinRule
該策略的實現功能與 RoundRobinRule 相同，一般不直接使用它。雖然我們不會直接使用該策略，但是通過繼承該策略，默認的 choose 就實現了線性輪詢機制，在子類中做一些高級策略時通常有可能會存在一些無法實施的情況，那麼就可以用父類的實現作爲備選。
BestAvailableRule
該策略繼承自 ClientConfigEnabledRoundRobinRule ，在實現中它注入了負載均衡器的統計對象LoadBalancer-Stats，同時在具體的 choose 算法中利用 LoadBalancerStats 保存的實例統計信息來選擇滿足要求的實例。它通過遍歷負載均衡中維護的所有服務實例，會過濾掉故障的實例，並找出併發請求數最小的一個實例，所以此策略是選擇最空閒的一個服務實例。此策略實現的核心依據是 LoadBalancerStats ，當 LoadBalancerStats 爲空的時候策略無法執行，會採用父類的線性輪詢策略。
PredicateBasedRule
先通過子類中實現的 Predicate 邏輯來過濾一部分服務實例， 然後再以線性輪詢的方式從過濾後的實例清單中選出一個。
AvailaiblityFilteringRule
該策略繼承自上面介紹的抽象策略 PredicateBasedRule ，所以它也繼承了 “先過濾清單，再輪詢選擇”的基本處理邏輯。它主要判斷服務實例的兩項內容：
- 是否故障，即斷路器是否生效已斷開
- 實例的併發請求數大於闕值，默認值爲 2^32 - 1，可通過 application.properties 文件配置。