Springcloud配置優化方案

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?