在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在進行加載時，只會加載其入口的當前目錄及其子目錄下的服務，如果存放在其它目錄下，應用掃描不到