內容

　　本節從源碼的角度探討了Eureka控制臺中為何replicas（副本）顯示unavailable（不可用）的原因。在源碼層級解讀了Eureka Server的replicas是如何解析，以及replica的狀態是如何判定。

版本

　　IDE：IDEA 2017.2.2 x64

　　JDK：1.8.0_171

　　manve：3.3.3

　　SpringBoot：1.5.9.RELEASE

?　　SpringCloud：Dalston.SR1

適合人群

　　Java開發人員?

用詞釋義

　　Eureka實例：表示啟動的Eureka Server項目。

　　peer：同伴，Eureka集群中所有Eureka實例之間互稱peer。

　　replica：副本，由於Eureka集群中的Eureka實例之間相互同步註冊信息，Eureka實例稱其他Eureka實例為自己的replica。

說明

　　轉載請說明出處：SpringCloud從入門到進階（三）——源碼探究Eureka集群之replicas的unavailable故障

參考

　　SpringCloud從入門到進階（二）——註冊中心Eureka的偽分布式部署

內容

　　上一節講解了Eureka Server（下面簡稱Eureka）的偽分布式部署。但是在項目部署後，通過Eureka的管理頁面發現所有Eureka實例的replicas（副本）都是unavailable（不可用）狀態。但是此時部署的三個Eureka實例都正常運行著，難道出現靈異事件了嗎？筆者對此問題感到非常費解。因為寫博客的過程中部署過多次Eureka集群，之前是不存在此問題的（如下圖所示）。

　　在網上查閱了一些資料，有些網友是由於一些基礎的配置有誤導致該問題出現，比如：Eureka實例的spring.application.name配置的不一致、serviceUrl的配置中使用了localhost等等。最後提到了preferIpAddress的設置，筆者正是配置了這個屬性之後才出現本篇文章要解釋的這個問題！

　　上一節也提到，默認情況下，Eureka Client使用主機名進行註冊，同時，他們之間的調用也是通過主機名實現。將eureka.instance.preferIpAddress=true後，Eureka Client便通過IP地址進行註冊和復制的互相調用。但是，這又跟replicas的unavailable故障有什麽關系呢？下面，我們從源碼角度分析下Eureka的replica是如何解析，以及replica的狀態是如何判定的。

回顧上節的yaml中peer1的部分配置

spring:
  profiles: peer1
  application:
   name: application-eurekaserver
server:
  port: 7001
eureka:
  instance:
  #設置實例的hostname
   hostname: eureka7001.com
   instance-id: springcloud-eurekaserver-7001
    #要求Client通過ip的方式進行註冊
   prefer-ip-address: true
  client:
    #不將eureka server 註冊進來，會提示unavailable-replicas
    #默認情況下，Eureka Server會向自己註冊，這時需要配置eureka.client.registerWithEureka 和 eureka.client.fetchRegistry為false，防止自己註冊自己。
   register-with-eureka: true
   fetch-registry: true
   service-url:
    #defaultZone中填寫的URL必須包括後綴/eureka，否則各eureka server之間不能通信
    #defaultZone為默認的Zone，來源於AWS的概念。區域（Region）和可用區（Availability Zone,AZ）是AWS的另外兩個概念。區域是指服務器所在的區域，
    #比如北美洲、南美洲、歐洲和亞洲等，每個區域一般由多個可用區組成。 在本案例中defaultZone是指Eureka Server的註冊地址。
     defaultZone: http://eureka7002.com:7002/eureka,http://eureka7003.com:7003/eureka

DS Replicas之Eureka副本的解析

　　Eureka的副本是在項目啟動時，通過解析配置文件中eureka.client.serviceUrl屬性獲得同區的Eureka peer的url地址；然後判斷這些url地址是否指向當前啟動實例自身，把未指向當前實例的url作為Eureka peer的url。代碼位於com.netflix.eureka.cluster.PeerEurekaNodes類的resolvePeerUrls 方法。

源碼

