在之前的案例中，我們啟動了乙個user-service，然後通過discoveryclient來獲取服務例項資訊，然後獲取ip和埠來訪問。
但是實際環境中，我們往往會開啟很多個user-service的集群。此時我們獲取的服務列表中就會有多個，到底該訪問哪乙個呢？
一般這種情況下我們就需要編寫負載均衡演算法，在多個例項列表中進行選擇。
不過eureka中已經幫我們整合了負載均衡元件：ribbon，簡單修改**即可使用。
什麼是ribbon：
使用ribbon實現負載均衡。
因為eureka中已經整合了ribbon，所以我們無需引入新的依賴。直接修改**：
在resttemplate的配置方法上新增@loadbalanced註解：
@bean
@loadbalanced
public resttemplate resttemplate()
public user queryuserbyid(string id)ribbon預設的負載均衡策略是簡單的輪詢
springboot幫我們提供了修改負載均衡規則的配置入口：
user-service:
ribbon:
nfloadbalancerruleclassname: com.netflix.loadbalancer.randomrule
.ribbon.nfloadbalancerruleclassname，值就是irule的實現類。
重試機制：
eureka的服務治理強調了cap原則中的ap，即可用性和可靠性。它與zookeeper這一類強調cp（一致性，可靠性）的服務治理框架最大的區別在於：eureka為了實現更高的服務可用性，犧牲了一定的一致性，極端情況下它寧願接收故障例項也不願丟掉健康例項，正如我們上面所說的自我保護機制。
但是，此時如果我們呼叫了這些不正常的服務，呼叫就會失敗，從而導致其它服務不能正常工作！這顯然不是我們願意看到的。
我們現在關閉乙個user-service例項：
但是此時，8081服務其實是正常的。
因此spring cloud 整合了spring retry 來增強resttemplate的重試能力，當一次服務呼叫失敗後，不會立即丟擲一次，而是再次重試另乙個服務。
只需要簡單配置即可實現ribbon的重試：
spring:
cloud:
loadbalancer:
retry:
enabled: true # 開啟spring cloud的重試功能
user-service:
ribbon:
connecttimeout: 250 # ribbon的連線超時時間
readtimeout: 1000 # ribbon的資料讀取超時時間
oktoretryonalloperations: true # 是否對所有操作都進行重試
maxautoretriesnextserver: 1 # 切換例項的重試次數
maxautoretries: 1 # 對當前例項的重試次數
maxautoretriesnextserver引數的值
引入spring-retry依賴
org.springframework.retry
spring-retry
Robbin負載均衡
feign預設整合了ribbon。我們在上一章 eureka服務的註冊與發現 的基礎上實現了乙個簡單的服務註冊與發現任務，這節我們會在上一工程的基礎上實現負載均衡。分別為 8087 8088 eureka中預設整合了ribbon，無需引入新的依賴 package com.boss.userclien...
nginx 負載均衡 Nginx負載均衡策略
nginx提供的負載均衡策略有2種 內建策略和擴充套件策略。內建策略為輪詢 預設 加權輪詢，ip hash，第三方。upstream mysvr1 輪詢 每個請求按照時間順序逐一的分配到每乙個後台伺服器上。如果某台伺服器宕機了，將會自動的剔除宕機的服務。nginx預設就是輪詢其權重都預設為1，伺服器...
軟負載均衡和F5負載均衡（硬負載均衡）區別
分割線，以下是原文內容 負載均衡 建立在現有網路結構之上，它提供了一種廉價有效透明的方法擴充套件 網路裝置 和伺服器 的頻寬 增加 吞吐量 加強網路資料處理能力 提高網路的靈活性和可用性。負載均衡，英文名稱為load balance，其意思就是分攤到多個操作單元上進行執行，例如web 伺服器 ftp...