1. 程式人生 > 實用技巧 >微服務之服務治理_Eureka

微服務之服務治理_Eureka

首先需要明確,不管是什麼事物需要”治理“,那一定是該事物存在一定問題。比如環境治理。那麼服務,或者說微服務為什麼需要治理?對於服務來說,如果它承擔的業務職責簡單,那其實治理的必要性不大,因為服務執行過程是相對透明的,即使出現問題也能較快發現、定位、回滾。當服務承擔的業務職責變多變大,那隨著更多問題的到來,服務治理開始變得必要。服務治理也與技術架構本身息息相關。

微服務系統為什麼要服務治理

微服務系統由很多個單一職責的服務單元組成,例如Netflix公司的系統是由600多個微服務構成的,而每一個微服務又有眾多例項。由於微服務系統的服務粒度較小,服務數量眾多,服務之間的相互依賴成網狀,所以微服務系統需要服務註冊中心來統一管理微服務例項,方便檢視每一個微服務例項的健康狀態。

服務治理的目標

  • 高可用

在服務治理下的微服務,只要有一個節點服務正常,就要保證服務的可用性

  • 分散式呼叫

微服務的節點散落在不同網路環境中,服務治理就需要在複雜的網路中準確的獲得服務節點的網路地址。

  • 生命週期管理

微服務把自己交給服務治理進行管理,如同bean交給spring

  • 健康度檢查

當服務節點不能正常工作,服務治理可以將其剔除

服務治理的解決方案

  • 服務註冊:服務提供方主動自報家門

服務註冊是指向服務註冊中心註冊一個服務例項,服務提供者將自己的服務資訊(如服務名、IP地址等)告知服務註冊中心。

  • 服務發現:服務消費者拉取註冊資料

服務發現是指當服務消費者需要消費另外一個服務時,服務註冊中心能夠告知服務消費者它所要消費服務的例項資訊(如服務名、IP地址等)。通常情況下,一個服務既是服務提供者,也是服務消費者。服務消費者一般使用HTTP協議或者訊息元件這種輕量級的通訊機制來進行服務消費。

  • 心跳檢測、服務續約和服務剔除

服務註冊中心會提供服務的健康檢查方案,檢查被註冊的服務是否可用。通常一個服務例項註冊後,會定時向服務註冊中心提供“心跳”,以表明自己還處於可用的狀態。當一個服務例項停止向服務註冊中心提供心跳一段時間後,服務註冊中心會認為該服務例項不可用,會將該服務例項從服務註冊列表中剔除。如果這個被剔除掉的服務例項過一段時間後繼續向註冊中心提供心跳,那麼服務註冊中心會將該服務例項重新加入服務註冊中心的列表中

  • 服務下線:服務提供方主動發起下線

服務治理的技術選型

Eureka Consul Nacos
一致性 AP AP AP/CP
效能
應用 主流 非主流 穩中有升

注意: 我們現在公司用的nacos主要用的是nacos config

Eureka

下面主要介紹下Eureka。Eureka server和client的搭建 這裡不做介紹。之前分享zuul閘道器的程式碼中已經說過

注意:Eureka是基於CAP定理的AP系統

Eureka 管理介面介紹

  • Current time:當前的系統時間
  • Uptime:已經運行了多少時間
  • Lease expiration enabled:是否啟用租約過期 ,自我保護機制關閉時,該值預設是true, 自我保護機制開啟之後為false。和自我保護互斥
  • Renews threshold: 每分鐘最少續約數,Eureka Server 期望每分鐘收到客戶端例項續約的總數。
  • Renews (last min): 最後一分鐘的續約數量(不含當前,1分鐘更新一次),Eureka Server 最後 1 分鐘收到客戶端例項續約的總數。

紅字提醒

  • 自我保護機制開啟
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.

// 掛掉的服務有可能會被錯誤的當做UP,(在一定時間內)續約成功的節點個數佔已註冊總服務的比值,已經低於限定值,因此所有節點都不會過期,服務自保開啟

  • 主動關閉了自我保護機制
THE SELF PRESERVATION MODE IS TURNED OFF.THIS MAY NOT PROTECT INSTANCE EXPIRY IN CASE OF NETWORK/OTHER PROBLEMS.

公司內就出現了上面的提示。說明我們部署的server是主動關閉了自我保護機制

自我保護機制

Eureka的自我保護特性主要用於減少在網路分割槽或者不穩定狀況下的不一致性問題

自我保護機制產生的原因
Eureka在執行期間會統計心跳成功的節點。如果15分鐘內所有成功續約的節點佔所有註冊節點85%以下
Eureka Server會將當前的例項註冊資訊保護起來,同時提示一個警告,一旦進入保護模式,
Eureka Server將會嘗試保護其服務登錄檔中的資訊,不再刪除服務登錄檔中的資料。也就是不會登出任何微服務。

上面提到公司是主動關閉了自我保護機制。雖然看不到server的程式碼可以猜測出公司的配置

Eureka Server端:配置關閉自我保護,並按需配置Eureka Server清理無效節點的時間間隔。

eureka.server.enable-self-preservation# 設為false,關閉自我保護
eureka.server.eviction-interval-timer-in-ms # 清理間隔(單位毫秒,預設是60*1000)

Eureka Client端:配置開啟健康檢查,並按需配置續約更新時間和到期時間

eureka.instance.lease-renewal-interval-in-seconds# 續約更新時間間隔(預設30秒)
eureka.instance.lease-expiration-duration-in-seconds # 續約到期時間(預設90秒)

看看 公司client 的配置

eureka:
  instance:
    prefer-ip-address: true
    instance-id: ${spring.application.name}:${spring.client.ipAdress}:${server.port}
    lease-expiration-duration-in-seconds: 30 #服務過期時間配置,超過這個時間沒有接收到心跳EurekaServer就會將這個例項剔除
    lease-renewal-interval-in-seconds: 10 #服務重新整理時間配置,每隔這個時間會主動心跳一次