//用於解析Eureka集群中Eureka實例的url地址
protected List<String> resolvePeerUrls() {
    //myInfo對象包含了當前實例的Eureka註冊信息，比如實例id，應用名，IP地址，端口號，主機名等信息，詳見下問"調試"。
    InstanceInfo myInfo = applicationInfoManager.getInfo();
    //當前實例所在區域，默認是defaultZone，在eureka.client.serviceUrl中配置。
    String zone = InstanceInfo.getZone(clientConfig.getAvailabilityZones(clientConfig.getRegion()), myInfo);
    //解析當前實例在eureka.client.serviceUrl參數配置的所有Eureka實例的url地址。詳見下文“調試”。
    List<String> replicaUrls = EndpointUtils
           .getDiscoveryServiceUrls(clientConfig, zone, new EndpointUtils.InstanceInfoBasedUrlRandomizer(myInfo));
    
    int idx = 0;
    //遍歷replicaUrls
    while (idx < replicaUrls.size()) {
        //判斷replicaUrls中的url是否指向當前實例，詳見下文“補充”。
        if (isThisMyUrl(replicaUrls.get(idx))) {
            //如果url指向當前實例，那麽該url就不能被認定為是當前實例的replica(副本)
            replicaUrls.remove(idx);
       } else {
            idx++;
       }
   }
    return replicaUrls;
}

調試

　　在該方法打斷點，項目啟動過程中，會執行到此斷點。

myInfo

　　myInfo對象包含了當前實例的註冊信息，比如實例id，應用名，IP地址，端口號，主機名等信息。可以發現，當配置eureka.instance.preferIpAddress=true後，實例的主機名就是該實例的IP地址，使用eureka.instance.hostname參數修改也是無效的！

replicaUrls

　　replicaUrls是當前實例在eureka.client.serviceUrl參數配置的所有Eureka peer的url地址。由配置文件可知，當前實例中配置的兩個Eureka實例的url地址是http://eureka7002.com:7002/eureka和http://eureka7003.com:7003/eureka，調試結果與配置一致。

本段小結

　　由peer1的配置文件可知，eureka.client.serviceUrl參數為http://eureka7002.com:7002/eureka和http://eureka7003.com:7003/eureka。這就是當前Eureka實例的兩個peer。由於開啟preferIpAddress，因此當前Eureka實例的主機名為ip地址，ip與eureka7002.com和eureka7003.com在字面量上都不相等，由源碼可知，當前Eureka實例會認為eureka7002.com和eureka7003.com這兩個實例是它的replica。於是就有了：

unavailable-replicas之Eureka副本的狀態判定

　　Eureka副本的狀態判定是通過遍歷當前Eureka實例的peer，將其url地址與當前所有可用的Eureka實例的主機名進行比對，來判斷此peer是否可用。代碼位於com.netflix.eureka.util.StatusUtil類的getStatusInfo 方法。

源碼

public StatusInfo getStatusInfo() {
    //實例信息的構造器
    StatusInfo.Builder builder = StatusInfo.Builder.newBuilder();
    //在線的replica的數量
    int upReplicasCount = 0;
    //在線的replica的主機名
    StringBuilder upReplicas = new StringBuilder();
    //不在線的replica的主機名
    StringBuilder downReplicas = new StringBuilder();
    //所有replica的主機名
    StringBuilder replicaHostNames = new StringBuilder();
    
    //遍歷當前Eureka實例的peer（下稱node），通過peerEurekaNode字面意思也能明白，詳見調試。
    for (PeerEurekaNode node : peerEurekaNodes.getPeerEurekaNodes()) {
        //如果有多個replica，用","號隔開主機名。
        if (replicaHostNames.length() > 0) {
            replicaHostNames.append(", ");
       }
        //將node的url地址加入到replicaHostNames中
        replicaHostNames.append(node.getServiceUrl());
        //通過isReplicaAvailable()方法判斷node是否可用
        if (isReplicaAvailable(node.getServiceUrl())) {
            //如果node可用，則將node的名稱加入到upReplicas
            upReplicas.append(node.getServiceUrl()).append(‘,‘);
            upReplicasCount++;
       } else {
            //如果node不可用，則將node的名稱加入到downReplicas
            downReplicas.append(node.getServiceUrl()).append(‘,‘);
       }
   }
    //向builder中添加replica的信息
    builder.add("registered-replicas", replicaHostNames.toString());
    builder.add("available-replicas", upReplicas.toString());
    builder.add("unavailable-replicas", downReplicas.toString());
?
    // 默認情況下，該條件為false
    if (peerEurekaNodes.getMinNumberOfAvailablePeers() > -1) {
        builder.isHealthy(upReplicasCount >= peerEurekaNodes.getMinNumberOfAvailablePeers());
   }
?
    //向builder中添加Eureka實例的信息
    builder.withInstanceInfo(this.instanceInfo);
?
    //通過builder構造當前實例的信息
    return builder.build();
}
?
//判定url指向的replica是否可用
private boolean isReplicaAvailable(String url) {
    try {
        //從容器registry中拿到名為“application-eurekaserver”的微服務app，app中包含了所有可用的Eureka實例。詳見下文“調試”。這裏也就解釋了為什麽application.name不同的Eureka實例不可用。
        Application app = registry.getApplication(myAppName, false);
        //如果不存在可用的peer，直接返回false
        if (app == null) {
            return false;
       }
        //遍歷應用中所有可用的peer
        for (InstanceInfo info : app.getInstances()) {
            //判斷給定的url是否指向可用的peer，如果是，那麽該url表示的replica是可用的，返回true。
            //由於開啟了preferIpAddress，實例的主機名就是該實例的IP地址，不再是eureka.instance.hostname的屬性值，因此url解析的主機名與ip地址不一致，會被誤認為當前在線的eureka實例並不是url指向的實例，因此url代表的replica被誤認為不可用。
            if (peerEurekaNodes.isInstanceURL(url, info)) {
                return true;
           }
       }
   } catch (Throwable e) {
        logger.error("Could not determine if the replica is available ", e);
   }
    return false;
}

