SpringCloud注册中心Eureka源码分析（二）

SpringCloud注册中心Eureka源码分析

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

int myZoneOffset = getZoneOffset(instanceZone, preferSameZone, availZones);
        List<String> serviceUrls = clientConfig.getEurekaServerServiceUrls(availZones[myZoneOffset]);

具体获取serviceUrls的实现，我们可以详细查看getEurekaServerServiceUrls函数的具体实现类EurekaClientConfigBean，该类是eurekaClientConfig和EurekaConstants接口的实现，用来加载配置文件中的内容，这里有非常多有用的信息，eureka.client.serviceUrl.defaultZone 属性可以配置多个，并且需要通过逗号分隔。

public List<String> getEurekaServerServiceUrls(String myZone) {
        String serviceUrls = this.configInstance.getStringProperty(this.namespace + "serviceUrl" + "." + myZone, (String)null).get();
        if (serviceUrls == null || serviceUrls.isEmpty()) {
            serviceUrls = this.configInstance.getStringProperty(this.namespace + "serviceUrl" + ".default", (String)null).get();
        }

        return (List)(serviceUrls != null ? Arrays.asList(serviceUrls.split(",")) : new ArrayList());
    }

首先会判断是否配置了自己的Zone，如果没有（(serviceUrls == null || serviceUrls.isEmpty())）就会使用默认的DefaultZone
当我们在微服务中使用Ribbon来实现服务调用时，对于Zone的设置可以负载均衡时实现区域亲和特性：Ribbon的默认策略会优先访问同客户端处于一个Zone中的服务端实例，只有当同一个Zone中没有可用服务端实例的时候才会访问其他Zone中的实例。所以通过Zone属性的定义，配合实际部署的物理结构，我们就可以有效地设计出对区域性故障的容错集群。
未完待续！！！！！！！