SpringCloud 笔记 （四）---- 简单源码分析

见eureka-core-1.4.6.jar

客户端

Com.netflix.discovery.endpoint.EndpointUtils中依次加载了Region和Zone

Region:

默认为default，自己可以通过eureka.client.region属性来定义，这个值是什么？

@Autowiredprivate EurekaClientConfig clientConfig;@RequestMapping("/test")public String test() {    return "Region-"+clientConfig.getRegion();}

访问http://cc-pc:8080/user/test：
us-east-1

这个默认居然长这个样子。。。这是因为源码里有默认值

一个微服务应用只可以属于一个Region.可以通过eureka.client.region属性来定义。

Zone

当我们没有特别为Region配置Zone的时候，将默认采用defaultZone,这也是我们之前配置参数eureka.client.serviceUrl.defaultZone的由来。若要为应用指定Zone,可以通过eureka.client.availability-zones属性来进行设置。通过region我们可以获得一个zone的数组，所以region和zone是一对多的关系。

ServiceUrls

在获取了以上两个信息之后，才开始真正加载eureka server的具体地址。它根据传入的参数按一定算法确定加载位于哪个zone配置的serviceUrls
可以查看EurekaClientConfigBean，该类是EurekaClientConfig和EurekaConstants接口的实现，用来加载配置文件中的内容，这里有非常多有用的信息。

因为我们这个时候使用的是默认值，region和zone都没有配置，所以当然这里使用的是默认值。

Public String[] getAvailabilityZones(String region){    String value = this.avaiabilityZones.get(region);    If(value == null){    Value = DEFAULT_ZONE; }   Return value.split(“,”);}

其中Value = DEFAULT_ZONE;这就是我们之前用的默认zone
Eureka.client.serviceUrl.defaultZone属性，可以配置多个，并且通过分隔
当我们使用ribbon实现服务调用时，对于Zone的设置可以在负载均衡时实现区域亲和特性：Ribbon的默认策略会优先访问同客户端处于一个Zone中的服务端实例，只有当同一个Zone中没有可用服务端实例的时候才会去访问其他Zone中的实例。所以通过Zone属性定义，配合实际部署的物理结构，我们就可以有效地设计出对区域性故障的容错集群。

服务注册

发起注册请求时候，传入了一个com.netflix.appinfo.InstanceInfo对象，该对象就是注册时客户端给服务端的服务的元数据（hostName,id等信息）。
服务续约和服务获取
服务续约：在注册时，与注册成对存在。注册时，通过REST方式请求，把元数据的ip,name等信息传入，如果httpResponse的状态时404，重新注册，200就返回。

服务注册中心

可发现所有交互都是通过REST请求发起的。Eureka Server注册中心对于各类REST请求的定义都位于com.netflix.eureka.resources包下
在注册函数中，先调用publishEvent函数将该新服务注册的事件传播出去，然后调用com.netflix.eureka.registry.AbstractInstanceRegistry父类中的注册实现，将InstanceInfo中的元数据信息存储在一个ConcurrentHashMap对象中，第一层key存储服务名，InstanceInfo中的appName属性，第二层key存储实例名，InstanceInfo中的instanceId属性。