Spring Cloud教程 | 第六篇：負載均衡策略配置及總結 | Feign | Ribbon
一、前言
第五篇中已介紹，feign其實不是做負載均衡的,負載均衡是ribbon的功能,feign只是集成了ribbon而已,換句話說負載均衡的功能是feign內置的ribbon在實現的。因此配置負載均衡策略即爲對ribbon進行配置。
目前公司的生產系統負載均衡、高可用等均使用集羣管理平臺Kubernetes（K8S）實現。本部門人員此部分了解即可，不指導生產使用
Spring Cloud版本 Spring Boot版本 JAVA IDE
Greenwich.SR1 2.1.6.RELEASE 1.8 IDEA
爲模擬實際開發，本篇教程除alh-tms外，所有的參數均從遠程配置中心讀取，若是不用遠程配置中心，請在本地應用直接寫各項參數即可。
涉及項目：
alh-config-server（6001）： 保持啓動狀態
alh-eureka-server（6000）：保持啓動狀態
alh-tms（8001）：保持上一篇中兩個實例啓動狀態
alh-order（8002）
完整教程全部章節目錄：https://blog.csdn.net/tuoyun6647/article/details/93501029
二、Feign中Ribbon配置
Ribbon負載均衡策略有以下幾種：
| 策略類 | 名稱 | 說明 |
| RandomRule | 隨機策略 | 隨機選擇 Server |
| RoundRobinRule | 輪訓策略 | 按順序循環選擇 Server |
| RetryRule | 重試策略 | 在一個配置時問段內當選擇 Server 不成功，則一直嘗試選擇一個可用的 Server |
| BestAvailableRule | 最低併發策略 | 逐個考察 Server，如果 Server 斷路器打開，則忽略，再選擇其中併發連接最低的 Server |
| AvailabilityFilteringRule | 可用過濾策略 | 過濾掉一直連接失敗並被標記爲 circuit tripped 的 Server，過濾掉那些高併發連接的 Server（active connections 超過配置的網值） |
| ResponseTimeWeightedRule | 響應時間加權策略 | 根據 Server 的響應時間分配權重。響應時間越長，權重越低，被選擇到的概率就越低；響應時間越短，權重越高，被選擇到的概率就越高。這個策略很貼切，綜合了各種因素，如：網絡、磁盤、IO等，這些因素直接影響着響應時間 |
| ZoneAvoidanceRule | 區域權衡策略 | 綜合判斷 Server 所在區域的性能和 Server 的可用性輪詢選擇 Server，並且判定一個 AWS Zone 的運行性能是否可用，剔除不可用的 Zone 中的所有 Server |
調用者（即服務消費者）alh-order配置文件application.properties如下
eureka.client.service-url.defaultZone=${default-zone}
server.port=${server.port}
spring.application.name=alh-order
#其中“alh-tms”指明對哪個微服務的調用進行配置，當前配置使用隨機策略，修改策略修改最後的類名即可
alh-tms.ribbon.NFLoadBalancerRuleClassName=com.netflix.loadbalancer.RandomRule
# 設置連接超時時間，單位ms
ribbon.ConnectTimeout=5000
# 設置讀取超時時間，單位ms
ribbon.ReadTimeout=5000
# 對所有操作請求都進行重試
ribbon.OkToRetryOnAllOperations=true
# 切換實例的重試次數
ribbon.MaxAutoRetriesNextServer=2
# 對當前實例的重試次數
ribbon.MaxAutoRetries=1
啓動後調用上一篇中的http://localhost:8002/tms/csinfo，發現調用alh-tms已變成隨機調用
三、總結
個人在實現時，發現負載均衡策略配置需指定調用的服務，如果一個服務中需要調用很多其他服務，則每個服務都需要進行配置，配置較繁瑣，且不方便統一管理（如有不對的地方請指正）。就生產而言，部署建議使用集羣管理平臺進行部署，高可用，負載均衡等均在集羣管理平臺統一配置
原文鏈接：https://blog.csdn.net/tuoyun6647/article/details/93667643