本节从源码的角度探讨了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,:7003/eureka