在Spring-cloud做微服务架构时，会碰到各种坑。下面总结一下Eureka的常见问题。
一、Eureka的自我保护模式
如果在Eureka Server的首页看到以下这段提示，则说明Eureka已经进入了保护模式：
EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.
一般出现此模式时，服务返回错误。即如果真实的服务已经Down掉，但在注册中心界面服务却一直存在，且显示为UP状态。
产生原因：Eureka Server在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%，如果出现低于的情况（在单机调试的时候很容易满足，实际在生产环境上通常是由于网络不稳定导致），Eureka Server会将当前的实例注册信息保护起来，同时提示这个警告。保护模式主要用于一组客户端和Eureka Server之间存在网络分区场景下的保护。一旦进入保护模式，Eureka Server将会尝试保护其服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。
详见：https://github.com/Netflix/eureka/wiki/Understanding-Eureka-Peer-to-Peer-Communication
解决方法：设置enableSelfPreservation:false
配置心跳检测时长，下线leaseRenewalIntervalInSeconds: 2
如何处理服务挂掉后或者手动关闭服务后，Ribbon负载均衡还是一直调用这个服务，然后调用@HystrixCommand断路器注解的方法：利用Hystrix，在error callback方法中可以shutdown指定的server
ZoneAwareLoadBalancer<Server> lb = (ZoneAwareLoadBalancer<Server>) springClientFactory.getLoadBalancer("CLOUD-SERVICE");
Server server = lb.chooseServer();
System.out.println("error->" + server.getHostPort());
lb.markServerDown(server);
另外在Camden.SR3中可以配置Ribbon请求重试，可以参考DD大神的新作：http://blog.didispace.com/spring-cloud-ribbon-failed-retry/
二、指定Eureka的Environment
eureka.environment: 指定环境
参考文档：https://github.com/Netflix/eureka/wiki/Configuring-Eureka
三、指定Eureka的DataCenter
eureka.datacenter: 指定数据中心
参考文档：https://github.com/Netflix/eureka/wiki/Configuring-Eureka
文中指出，配置-Deureka.datacenter=cloud，这样eureka将会知道是在AWS云上
参见：http://www.itmuch.com/spring-cloud-sum-eureka/和http://blog.csdn.net/jdhanhua/article/details/55002191
四、Whitelabel Error Page
@springBootApplication在进行加载时，只会加载其入口的当前目录及其子目录下的服务，如果存放在其它目录下，应用扫描不到