當生產者有多個相同的serciceid的例項後，消費者從rureka中獲取的服務列表中就會包含多個服務例項，這個時候消費者怎麼樣去進行選擇使用哪乙個服務例項呢
ribbon會獲取到服務列表後，ribbon可以根據自己的負載均衡的演算法，自動的選擇某乙個服務去進行請求。ribbon本身也提供了一些負載均衡的演算法。
因為eureka依賴中已經帶有ribbon，所以不在需要新增依賴。
1.配置類
@configuration
public
class
webconfig
}
)public result
>
selectaddress
(@pathvariable
("parent_id"
)int parent_id)
throws ioexception
負載均衡有好幾種實現策略，常見的有：
隨機 (random)
輪詢 (roundrobin)
一致性雜湊 (consistenthash)
雜湊 (hash)
加權（weighted）
預設情況下ribbon使用的負載均衡的策略為輪詢，我們也可以配置策略
#配置消費者訪問指定serviceid的負載均衡策略
demo1.ribbon.nfloadbalancerruleclassname=com.netflix.loadbalancer.randomrule
SpringCould之Hystrix熔斷器
在微服務架構中，一台服務往往會去遠端呼叫別的服務，但是如果別的服務出現了故障，或者因為網路問題導致遲遲沒有給出響應，這時我們的請求會一直佔據著資源，如果在高併發的時候，還會把服務壓垮，導致此服務不能使用，依賴於這個服務的所有服務都會出現問題，導致服務雪崩。為了解決這一的問題，hystrix解決的方案...
SpringCould之熔斷器（四）
雪崩效應 在微服務架構中通常會有多個服務之間進行相互呼叫，基礎服務的故 障可能會導致級聯故障，進而造成整個系統不可用的情況，這種現象被稱為服務 雪崩效 應 服務雪崩效應是一種因 服務提供者 的不可用導致 服務消費者 的不可用,並將 不可用逐漸放大的過程。為解決 雪崩效應 微服務架構提供了一種了斷路器...
springCould 基礎服務搭建
這裡拿itoken config 和 itoken eureka 做解釋 master這裡之前是部署了gitlab的，但是有個坑自己沒有解決。就是gitlab上面的專案我無法讀取到配置，相同的 我github就能讀取到，暫時還未解決 itoken config.yml spring name ito...