问题的根源

  一个项目采用Eureka Client的方式跟服务方交互，之前运行好好的，直到运维停机维护，结果就是调不通服务，仿佛整个服务端挂了。服务端是三台服务器组成的集群，客户端通过Ribbon负载均衡调用，运维是逐个停机维护，不会一下子关闭所有的服务器，不应该出现所有服务不可用。查找问题半天，最后发现是Eureka集群地址写错了，而且从进入生产环境的第一天地址就是错的。

正确的地址是

eureka.client.serviceUrl.defaultZone=http://ip1:11111/eureka/,http://ip2:11111/eureka/,http://ip3:11111/eureka/

调用方配置成了

eureka.client.serviceUrl.defaultZone=http://ip1:11111/eureka/,http://ip2:22222/eureka/,http://ip3:33333/eureka/

后面两台服务器的端口都配置错了，由于平常通过Ribbon负载均衡机制把请求路由到能够调通的服务上，一时没发现问题。直到前面那台服务停机维护，对客户端来说可用的服务没了。
随着配置的增多，更多相似的问题暴露出来，运维、开发人员错得一塌糊涂比如把ActiveMq集群地址配置成：

tcp://ip1::61616,tcp://ip2:61616,tcp://ip3:61616

地址里面多了个冒号，也是平常负载均衡作用下没问题，一旦后面两台服务挂了，服务就不通了。
这让我想起一个笑话，把原文摘抄在此，形象地展现了信息在传递过程中如何往奇怪的方向发展。

据说，一次部队的命令传递是这样的：
营长对值班军官：明晚大约8点钟左右，哈雷彗星将可能在这个地区看到，这种彗星每隔76年才能看见一次。命令所有士兵着野战服在操场上集合，我将向他们解释这一罕见的现象。如果下雨的话，就在礼堂集合，我为他们放一部有关彗星的影片。

值班军官对连长：根据营长的命令，明晚８点哈雷彗星将在操场上空出现。如果下雨的话，就让士兵穿着野战服列队前往礼堂，这一罕见的现象将在那里出现。

连长对排长：根据营长的命令，明晚8点，非凡的哈雷彗星将身穿野战服在礼堂中出现。如果操场上下雨，营长将下达另一个命令，这种命令每隔76年才会出现一次。

排长对班长：明晚8点，营长将带着哈雷彗星在礼堂中出现，这是每隔76年才有的事。如果下雨的话，营长将命令彗星穿上野战服到操场上去。

班长对士兵：在明晚8点下雨的时候，著名的76岁哈雷将军将在营长的陪同下身着野战服，开着他那彗星牌汽车，经过操场前往礼堂。

首先这种(ip1:port1,ip2:port1,ip3:port1)地址+端口+英文逗号分隔的形式并不符合人的阅读习惯，其次运维跟开发之间粘贴来粘贴去，难免出错。现在是三台服务，试想后续是三十台服务，只怕谁看了都头大。

解决方法

  所有调用方不再维护集群地址，统一由公司内部框架封装，公司内部框架再从分布式配置中心获取集群地址，集群地址由专人维护。Spring Cloud已经提供了分布式配置中心组件Spring Cloud Config，但我们使用了携程开源的分布式配置中心 Apollo（阿波罗）。集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。