dev，test环境公用一个Eureka的总结

需求1：保证不同环境服务调用稳定

dev环境存在调用方A，提供方B
test环境存在调用方C，提供方D
(A,C同一个工程，B,D同一个工程)
期望：A->B,C->D，dev环境和test环境下的服务调用不会乱串，必须在eureka上报中指定自己的所属分区

配置application-test.yml（调用方和提供方都必须指定）

eureka:  instance:    metadata-map:      zone: test

application-test.yml指定后，application-dev.yml的配置不需要特别指定，以默认的zone即可（什么都不用写）。
这样，在服务在Eureka中注册成功后，从Eureka中拉取全部注册的Applications信息，当applications中存在多个实例，ribbon会过滤掉zone与当前服务zone不同的服务，只会连接属于同一个zone的服务实例。

需求2：dev环境连接test环境中的服务

dev环境存在调用方A，提供方B
test环境存在调用方C，提供方D
(A,C同一个工程，B,D同一个工程)
本地dev环境中经常需要进行调试，调试的时候必须启动服务A,服务B,组成完成的调用链，假如涉及的服务比较多，这样耗时耗力，很不现实。
所以，产生了需求：有时候只变更了服务A,服务B不需要启动，A发起对B的调用使用test环境的服务D代替。
在dev，test网络隔离的情况下，我们必须要通过转发连通test环境的服务才能实现本地服务调用测试的依赖。

配置application-test.yml（提供方配置）

所以test环境的服务上报的hostname必须是跳板机的公网ip或者域名，port如果不指定则和server.port一致。

eureka:  instance:    hostname: example.com

配置nginx

配置完成后需要在nginx中开启端口转发至对应的内网ip:port
如果对应的域名的端口号（运营商对于很多常见的端口都会做禁封处理，如8080，可以使用telnet测试对应的端口是否被禁封）被禁封，可以在上报eureka的时候使用高端口（>30000），然后上述配置改为

eureka:  instance:    non-secure-port: 40004    hostname: example.com

完整配置

如果需要满足需求1、需求2，请拷贝下述配置即可

eureka:  instance:    hostname: example.com    metadata-map:      zone: test  client:    serviceUrl:      defaultZone: http://example.com/eureka/eureka