Eureka 參數調優問題（注冊延遲、緩存等）

Eureka 參數調優問題

• 1、說明
• 2、案例一
• • 2.1 問題描述
  • 2.2 原因與解決
• 3、案例二
• • 3.1 問題描述
  • 3.2 原因與解決
• 4、補充說明

1、說明

1、 本篇博文建議參考 《SpringCloud 服務注冊和發現 Eureka元件》 閱讀

2、本文主要講解了以下兩個調優的案例 ：

• Eureka-client服務已經下線了，但是Eureka-Server接口傳回的資訊還是會存在。
• 新服務上線了，Eureka-Client服務不能及時擷取到。

2、案例一

2.1 問題描述

問題：Eureka-client服務已經下線了，但是Eureka-Server接口傳回的資訊還是會存在。

2.2 原因與解決

Eureka-Server中的 注冊清單（registry）會存留過期的執行個體。具體原因來自以下幾個方面：

• 1、Eureka_Client應用執行個體異常挂掉了，但是沒有能在挂掉前告知Eureka-Server服務，是以Eureka-Server服務沒有下線挂掉的Eureka-Client服務執行個體資訊。解決該問題可以依賴Eureka-Server 的 EvictionTask 去剔除已下線的Eureka-client服務執行個體資訊。

  解決方案：

         可以在Eureka-Server服務中調整EvictionTask的排程頻率，比如将排程間隔從預設的60秒，調整為5秒，即添加以下配置：

eureka:
  server:
     eviction-interval-timer-in-ms: 5000 
           

• 2.Eureka-Client應用執行個體下線時告知Eureka-Server了，但是 Eureka-Server 的 REST API 有 response cache 緩存，是以需要等待緩存過期後才能更新。

  解決方案：

  可以根據情況考慮在Eureka-Server服務中關閉readOnlyCacheMap，即修改或添加以下配置：

eureka:
    server:
         use-read-only-response-cache: false
           

       或者調整 readWriteCacheMap 的過期時間，即修改或添加以下配置：

eureka:
   server:
     response-cache-auto-expiration-in-seconds: 60
           

• 3.Eureka-Server 服務由于開啟了Self Preservation 模式（自我保護模式），導緻注冊清單（registry）的資訊不會因為過期而被剔除，直到退出自我保護模式（Self Preservation）。

解決方案：

       在測試環境中可在Eureka-Server服務中關閉自我保護模式，即修改或添加以下配置：

eureka:
   server:
      enable-self-preservation: false
           

或

eureka:
   server:
      enableSelfPreservation: false
           

       在生産環境下可以在Eureka-Server服務中把leaseRenewalIntervalInSeconds 和 renewal-percent-threshold 參數調小，進而提高觸發自我保護機制的門檻，即修改或添加以下配置：

eureka:
  server:
      renewal-percent-threshold: 0.49  ## 指定每分鐘需要收到的續約次數的閥值，預設值為0.85  
           

       以及

eureka:
   instance:
     leaseRenewalIntervalInSeconds: 10  # 預設值為30 
           

3、案例二

3.1 問題描述

問題：新服務上線了，Eureka-Client服務不能及時擷取到。

3.2 原因與解決

• 原因1：Eureka Client注冊延遲

         Eureka Client啟動後，不是立即向Eureka Server注冊的，而是有一個延遲向服務端注冊的時間。通過跟蹤源碼，可以發現預設的延遲時間為40秒，源碼在eureka-client-1.6.2jar的DefaultEurekaClientConfig類中。

  解決方案：

          将執行個體資訊變更同步到 Eureka Server的初始延遲時間，從預設的40秒修改到10秒，即修改或添加以下配置：

eureka:
   client:
     ## InstanceInfoReplicator 将執行個體資訊變更同步到 Eureka Server的初始延遲時間 ，預設為40秒
     initial-instance-info-replication-interval-seconds: 10
           

• 原因2： Eureka Client緩存

         Eureka Client保留系統資料庫資訊的緩存。該緩存每30秒更新一次。故Eureka Client重新整理本地緩存并發現其他新注冊的執行個體可能需要30秒。

  解決方案：

         在測試環境下，可以在Eureka-Client服務中适當提高 Eureka-Client端拉取 Server注冊資訊的頻率，比如将預設頻率由30秒改為5秒，即修改或添加以下配置：

eureka:
  client:
    registry-fetch-interval-seconds: 5
           

4、補充說明

       除以上問題外，本人還遇到了另一個問題。即前端請求後端接口，通過gateway網關調用具體業務伺服器時，比如登入時調用 users 服務，經常會在網關層面走熔斷機制。于是對配置檔案做了如下調整：

具體的業務服務（如 users 服務），添加或修改以下配置 ：

eureka:
   client:
      ## http 連接配接逾時時間，預設為5秒，這裡設定為30秒
      eureka-server-connect-timeout-seconds: 30
           

網關服務（ gateway），添加或修改以下配置 ：

##    eureka 服務注冊中心配置
eureka:
   client:
      ## InstanceInfoReplicator 将執行個體資訊變更同步到 Eureka Server的初始延遲時間 ，預設為40秒
      initial-instance-info-replication-interval-seconds: 10
   server:
      ## 連接配接逾時時間,節點之間連接配接逾時時長（ms） 預設 200
      peer-node-connect-timeout-ms: 5000

## 設定hystrix逾時時間（毫秒） ，預設隻有2秒，設定為30秒
hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 30000
           

以上是本人在試點微服務時，測試階段遇到的諸多問題，和一點薄見，歡迎各位大牛批評指正

.