在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在进行加载时,只会加载其入口的当前目录及其子目录下的服务,如果存放在其它目录下,应用扫描不到