調試

　　在該方法打斷點，項目啟動後訪問Eureka實例的管理界面時，會執行到此斷點。

peerEurekaNodes

　　peerEurekaNodes中包含了當前Eureka實例的peer，即主機名為eureka7002.com和eureka7003.com的Eureka實例。

名為“APPLICATION-EUREKASERVER”的服務-app

　　從registry容器中拿到名為“application-eurekaserver”的微服務app，app中包含了所有可用的Eureka實例。通過調試可以看到這三個實例分id分別為：springcloud-eurekaserver-7001、springcloud-eurekaserver-7002、springcloud-eurekaserver-7003。這正是我們啟動的三個Eureka實例，調試結果與事實一致。

結論

　　由於開啟了preferIpAddress，實例的主機名就是該實例的IP地址，不再是eureka.instance.hostname的屬性值。因此拿著replica的url（http://eureka7002.com:7002/eureka/）與實例的主機名（ip地址，比如：192.168.99.1）進行字面量比較，兩者肯定是不相等。從而被誤認為當前在線的eureka實例並不是url指向的實例，因此url代表的replica被誤認為不可用。

全文總結

　　再用白話解說為何實例可以識別到兩個replica，但是卻認為這些replica不可用。

　　當前實例會從配置文件serviceUrl屬性中的url中刨除指向自己的url，將剩下的url指向的實例認定為replica。在判斷replica的可用性時，拿著這些url跟在線的Eureka Server實例的主機名比較，看這些url是否指向在線的實例。但是由於開啟了preferIpAddress，在線實例的主機名變成ip地址，因此拿著replica的url的主機名跟ip地址做equals判斷時，二者必然不相等，也就導致了replica不可用的情況。一句話說，配置時用的域名，比較時用的ip地址，都是直接比較二者是否相等惹的禍。

如何解決此問題

　　開啟preferIpAddress後，運行在同一個主機上的所有Eureka實例都有相同的主機號，即主機的IP地址。因此在判斷replica狀態的時候必定會判為不可用。只有在真實的分布式主機上部署不同的Eureka實例，結合正確的配置*（serviceUrl需要配置為ip地址），才能做到開啟preferIpAddress後讓replica的狀態顯示正常。詳細過程請看下文：SpringCloud從入門到進階（四）——生產環境下Eureka的完全分布式部署

補充

isInstanceURL()方法

　　isInstanceURL()方法如何判定給定url是否指向給定的實例instance。

//該方法用於判定給定url是否代表了給定的實例instance
public boolean isInstanceURL(String url, InstanceInfo instance) {
    //解析url地址得到主機名，比如“http://eureka7002.com:7002/eureka/”的主機名為eureka7002.com
    String hostName = hostFromUrl(url);
    //拿到實例instance的主機名，當開啟preferIpAddress時，實例的主機名為ip地址。
    String myInfoComparator = instance.getHostName();
    //默認情況下，該if條件為false，即通過第二句代碼，從instance的信息中獲取主機名。
    if (clientConfig.getTransportConfig().applicationsResolverUseIp()) {
        myInfoComparator = instance.getIPAddr();
   }
    //如果url的主機名不為空，且等於instance的主機名，則返回true。
    return hostName != null && hostName.equals(myInfoComparator);
}

關閉preferIpAddress

　　關閉preferIpAddress後，實例的主機名就可以通過eureka.instance.hostname屬性進行設置，如下圖：

SpringCloud從入門到進階（三）——源碼探究Eureka集群之replicas的unavailable故障