见eureka-core-1.4.6.jar
客户端
Com.netflix.discovery.endpoint.EndpointUtils中依次加载了Region和Zone
Region:
默认为default,自己可以通过eureka.client.region属性来定义,这个值是什么?
@Autowired
private 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属性。