eureka 自定义defaultZone无效问题

eureka.client.service-url.defaultZone为什么自定义地址失效？
累计花费三四个小时，甚至clone了spring-cloud-netflix项目源码，终于被我发现了！

serviceUrl本身是个hashmap，初始化的时候会默认8761端口。

之后会读取yml(或properties）里serviceUrl下面的所有字段(键值对) 存到这个map里。

因为是存的是键值对，所以它并不能帮你检查拼写错误。

就算你在里面写了阿猫阿狗，都不会有任何错误提示（在其他对象里写了错误的属性，idea会有淡黄色背景色提醒）

接下来就很好解释为什么serviceUrl和service-url能通用，而defaultZone不能写成default-zone了。
首先要获得一个AwsEndpoint实例，它继承了DefaultEndpoint.

它的serviceURI是在这里得到的：

这个方法点进去看，发现它是根据zone去serviceUrl map里取值，而zone的值(即要查的map的key)就是defaultZone

假使zone字符串是个空值，或者在map里查到空值，也会默认去查defaultZone。所以这个属性必须写成 “defaultZone: xxxx " 差一个字符都不行。

补充一下，为什么zone会是 “defaultZone”？
zone是从availZones里拿的。availZones会从config的availabilityZones里拿，按逗号分隔；如果没有，就返回 “defaultZone” (这点在getAvailabilityZones方法和getAvailabilityZones下面的if语句中都有保证）。
我这里没有配置availabilityZones，所以availZones就只能拿到defaultZone。


getZoneOffset方法是遍历availZones数组，查询instanceZone在数组中的位置，如果查不到，就返回下标0（相当于缺省值）。这里的instanceZone的值是"defaultZone"这也是为什么最后zone会得到"defaultZone”。instanceZone的值是方法调用的时候传进来的。

接下来看为什么instanceZone是"defaultZone"
首先是getAvailabilityZones方法，之前已经分析过了，因为没有配置availabilityZones，所以会拿到一个只有"defaultZone的数组"

getZone方法会返回availZone的第一个值(如果没有，返回"default")。下面的判断条件只有在name=Amazon的时候才会成立，所以可以忽略。根据上文，我们的availZone只有一个值{“defaultZone”}，这就是instanceZone的值为"defaultZone"的原因

最后补充一下，读取eureka endpoints有DNS和config两种方式。上面所说的都是在选择config的情况下。

最后

以上就是纯真航空为你收集整理的eureka 自定义defaultZone无效问题的全部内容，希望文章能够帮你解决eureka 自定义defaultZone无效问题所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。