1.解決Eureka註冊服務慢的問題
（1）調整客戶端心跳時間
instance:
# 心跳時間，即服務續約間隔時間（缺省爲30s）
lease-renewal-interval-in-seconds: 5
# 發呆時間，即服務續約到期時間（缺省爲90s）
lease-expiration-duration-in-seconds: 10
eureka.instance.lease-expiration-duration-in-seconds
leaseExpirationDurationInSeconds，表示eureka server至上一次收到client的心跳之後，等待下一次心跳的超時時間，在這個時間內若沒收到下一次心跳，則將移除該instance。
默認爲90秒
如果該值太大，則很可能將流量轉發過去的時候，該instance已經不存活了。
如果該值設置太小了，則instance則很可能因爲臨時的網絡抖動而被摘除掉。
該值至少應該大於leaseRenewalIntervalInSeconds
eureka.instance.lease-renewal-interval-in-seconds
leaseRenewalIntervalInSeconds，表示eureka client發送心跳給server端的頻率。如果在leaseExpirationDurationInSeconds後，server端沒有收到client的心跳，則將摘除該instance。除此之外，如果該instance實現了HealthCheckCallback，並決定讓自己unavailable的話，則該instance也不會接收到流量。
默認30秒
作爲實例還涉及到與註冊中心的週期性心跳，默認持續時間爲30秒（通過serviceUrl）。在實例、服務器、客戶端都在本地緩存中具有相同的元數據之前，服務不可用於客戶端發現（所以可能需要3次心跳）。你可以使用eureka.instance.leaseRenewalIntervalInSeconds 配置，這將加快客戶端連接到其他服務的過程。在生產中，最好堅持使用默認值，因爲在服務器內部有一些計算，他們對續約做出假設。
（2） 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.
配置
server:
#開啓Eureka的自我保護機制
enable-self-preservation: true
#清理無效節點的時間間隔
eviction-interval-timer-in-ms: 5000
eureka.server.enable-self-preservation
是否開啓自我保護模式，默認爲true。
默認情況下，如果Eureka Server在一定時間內沒有接收到某個微服務實例的心跳，Eureka Server將會註銷該實例（默認90秒）。但是當網絡分區故障發生時，微服務與Eureka Server之間無法正常通信，以上行爲可能變得非常危險了——因爲微服務本身其實是健康的，此時本不應該註銷這個微服務。
Eureka通過“自我保護模式”來解決這個問題——當Eureka Server節點在短時間內丟失過多客戶端時（可能發生了網絡分區故障），那麼這個節點就會進入自我保護模式。一旦進入該模式，Eureka Server就會保護服務註冊表中的信息，不再刪除服務註冊表中的數據（也就是不會註銷任何微服務）。當網絡故障恢復後，該Eureka Server節點會自動退出自我保護模式。
綜上，自我保護模式是一種應對網絡異常的安全保護措施。它的架構哲學是寧可同時保留所有微服務（健康的微服務和不健康的微服務都會保留），也不盲目註銷任何健康的微服務。使用自我保護模式，可以讓Eureka集羣更加的健壯、穩定。
eureka.server.eviction-interval-timer-in-ms
eureka server清理無效節點的時間間隔，默認60000毫秒，即60秒
（3）如何解決Eureka Server不踢出已關停的節點的問題
在開發過程中，我們常常希望Eureka Server能夠迅速有效地踢出已關停的節點，但是新手由於Eureka自我保護模式，以及心跳週期長的原因，常常會遇到Eureka Server不踢出已關停的節點的問題。解決方法如下：
（1） Eureka Server端：配置關閉自我保護，並按需配置Eureka Server清理無效節點的時間間隔。
eureka.server.enable-self-preservation # 設爲false，關閉自我保護
eureka.server.eviction-interval-timer-in-ms # 清理間隔（單位毫秒，默認是60*1000）
（2） Eureka Client端：配置開啓健康檢查，並按需配置續約更新時間和到期時間。
eureka.client.healthcheck.enabled # 開啓健康檢查（需要spring-boot-starter-actuator依賴）
eureka.instance.lease-renewal-interval-in-seconds # 續約更新時間間隔（默認30秒）
eureka.instance.lease-expiration-duration-in-seconds # 續約到期時間（默認90秒）
（4）zuul間隔多久去拉取註冊服務的信息
eureka.client.registry-fetch-interval-seconds
表示eureka client間隔多久去拉取服務註冊信息，默認爲30秒，對於api-gateway，如果要迅速獲取服務註冊狀態，可以縮小該值，比如5秒
（5）ribbon的飢餓加載
意爲Spring Cloud爲每個Ribbon客戶端維護了一個相對的子應用環境的上下文，應用的上下文在第一次請求到指定客戶端的時候懶加載。不過可以通過如下配置進行修改
ribbon:
eager-load:
enabled: true
clients:
- callback,service-cache,service-singlepoint
按照如上的配置之後，發現鑑權服務啓動時就將user服務的Ribbon客戶端進行了加載。
（6）zuul的飢餓加載
上面小節解決了auth-Service調用user-Service的Ribbon客戶端啓動時飢餓加載。網關作爲對外請求的入口，zuul內部使用Ribbon調用其他服務，Spring Cloud默認在第一次調用時懶加載Ribbon客戶端。zuul同樣需要維護一個相對的子應用環境的上下文，所以也需要啓動時飢餓加載。
zuul:
ribbon:
eager-load:
enabled: true