Eureka常見問題

Eureka注冊服務(wù)慢

• 默認(rèn)情況，服務(wù)注冊到Eureka Server 的過程比較慢。在開發(fā)或者測試時候，如果能夠加速注冊的過程，從而提升工作效率。
• Spring Cloud官方文檔詳細(xì)描述了該問題的原因并提供了解決方案：

//原文 Why is it so Slow to Register a Service? Being an instance also involves a periodic heartbeat to the registry (via the client’s serviceUrl) with default duration 30 seconds. A service is not available for discovery by clients until the instance, the server and the client all have the same metadata in their local cache (so it could take 3 heartbeats). You can change the period using eureka.instance.leaseRenewalIntervalInSeconds and this will speed up the process of getting clients connected to other services. In production it’s probably better to stick with the default because there are some computations internally in the server that make assumptions about the lease renewal period.

• 解釋如下：服務(wù)的注冊涉及到周期性的心跳檢測，默認(rèn)Eureka是30秒發(fā)送異常心跳（通過客戶端配置的serviceUrl）。只有當(dāng)前實例，服務(wù)器端和客戶端的本地緩存中的元數(shù)據(jù)都相同的時候，服務(wù)才能被其他客戶端發(fā)現(xiàn)（所以可能需要3次心跳）。可以使用參數(shù)eureka.instance.leaseRenewalIntervalInSeconds修改時間間隔，從而加快客戶端連接到其他服務(wù)的過程。在生成環(huán)境中最好使用默認(rèn)的值，因為在服務(wù)器內(nèi)部有一些計算，這些配置的修改都會對其進(jìn)行影響。

Eureka已停的微服務(wù)節(jié)點注銷慢或不注銷

• 在開發(fā)環(huán)境，我們希望Eureka Server能迅速有效的注銷已經(jīng)停止的微服務(wù)實例。然而，由于Eureka Server 清理無效節(jié)點的周期比較長（默認(rèn)90s），以及自我保護(hù)模式等原因，可能會遇到微服務(wù)注銷慢甚至不注銷的情況。解決方案如下：
• Eureka Server端：配置關(guān)閉自我保護(hù)，并且按需配置Eureka Server清理無效節(jié)點的時間間隔。配置如下：

eureka.server.enable-self-preservation #設(shè)置為false，關(guān)閉自我保護(hù)，從而保證會注銷微服務(wù) eureka.server.eviction-interval-tomer-in-us #清理間隔（單位毫秒，默認(rèn)60*1000）

• Eureka Client端：配置開啟健康檢查，并按照業(yè)務(wù)需要配置續(xù)約更新時間和到期時間。配置如下：

eureka.client.healthcheck.enabled #設(shè)為true，開啟健康檢查（需要添加依賴spring-boot-starter-actuator） eureka.instance.lease-renewal-interval-in-seconds #續(xù)約更新時間間隔，默認(rèn)30秒 eureka.instance.lease-expiration-duration-in-seconds #續(xù)約到期時間默認(rèn)90秒

• 以上的配置僅建議在開發(fā)的時候，測試的時候用，生產(chǎn)環(huán)境如非必要建議堅持使用默認(rèn)值，因為修改Eureka的續(xù)約評率可能會打破Eureka的自我保護(hù)特性，這就意味著生產(chǎn)環(huán)境中如果真正遇到網(wǎng)絡(luò)問題或者其他情況無法注冊，或者無法發(fā)送心跳等情況，此時Eureka的自我保護(hù)也無法使用，可能導(dǎo)致更嚴(yán)重的問題，所以堅持默認(rèn)配置還是有好處的，具體情況結(jié)合實際業(yè)務(wù)需求來改變。如下配置示例

#Server配置示例server:enable-self-preservation: falseeviction-interval-timer-in-ms: 4000 #client配置示例 server:port: 8761 eureka:client:registerWithEureka: falsefetchRegistry: falseserviceUrl:defaultZone: http://localhost:8761/eurekahealthcheck:enable: trueinstance:lease-expiration-duration-in-seconds: 30lease-renewal-interval-in-seconds: 10

• 以下界面表示處于自我保護(hù)狀態(tài)下的Eureka界面截圖信息：
  

