1.遇到的問題及對應原始碼
1.1.ribbon loadbalancer 請求快取:
1.1.1.問題描述: spring cloud 版本:dalston.sr1,註冊中心:eureka. 基於 rest 的微服務架構中,使用 ribbon 來作為客戶端負載.當乙個服務呼叫另乙個服務的時候, ribbon 會快取請求和 service list. 假設現在有service0和service1, 當service1異常關閉後,service0去呼叫,會提示錯誤.過了一段時間,service1正常啟動了,此時,service0並不會立刻知道service1已經啟動,而是等待 updatelistofservers 定時任務執行,它執行的時候,就會更新service list.
1.1.2.解決方案: 這裡涉及2個定時任務,乙個是eurekaclient的定時任務(com.netflix.discovery.discoveryclient.refreshregistry()), 另乙個是ribbon的定時任務(com.netflix.loadbalancer.pollingserverlistupdater.start()) . ribbon更新server list的時候,是根據eurekaclient中的 instance list 來更新的,ribbon並不會傳送請求到eureka server中,獲取新的service list. 獲取的操作是由eurekaclient的定時任務做的. 和eurekaclient定時任務有關的配置是: eureka.client.registry-fetch-interval-seconds 這個值就是eureka client 定時向 eureka server 獲取 服務列表的間隔. 和ribbon定時任務有關的配置是:ribbon.serverlistrefreshinterval . 測試的時候,調小這兩個值,即可達到快速發現服務的效果. 更好的實現方式應該是由spring cloud bus 來實現.還在研究原始碼中.
1.2.ribbon ping :
1.2.1.問題描述: 我這裡使用的是 dalston.sr1 版本,如果你使用了eureka作為註冊中心,這時候 ribbon會使用eurekaribbonclientconfiguration,iping的實現類使用的是: niwsdiscoveryping ,觀察niwsdiscoveryping.isalive(), 這裡面其實沒有真正的實行ping操作,而是把引數server的status直接獲取,判斷一下是否為up,就判定服務是否正常.是別有用意還是太草率了?
1.2.2.解決方案: 自行實現乙個iping,並注入到spring中.
ribbon原始碼分析
ribbon 原始碼分析 一 兩個註解 ribbonclients ribbonclients 註解上面都匯入了 這個類 import ribbonclientconfigurationregistrar.class ribbonclientconfigurationregistrar 這個類 實現...
Fabric 原始碼解析 原始碼目錄解析
這裡對重要的一些目錄進行說明 bccsp 與密碼學 加密 簽名 證書等等 相關的加密服務 將fabric中用到的密碼學相關的函式抽象成了一組介面，便於拓展。bddtests 一種新型的軟體開發模式 行為驅動開 需求 開發 common 一些公共庫 錯誤處理 日誌處理 賬本儲存 策略以及各種工具等等 ...
ribbon負載均衡迴圈策略原始碼
在用ribbon負載均衡取eureka註冊中心中的位址時，預設採用迴圈策略，例如商品服務有3個，分別為url1,url2,url3,那麼在客戶端第一次取時，會取到url1，第二次取時取到url2,第三次是url3,然後依次迴圈。很好奇這種演算法是怎麼保證永遠是順序取的，如果在高併發下，是否也能按這個...