您好,登錄后才能下訂單哦!
這期內容當中小編將會給大家帶來有關SEureka服務實例啟動時是否會立刻向EurekaServer注冊,文章內容豐富且以專業的角度為大家分析和敘述,閱讀完這篇文章希望大家可以有所收獲。
基于SpringCloud-Dalston.SR5
是的,立刻會。
EurekaClient在每次實例狀態發生改變時,有一個Listener:
statusChangeListener = new ApplicationInfoManager.StatusChangeListener() { @Override public String getId() { return "statusChangeListener"; } @Override public void notify(StatusChangeEvent statusChangeEvent) { if (InstanceStatus.DOWN == statusChangeEvent.getStatus() || InstanceStatus.DOWN == statusChangeEvent.getPreviousStatus()) { // log at warn level if DOWN was involved logger.warn("Saw local status change event {}", statusChangeEvent); } else { logger.info("Saw local status change event {}", statusChangeEvent); } //這個會觸發調用register接口將實例信息注冊上去 instanceInfoReplicator.onDemandUpdate(); } };
實例初始化完畢時,會發送一個狀態為UP的事件,觸發這個Listener(狀態從STARTING變成UP ):
@Override public void register(EurekaRegistration reg) { maybeInitializeClient(reg); if (log.isInfoEnabled()) { log.info("Registering application " + reg.getInstanceConfig().getAppname() + " with eureka with status " + reg.getInstanceConfig().getInitialStatus()); } reg.getApplicationInfoManager() .setInstanceStatus(reg.getInstanceConfig().getInitialStatus()); if (reg.getHealthCheckHandler() != null) { reg.getEurekaClient().registerHealthCheck(reg.getHealthCheckHandler()); } }
那么,官網這兩個配置有啥用: 其實這個Initially是另外一個邏輯,就是在應用啟動40s后,檢查實例信息是否老舊,或者第一次注冊是否失敗,如果失敗,就再次注冊。之后每隔30s執行一次這個任務
首先,EurekaClient會選擇eureka.client.service-url.defaultZone配置的第一個EurekaServer,之后如果和這個EurekaServer沒有網絡問題,就會一直用這個。 在EurekaClient向EurekaServer發送注冊,下線,心跳,狀態改變等一切事件時,這些會在EurekaServer上面同步到集群(EurekaServer集群配置就是eureka.client.service-url.defaultZone,集群內每個EurekaServer)的所有Server上
這樣的機制有沒有問題?
這個同步到其他EurekaServer與本次EurekaClient請求是否是同步的? 不是同步的,例如注冊到EurekaServerA,EurekaServerA將注冊請求同步到EurekaServerB與當前注冊請求是異步的
某次異步同步請求失敗如何補償? 例如服務實例A注冊到EurekaServerA,但是同步到EurekaServerB失敗。這時EurekaServerB就沒有這個實例,在下次A心跳時,EurekaServerA同步心跳請求到EurekaServerB時,會返回404,觸發重新注冊 推論: 為了減少和均勻EurekaServer壓力和訪問便利,我們對于每個微服務的不同實例,配置Eureka集群都要寫的順序不一樣,和自己網段一樣的寫的靠前
網絡抖動時,導致訪問到另一個Eureka,重啟才能恢復。。。
通過EurekaServer內部定時檢查過期實例任務,掃描Registry里面過期的實例并刪除,并且使對應的ReadWriteMap緩存失效 注意,ReadOnlyMap里面的并不會立刻失效,而是通過下一個只讀緩存刷新從ReadWriteMap刷到ReadOnlyMap感知變化。因為EurekaClient獲取實例信息只從ReadOnlyMap讀取,所以EurekaClient感知變化也會有這個延遲
SpringCloud環境下,EurekaClient有緩存,Ribbon對于調用的服務列表也有緩存,所以可以繼續調用,但不會更新服務與實例列表了。 根據Eureka的self-preservation的設計思路,可以理解這種設計也是符合Eureka初衷的(CAP中的A)
上述就是小編為大家分享的SEureka服務實例啟動時是否會立刻向EurekaServer注冊了,如果剛好有類似的疑惑,不妨參照上述分析進行理解。如果想知道更多相關知識,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。