第三章 服务治理: Spring Cloud Eureka
Spring Cloud Eureka是Spring Cloud Netflix微服務套件中的一部分,它基于Netflix Eureka做了二次封裝,主要負責完成微服務架構中的服務治理功能
服務治理
服務治理可以說是微服務架構中最為核心和基礎的模塊,它主要用來實現各個微服務實例自動化注冊與發現
服務注冊:在服務治理框架中,通常都會構建一個注冊中心,每個服務單元向注冊中心登記自己提供的服務。注冊中心按服務名分類組織服務清單
服務發現:在服務治理框架下運作,服務間的調用不再通過指定具體的實例地址來實現,而是通過向服務名發起請求調用實現
Netflix Eureka
Spring Cloud Eureka,使用Netflix eureka來實現服務注冊與發現,它既包含了服務端組件也包含客戶端組件,并且均采用java編寫。
Eureka服務端:服務注冊中心,同其他服務注冊中心一樣,支持高可用配置
Eureka客戶端:主要處理服務的注冊與發現
Eureka詳解
基礎架構
整個 Eureka 服務治理基礎架構有三個核心要素:
服務注冊中心: Eureka 提供的服務端, 提供服務注冊與發現的功能, 也就是在上一節中我們實現的 eureka-server
服務提供者:提供服務的應用, 可以是 Spring Boot 應用, 也可以是其他技術平臺且遵循 Eureka 通信機制的應用。它將自己提供的服務注冊到 Eureka, 以供其他應用發現, 也就是在上一節中我們實現的 HELLO-SERVICE 應用
服務消費者:消費者應用從服務注冊中心獲取服務列表, 從而使消費者可以知道去何處調用其所需要的服務,在上一節中使用了 Ribbon 來實現服務消費,另外后續還會介紹使用 Feign 的消費方式
服務治理機制
"服務注冊中心-1" 和 “服務注冊中心-2", 它們互相注冊組成了高可用集群。
"服務提供者” 啟動了兩個實例, 一個注冊到 “服務注冊中心-1" 上, 另外一個注冊到 “服務注冊中心-2" 上
還有兩個 “服務消費者“, 它們也都分別只指向了一個注冊中心
服務提供者:
服務注冊:“服務提供者” 在啟動的時候會通過發送REST請求的方式將自己注冊到EurekaServer 上, 同時帶上了自身服務的一些元數據信息。Eureka Server接收到這個REST請求之后,
將元數據信息存儲在一個雙層結構Map中, 其中第一層的key是服務名, 第二層的key是具體服務的實例名。在服務注冊時, 需要確認一下 eureka.cli ent.register-with-eureka=true
參數是否正確, 該值默認為true。 若設置為false將不會 啟動注冊操作
服務同步:由于服務注冊中心之間因互相注冊為服務, 當服務提供者發送注冊請求到一個服務注冊中心時, 它會將該請求轉發給集群中相連的其他注冊中心, 從而實現注冊中心之間的服務同步 。 通過服務同步,兩個服務提供者的服務信息就可以通過這兩臺服務注冊中心中的任意一臺獲取到
服務續約:在注冊完服務之后,服務提供者會維護一個心跳用來持續告訴EurekaSe1-ver: "我還活著”, 以防止Eureka Server的“剔除任務 ” 將該服務實例從服務列表中排除出去,我們稱該操作為服務續約(Renew)。關于服務續約有兩個重要屬性,我們可以關注并根據需要來進行調整:
#參數用于定義服務續約任務的調用間隔時間,默認為30秒
eureka.instance.lease-renewal-interval-in-seconds=30
#參數用于定義服務失效的時間,默認為90秒 eureka.ins七ance.lease-expiration-duration-in-seconds=90
服務消費者:
荻取服務:當我們啟動服務消費者的時候, 它會發送一個REST請求給服務注冊中心,來獲取上面注冊的服務清單 。 為了性能考慮, Eureka Server會維護一份只讀的服務清單來返回給客戶端,同時該緩存清單會每隔30秒更新 一次。獲取服務是服務消費者的基礎,所以必須確保eureka.c巨ent.fetch-registry=true參數沒有被修改成false, 該值默認為七rue。若希望修改緩存清單的 更新時間,可以通過 eureka.c巨ent.registry-fetch-interval-seconds= 30參數進行修改,該參數默認值為30, 單位為秒
服務調用:服務消費者在 獲取服務清單后,通過服務名可以獲得具體提供服務的實例名和該實例的元數據信息。 因為有這些服務實例的詳細信息, 所以客戶端可以根據自己的需要決定具體調用哪個實例,在沁bbon中會默認采用輪詢的方式進行調用,從而實現客戶端的負載均衡
服務下線:當服務實例進行正常的關閉操作時, 它會觸發一個服務下線的REST請求給Eurke a Server, 告訴服務注冊中心:“我要下線了”。 服務端在接收到請求之后, 將該服務狀態置為下線(DOWN), 并把該下線事件傳播出去
服務注冊中心 :
失效剔除:為了從服務列表中將這些無法提供服務的實例剔除, Eureka Server在啟動的時候會創建一個定時任務,默認每隔一段時間(默認為60秒) 將當前清單中超時(默認為90秒)沒有續約的服務剔除出去
自我保護:EurekaServer 在運行期間,會統計心跳失敗的比例在15分鐘之內是否低于85%, 如果出現低于的情況(在單機調試的時候很容易滿足, 實際在生產環境上通常是由于網絡不穩定導致), EurekaServer會將當前的實例注冊信息保護起來, 讓這些實例不會過期, 盡可能保護這些注冊信息。 但是, 在這段保護期間內實例若出現問題, 那么客戶端很容易拿到實際已經不存在。由于本地調試很容易觸發注冊中心的保護機制, 這會使得注冊中心維護的服務實例不那么準確。 所以, 我們在本地進行開發的時候, 可以使用eureka.server.enableself-preserva巨on = false參數來關閉保護機制, 以確保注冊中心可以將不可用的實例正確剔除
配置詳解
在Eureka的服務治理體系中, 主要分為服務端與客戶端兩個不同的角色, 服務端為服務注冊中心, 而客戶端為各個提供接口的微服務應用。 當我們構建了高可用的注冊中心之后, 該集群中所有的微服務應用和后續將要介紹的一些基礎類應用(如配置中心、 API網關等)都可以視作該體系下的一個微服務(Eureka客戶端)。 服務注冊中心也一樣, 只是高可用環境下的服務注冊中心除了作為客戶端之外, 還為集群中的其他客戶端提供了服務注冊的特殊功能
Eureka服務端更多地類似于一個現成產品, 大多數情況下, 我們不需要修改它的配置信息
Eureka客戶端的配置主要分為以下兩個方面:
服務注冊相關的配置信息, 包括服務注冊中心的地址、 服務獲取的間隔時間、 可用區域等
指定注冊中心:
eureka.client.serviceUrl.defaultZone=http://localhost:llll/eureka/ #構建了高可用的服務注冊中心集群 eureka.client.serviceUrl.defaul七Zone=http://peerl: 1111/eureka/, http:/ /peer2: 111 2/eureka/
其他配置:
| 參數名 | 說明 | 默認值 |
| enabled | 啟用Eureka客戶端 | true |
| registryFetcl讓ntervalSeconds | 從Eureka服務端獲取注冊信息的間隔時間,單位為秒 | 30 |
| instancelnfoReplicationlnterva!Seconds | 更新實例信息的變化到E田eka服務端的間隔時間, 單位為秒 | 30 |
| in I tiallnstancelnfoRep I icationintervalSeconds | 初始化 實例信息到 Eureka 服務端的間隔時間, 單位為秒 | 40 |
| eurekaServiceUrlPolllntervalSeconds | 輪詢Eureka服務端地址更改的間隔時間, 單位為秒。 當我們與Spring Cloud Config配合,動態刷新Eureka的serv1ceURL地址時需要關注該參數 | 300 |
| eurekaServerReadTimeoutSeconds | 讀取Eureka Se1-ver信息的超時時間, 單位為秒 | 8 |
| eurekaServerConnectTimeoutSeconds | 連接 Eureka Server的超時時間, 單位為秒 | 5 |
| eurekaServerTotalConnections | 從Eureka客戶端到所有Eureka服務端的連接總數 | 200 |
| eurekaServerTotalConnectionsPerHost | 從Eureka客戶端到每個Eureka服務端主機的連接總數 | 50 |
| eurekaConnectionldleTimeoutSeconds | Eureka服務端 連接的空閑關閉時間, 單位為秒 | 30 |
| heartbeatExecutorT缸eadPoolSize | 心跳連接池的初始化線程數 | 2 |
| heartbeatExecutorExponentta!BackOffBound | 心跳超時重試延遲時間的最大乘數值 | 10 |
| cacheRefresl讓xecutorThreadPoolS1ze | 緩存刷新線程池的初始化線程數 | 2 |
| cacheRefreshExecutorExponentialBackOffBound | 緩存刷新重試延遲時間的最大乘數值 | 10 |
| useDnsForFetchmgServ1ceUrls | 使用DNS來獲取Eureka服務端的serviceUri | false |
| registerWitl也ureka | 是否要將自身的實例信息 注冊到Eureka服務端 | true |
| preferSameZoneEureka | 是否偏好使用處于相同Zone的Eureka服務端 | true |
| fi lterOnlyUplnstances | 獲取實例 時是否過濾, 僅保留UP狀態的實例 | true |
| fetchRegistry | 是否從Eureka服務端獲取注冊信息 | true |
服務實例相關的配置信息, 包括服務實例的名稱、IP地址、 端口號、 健康檢查路徑等
元數據:它是Eureka 客戶端在向服務注冊 中心發送注冊請求時, 用來描述自身服務信息的對象, 其中包含了一些標準化的元數據, 比如 服務名稱、 實例名稱、 實例IP、 實例端口等用于服務治理的重要信息;以及一些用 千負載均衡策略或是其他特殊用途的自定義元數據信息
實例名配置:實例名, 即Instance工nfo 中的instanceI d參數, 它是區分同 一 服務 中不同實例的唯一 標識
eureka.ins七ance.instanceid=${spring.applica七ion.name}:${random.int}}
健康檢測:默認情況下,Eureka中各個服務實例的健康檢測并不是通過spring-boot-actuator模塊的/health 端點來實現的, 而是依靠客戶端心跳的方式來保持服務實例的存活。在Eureka 的服務續約與剔除機制下,客戶端的健康狀態從注冊到注冊中心開始都會處于UP狀態, 除非心跳終止一段時間之后,服務注冊中心將其剔除。 默認的心跳實現方式可以有效檢查客戶端進程是否正常 運作, 但卻無法保證客戶端應用能夠正常提供服務。在Spring Cloud Eureka中,我們可以通過簡單的配置, 把Eureka客戶端的健康檢測交
給spring-boot-actuator模塊的/health端點, 以實現更加全面的健康狀態維護。詳細的配置步驟如下所示:
1 在pom.xml中引入spring-boot-starter-actuator模塊的依賴 2 在application.properties中增加參數配置 eureka.client.healthcheck.enabled=true 3 如果客戶端的/health端點路徑做了 一 些特殊處理,請參考前文介紹端點配置時的方法進行配置, 讓服務注冊中心可以正確訪問到健康檢測端點
其他配置:
| 參數名 | 說明 | 默認值 |
| preferlpAddres | 是否優先使用IP地址作為主機名的標識 | false |
| leaseRenewallntervallnSeconds | Eureka客戶端向服務端發送心跳的時間間隔, 單位為秒 | 30 |
| leaseExpirationDurationlnSeconds | Eureka服務端在收到砓后 一次心跳之后等待的時間上限,單位為秒。 超過該時間之后服務端會將該服務實例從服務消單中剔除, 從而禁止服務調用請求被發送到該實例上 | 90 |
| nonSecurePort | 非安全的通信端口號 | 80 |
| securePort | 安全的通信端口號 | 443 |
| nonSecurePotiEnabled | 是否啟用非安全的通信端口號 | true |
| securePortEnabled | 是否啟用安全的通信端口號 | |
| appname | 服務名,默認取spring.app巨ca巨on.name的配置值,如果沒有則為unknown | |
| hostname | 主機名, 不配置的時候將根據操作系統的主機名來獲取 |
總結
以上是生活随笔為你收集整理的第三章 服务治理: Spring Cloud Eureka的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 你比我猜游戏爆笑词语大全105个
- 下一篇: 可爱的动物名字,适合做昵称的动物名字54