Spring Cloud之Eureka註冊中心使用

springcloud總體介紹

eureka使用

eureka客戶端實現原理分析

eureka服務端實現原理分析

註冊中心：是微服務架構中的通訊錄，用於儲存、維護服務和服務位址的對映關係。

eureka client為當前服務提供註冊、同步、查詢服務以及其實例資訊或狀態等能⼒

>
>
org.springframework.cloudgroupid
>
>
spring-cloud-starter-eureka-serverartifactid
>
dependency
>
>
>
org.springframework.cloudgroupid
>
>
spring-cloud-starter-netflix-eureka-serverartifactid
>
dependency
>

# 基本配置資訊 server.port=8000 eureka.instance.hostname=eservice1 # 是否註冊自己，預設true eureka.client.register-with-eureka=false # 是否去檢索其他的服務，預設true eureka.client.fetch-registry=false # 註冊中心訪問位址url # 高可用方案：eservice2、eservice3互相備份 # 高階設定 eureka.instance.lease-renewal-interval-in-seconds=30 #服務心跳間隔，預設為30秒 eureka.instance.lease-expiration-duration-in-seconds=90 #服務失效時間，預設為90秒 eureka.server.enable-self-preservation=false #關閉保護機制，失效就刪除,預設為true

@enableeurekaserver
public
class
}

>
>
org.springframework.cloudgroupid
>
>
spring-cloud-starter-eurekaartifactid
>
dependency
>
>
>
org.springframework.cloudgroupid
>
>
spring-cloud-starter-netflix-eureka-clientartifactid
>
dependency
>

# 埠號 server.port=9000 # 應用名稱 # 註冊中心位址 # 從服務上拉取服務，用於負載均衡 eureka.client.fetch-registry=true # 客戶端獲取服務資訊的時間間隔，預設30s eureka.client.registry-fetch-interval-seconds=30 # 客戶端應用狀態資訊上報的週期，預設30 eureka.client.instance-info-replication-interval-seconds=30

//@enableeurekaclient //eureka客戶端，必須使用eureka作為註冊中心 @enablediscoveryclient //開啟服務註冊發現功能，不限定註冊中心型別 public class @bean @loadbalanced resttemplate resttemplate()

}

eureka server會通過心跳判斷上報服務是否存活，並將「不存活」的服務（服務關閉、服務網路異常）從服務列表剔除出去。那麼，當問題出現在eureka server服務端，是eureka server服務端出現問題不能成功接收客戶端心跳資訊，而不是上報服務出現問題，此時剔除上報服務資訊就是錯誤的。

如何判斷是eureka服務端出現問題？我們知道eureka通過心跳機制對註冊服務進行續約，如果近1分鐘內，服務續約成功率低於85%時，則認為是eureka server服務端存在異常，此時服務端會進入自我保護狀態。

當eureka server服務端進入自我保護狀態後，會出現以下幾種情況：

eureka server在啟動的時候會建立乙個定時任務，每隔60秒就去將當前服務列表中超過90秒還沒續約的服務剔除出去

自我保戶機制：心跳失敗比例在1分鐘之內低於85%，eureka 註冊中心會進入自我保護模式，即不會刪除異常服務。同時真的有問題的服務也不會被剔除，當消費端請求到真的有問題的服務時，需要有容錯機制

優點：高可用、跨語言（使用rest api訪問）

缺點：eureka客戶端會拉取註冊中心全部實力資訊快取到本地，如果實力資訊過多，這些資訊又不會gc，會大量占用本地記憶體，有可能致使頻繁fullgc

比較點eureka

zookeeper

consul

nacos

運維熟悉度

相對陌生

熟悉更陌生

cap特性

apcp

ap/cp

一致性協議

http定時輪詢

zab協議

raft

通訊方式

自定義協議

更新機制

poll

push

zk watch

long polling

agent監聽方式

long polling

適用規模

20k~30k例項

10k~20k例項

<3k例項

100k+例項

效能問題

簡單的更新機制

複雜設計

規模較大時gc頻繁

擴容麻煩

規模較大時gc頻繁

3k節點以上更新列表緩慢

服務列表

獲取全部例項資訊

基於zk檔案列表儲存方式，按需獲取

全查詢 (1s一次、2s延遲阻塞)

多乙個index版本控制

根據訂閱獲取服務列表

Spring Cloud之Eureka註冊中心使用

SpringCloud之客戶端連線Eureka集群

SpringCloud之Dashboard 流監控

SpringCloud之Hystrix應用實踐

Spring Cloud之Eureka註冊中心使用

SpringCloud之客戶端連線Eureka集群

SpringCloud之Dashboard 流監控

SpringCloud之Hystrix應用實踐

相關推薦