源码分析

上一篇对Eureka中各个元素的通信行为做了了解。
首先，对于服务注册中心、服务提供者、服务消费者这三个主要元素来说，后两者（也就是Eureka客户端）在整个运行机制中是大部分通信行为的主动发起者，而注册中心主要是处理请求的接收者，所以，可以从Eureka的客户端作为入口看看他是如何完成通信的。

我们将一个普通的spring boot应用注册到Eureka Server或者是从Eureka Server中获取服务列表时，主要做两件事：
1、在应用主类中配置了@EnableDiscoveryClient//激活Eureka中DiscoveryClient实现
2、在application.properties中用eureka.client.serviceUrl.defaultZone参数指定了服务注册的位置。
顺着上面 ，看看@EnableDiscoveryClient的源码，

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Inherited;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import org.springframework.context.annotation.Import;

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@Import({EnableDiscoveryClientImportSelector.class})
public @interface EnableDiscoveryClient {
}

从该注解的注释中我们可以知道，它主要用来开启贮 scoveryClient 的实例。通过
搜索 DiscoveryClient, 我们可以发现有 一 个类和 一 个接口。通过梳理可以得到如下图
所示的关系：

其中，左边的org.springframework.cloud.client.discovery.DiscoveryClient
是 Spring Cloud 的接口，它定义了用来发现服务的常用的抽象方法，通过该接口可以有效的屏蔽服务治理的实现细节。所以使用spring cloud构建微服务应用可以方便的切换不同的服务治理框架，而不改动程序代码。只需要另外添加一些针对服务治理框架的配置即可。
org.springframework.cloud.netflix.eureka.EurekaDiscoveryClient是对
该接口的实现， 从命名来判断， 它实现的是对 Eureka 发现服务的封装。
。 所以
EurekaDiscoveryClient 依赖了 Netflix Eureka 的 com.netf lix.discovery.
EurekaClient 接口， EurekaClient 继承了 LookupService 接口， 它们都是 Netflix
开源包中的内容， 主要定义了针对 Eureka 的发现服务的抽象方法， 而真正实现发现服务的
则是 Netflix 包中的 com.netf lix.discovery.DiscoveryClient 类。

接下来看DiscoveryClient类，解读该类头部注释：

这个类用于帮助与Eureka Server互相协作。
Eureka Client负责下面的任务：
*向Eureka Server注册服务实例
*向Eureka Server服务租约
*当关闭服务期间，向Eureka Server取消租约
*查询Eureka Server中的服务实例列表
Eureka Client还需要配置一个Eureka Server的URL列表。

在具体Eureka Client负责完成的任务前，我们看卡在哪里对Eureka Server的URL列表进行配置，根据我们配置的属性名eureka.client.serviceUrl.defaultZone,通过serviceUrl可以找到该属性相关的加载属性，但是在SR5版本中他们都被
@Deprecated 标注为不再建议使用，并＠巨 nk 到了替代类 com.netflix.discovery.
endpoint.EndpointUtils, 所以我们可以在该类中找到下面这个函数：

Region 、 Zone
在上面的函数中，可以发现，客户端加载了两个内容，第一个是Region，第二个是Zone，从逻辑上可以判断他们之间的关系：
1、通过getRegion 函数， 我们可以看到它从配置中读取了一 个Region返回， 所以 一
个微服务应用只可以属于 一 个Region, 如果不特别配置， 默认为default。 若我们要
自己设置， 可以通过eureka.client.region属性来定义。
2、过 getAvailabilityZones 函数， 可以知道当我们没有特别为Region配置
Zone的时候， 将默认采用defaultZone, 这也是我们之前配置参数 eureka.
client.serviceUrl.defaultZone的由来。 若要为应用指定Zone, 可以通过
eureka.client.availability-zones属性来进行设置。从该函数的return
内容， 我们可以知道Zone能够设置多个， 并且通过逗号分隔来配置。 由此， 我们
可以判断Region与Zone是 一 对多的关系。

serviceUrls
在获取了 Region 和 Zone 的信息之后， 才开始真正加载 Eureka Server 的具体地址。 它
根据传入的参数按 一 定算法确定加载位于哪 一 个 Zone 配置的 serviceUris 。

具体获取 serviceUrls 的实现， 我们可以详细查看 getEurekaServerServiceUrls
函数的具体实现类 EurekaClientConfigBean, 该类是EurekaClientConfigBean和
EurekaConstants 接口的实现，用来加载配置文件中的内容，这里有非常多有用的信息，
我们先说 一 下此处我们关心的， 关于 defaultZone 的信息。 通过搜索 defaultZone,
我们可以很容易找到下面这个函数， 它具体实现了如何解析该参数的过程， 通过此内容，
我们就可以知道， eureka.client.serviceUrl.defaultZone 属性可以配置多个，
并且需要通过逗号分隔。