SEureka服務(wù)實(shí)例啟動時是否會立刻向EurekaServer注冊

這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)SEureka服務(wù)實(shí)例啟動時是否會立刻向EurekaServer注冊，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

基于SpringCloud-Dalston.SR5

Eureka服務(wù)實(shí)例啟動時，是否會立刻向EurekaServer注冊?

是的，立刻會。

EurekaClient在每次實(shí)例狀態(tài)發(fā)生改變時，有一個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);
        }
//這個會觸發(fā)調(diào)用register接口將實(shí)例信息注冊上去
        instanceInfoReplicator.onDemandUpdate();
    }
};

實(shí)例初始化完畢時，會發(fā)送一個狀態(tài)為UP的事件，觸發(fā)這個Listener（狀態(tài)從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());
   }
}

那么，官網(wǎng)這兩個配置有啥用： 其實(shí)這個Initially是另外一個邏輯，就是在應(yīng)用啟動40s后，檢查實(shí)例信息是否老舊，或者第一次注冊是否失敗，如果失敗，就再次注冊。之后每隔30s執(zhí)行一次這個任務(wù)

EurekaServer集群內(nèi)部信息如何同步？

首先，EurekaClient會選擇eureka.client.service-url.defaultZone配置的第一個EurekaServer，之后如果和這個EurekaServer沒有網(wǎng)絡(luò)問題，就會一直用這個。 在EurekaClient向EurekaServer發(fā)送注冊，下線，心跳，狀態(tài)改變等一切事件時，這些會在EurekaServer上面同步到集群（EurekaServer集群配置就是eureka.client.service-url.defaultZone，集群內(nèi)每個EurekaServer）的所有Server上

這樣的機(jī)制有沒有問題？

1. 這個同步到其他EurekaServer與本次EurekaClient請求是否是同步的？ 不是同步的，例如注冊到EurekaServerA，EurekaServerA將注冊請求同步到EurekaServerB與當(dāng)前注冊請求是異步的

2. 某次異步同步請求失敗如何補(bǔ)償？ 例如服務(wù)實(shí)例A注冊到EurekaServerA，但是同步到EurekaServerB失敗。這時EurekaServerB就沒有這個實(shí)例，在下次A心跳時，EurekaServerA同步心跳請求到EurekaServerB時，會返回404，觸發(fā)重新注冊 推論： 為了減少和均勻EurekaServer壓力和訪問便利，我們對于每個微服務(wù)的不同實(shí)例，配置Eureka集群都要寫的順序不一樣，和自己網(wǎng)段一樣的寫的靠前

網(wǎng)絡(luò)抖動時，導(dǎo)致訪問到另一個Eureka，重啟才能恢復(fù)。。。

服務(wù)實(shí)例怎么過期？

通過EurekaServer內(nèi)部定時檢查過期實(shí)例任務(wù)，掃描Registry里面過期的實(shí)例并刪除，并且使對應(yīng)的ReadWriteMap緩存失效 注意，ReadOnlyMap里面的并不會立刻失效，而是通過下一個只讀緩存刷新從ReadWriteMap刷到ReadOnlyMap感知變化。因?yàn)镋urekaClient獲取實(shí)例信息只從ReadOnlyMap讀取，所以EurekaClient感知變化也會有這個延遲

為何EurekaServer掛了，客戶端依然可以調(diào)通？

SpringCloud環(huán)境下，EurekaClient有緩存，Ribbon對于調(diào)用的服務(wù)列表也有緩存，所以可以繼續(xù)調(diào)用，但不會更新服務(wù)與實(shí)例列表了。 根據(jù)Eureka的self-preservation的設(shè)計思路，可以理解這種設(shè)計也是符合Eureka初衷的（CAP中的A）

上述就是小編為大家分享的SEureka服務(wù)實(shí)例啟動時是否會立刻向EurekaServer注冊了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道。