自定義微服務(wù)的InstandeID

• InstanceID用于唯一事變注冊到Eureka Server上的微服務(wù)實例。在Eureka的首頁可以直觀的看到各個微服務(wù)的InstanceID，如上圖中所示，localhost:microservice-consumer-business:8080就是instanceID
• Spring Cloud中，服務(wù)的InstanceID默認(rèn)值是${spring.cloud.client.hostname}: ${spring.aplication.name}: &{spring.aplication.instance_id: ${server.port}}。如果想自定義這部分內(nèi)容，只需要在微服務(wù)中配置eureka.instance.instance-id,如下案例：

server:port: 8001 spring:application:name: microservice-provider-user eureka:instance:prefer-ip-address: trueinstance-id: ${spring.cloud.client.ipAddress}:${server.port}

• 這樣配置后，可以將微服務(wù)microservice-provider-user的instanceID設(shè)置為ip：端口的形式。效果如下
  

Eirela的UNKNOWN問題總結(jié)與解決

• 注冊信息UNKNOWN，在剛開始學(xué)SpringCloud的時候遇到過這個問題，如下圖，有兩種UNKNOWN的情況，一種是應(yīng)用名稱UNKNOW，另外一種是應(yīng)用狀態(tài)的UNKNOWN，下面分別討論兩種情況
  

應(yīng)用名稱UNKNOWN

• 應(yīng)用名稱UNKNOWN顯然是不應(yīng)該存在于任何環(huán)境下的微服務(wù)機(jī)器中，首先是微服務(wù)的名字不能夠望文見意，無法直觀看出這個那個服務(wù)；更重要的是，我們經(jīng)常使用引用名稱消費(fèi)對應(yīng)的微服務(wù)的接口，比如我們用FegnClient的時候，必須用到服務(wù)名稱。
• 一般來說，有兩種情況可能導(dǎo)致這個問題的產(chǎn)生：
  • 未配置spring.application.name或者eureka.instance.appname屬性（配置了但是名稱沒有寫配置的是空值）。如果這兩個屬性均是空，就會導(dǎo)致應(yīng)用名稱UNKNIWN的問題。
  • 某些版本的SpringFox會導(dǎo)致這個問題，不讓SpringFox2.6.0。建議使用SpringFox2.6.1或者更高的版本。

微服務(wù)狀態(tài)UNKNOWN

• 微服務(wù)狀態(tài)UNKNOWN同樣麻煩，一般情況，Loadbalance負(fù)責(zé)均衡器只會請求UP狀態(tài)的服務(wù)器。該問題一般由監(jiān)考檢查導(dǎo)致的
• eureka.client.healthcheck.enabled=true必須設(shè)置在application.yml中，而不能設(shè)置在bootstrap.yml中，否則一下場景下會導(dǎo)致應(yīng)用狀態(tài)UNKNOWN的問題。

Hystrix/Feign 整合Hystrix后首次請求失敗

• 在某些場景下，Feign或者Ribbon整合Hystrix后，會出現(xiàn)首次調(diào)用失敗的問題。

原因分析

• Hystrix默認(rèn)的超時時間是1秒，如果在1秒內(nèi)得不到響應(yīng)，就會進(jìn)入fallback邏輯。由于Spring的懶加載機(jī)制，首次請求會比較慢，因此在某些機(jī)器（例如配置比較低的機(jī)器）上，上次請求需要的時間可能會大于1秒。因此出現(xiàn)這個問題

解決方案

• 方法一，延長Hystrix的超時時間，如下配置可以讓Hystrix超時時間修改為5秒：

hystrix.command.default.execution.timeout.enabled: false

• 方法二：禁用Hystrix的超時，配置示例如下：

Hystrix.command.default.execution.timeout.enabled:false

• 方法三：對于Feign，還將可以禁用Hystrix，這樣既可以為Feign全局禁用Hystrix支持，不過這種方式比較極端，不推薦這樣做。示例如下：

feign.hystrix.enabled: false

[下一篇 SpringCloud常見問題總結(jié)(二)(https://blog.csdn.net/liaojiamin0102/article/details/107408563)

總結(jié)

以上是生活随笔為你收集整理的SpringCloud常见问题总结(一)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。