故障现象：使用docker发布微服务的各个服务，注册到某服务器上的eureka注册中心，欲使用application-name进行服务消费，然鹅在eureka的页面发现，注册的服务的IPADDRESS都是莫名的172.17.0.3，实际服务地址应该是172.26.102.28或者32，问题导致服务调用的时候无法查找到正确地址进行调用，调用失败。
故障分析：首先我考虑的是服务器的网关用了nginx反向代理，是否在访问的时候，eureka就无法获得正确的地址。对配置进行了修改，添加了spring.cloud.instance.default.ip.address进行IP固定，失败。
转换思路，考虑到，在本机上用sts运行的微服务是可以正确显示IP地址和端口号，并能正确访问的，目光放在了docker上。去掉eureka的docker外壳，将eureka服务端打包成jar，在服务器上以java -jar XXXX.jar方式直接运行，再将微服务以同样方式进行运行，微服务可以正常显示并调用，确定问题是docker。应该是docker在容器运行的时候，自己建立了一个虚拟的网卡，所有的端口必须通过端口映射的方式才能与外通讯，所以，通过docker启动的项目，在进行eureka注册的时候，实际上是获得了一个通过docker进行包装过的网关的IP地址。
故障解决：分析出了问题的原因，就需要对症下药，此时得到了公司大牛的帮助，在大堆英文文档里翻出了eureka的配置，配置eureka.instance.ip-address&eureka.instance.secure-port即可写死项目对外的IP和端口号，不受docker影响，如此虽然不够灵活，但是好在项目发布到哪个服务器和使用哪个端口目前都是可以确定且不会进行修改的，故而不失为一个不错的临时解决方案，待以后对spring cloud有了更多了解以后再看有没有更好的办法。
心得：碰到问题的时候，其实做了很多努力，甚至想到用zuul，网关代理来解决问题，但是zuul是对服务进行网关，进行分发，负载均衡等可以有用，对该问题不能解决，不过顺便学会了zuul的初级使用。关键点还是在于对问题的定位，需要更细心的去发现问题的线索，定位引发问题的所在，对症下药可解决问题。另：英文好真的很重要，前沿的软件技术国内的文档太少了，特别是一个新兴的软件工程出来的时候，版本的更新常常会导致配置进行变更，我在springcloud 1.4版本的教程里抄的配置，到了1.5就不能用了，我特么找谁说理去。短短不到半年，又特么从1.5到现在2.0的，麻蛋，车速太快跟不上了啊。
