Eureka大雜燴

文章目錄

\color {red}{本文將多篇前輩的博客整合一下，方便自己查看}

Eureka 作爲Spring Cloud 體系中最核心、默認的註冊中心組建、研究他的運行機制，有助於我們在工作中更好使用他

0、爲什麼需要註冊中心

過去每個應用都是一個CPU，一個主機上的單一系統，然而今天，隨着大數據和雲計算時代的到來，任何獨立的程序都可以運行在多個計算機上，並且隨着業務的發展，訪問用戶量的增加，開發人員或小組的增加，系統會被拆分多個功能模塊，拆分後每個功能模塊作爲一個獨立的子系統提供其職責範圍內的功能。而多個子系統中，由於職責不同並且會存在相互調用，同時可能每個子系統還需要多個實例部署在多臺服務器或者鏡像中，導致子系統的相對調用形式一個錯綜複雜的網狀結構，
單體應用
- 隨着業務的發展，經過了多個系統架構的演變，變成這樣的

從系統架構的演變到對於微服務架構的思考

爲什麼上圖中的系統演變最終會變成如圖所示的樣子？是一種架構思維，這裏不擴張來說，簡單描述一下微服務架構是爲了解決什麼問題，隨着系統結構、架構的演變，系統功能的增加，用戶量的增加，開發人員的增加等各種增加情況下，需要由一個比較好的擴展的系統架構來快速、儘量減少代碼改動的前提下以支持系統功能開發，用戶增加導致的硬件資源的橫向擴容，以及開發人員的增加時的協同工作效率，在此基礎上，需要解決系統的穩定性、容錯性、高併發性的支持性等等，以及隨着系統功能的增加如何有效管理系統，排查、定位系統問題。同時當參與項目的（包括測試、運維、業務等人員）越來越多時，如何高效的彼此之間的協同辦公的效率等等。
所以微服務架構需要考慮的不僅僅是軟件架構本身，需要從參與到整個項目實施過程中的各個環節，可能的問題以及人員協同的整體情況去考慮，讓整個項目做到可用（滿足功能以及硬件資源的橫向擴容）、可行（滿足整個系統運行中的各個點的監控、拍錯等）可持續（滿足系統功能的可持續集成，以及系統運行的可持續性）以及高效（系統運行的高效、人員協同工作的高效、功能的迭代的高效等）

1、 Eurake 核心概念

服務提供者或服務的消費者，本質上也是Eureka Client角色，整體上可以分爲兩個主體：Eureka Server 和Eureka Client

1.1 Eurake Server: 註冊中心服務端

註冊中心服務器主要對外提供了三個功能（服務註冊、提供註冊表、同步狀態）
服務註冊
- 服務提供者啓動時，會通過Eureka Client 向Eureka Server註冊信息，Eureka Server會存儲該服務的信息，Eureka Server內部有兩層緩存機制來維護整個註冊表
- Eureka Server同時也是一個Eureka Client，在不禁止Eureka Server的客戶端行爲時，它會向配置文件中的其他Eureka Server 進行拉取註冊表、服務註冊和發送心跳等操作
- eureka server端通過 appName 和 instanceInfoId 來唯一區分一個服務實例，服務實例信息是保存在哪裏呢？其實就是一個Map中：
- ```
// 第一層的key是appName，第二層的key是instanceInfoId
private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry 
    = new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();
```

寫入本地reistry

服務信息（InstanceInfo ) 保存在Lease中，寫入本地registry對應方法com.netflix.eureka.registry.PeerAwareInstanceRegistryImpl#register，Lease 統一保存在內存的ConcurrentHashMap中，在服務註冊過程中，首先加個讀鎖，然後從registry中判斷該Lease是否已經存在，如果已經存在則比較lastDirtyTimestamp，時間戳，取二者最大的服務信息，避免發生數據覆蓋，使用instanceInfo 創建一個新的InstanceInfo:

if (existingLastDirtyTimestamp > registrationLastDirtyTimestamp) {
    // 已存在Lease則比較時間戳，取二者最大值
    registrant = existingLease.getHolder();
}
Lease<InstanceInfo> lease = new Lease<InstanceInfo>(registrant, leaseDuration);
if (existingLease != null) {
    // 已存在Lease則取上次up時間戳
    lease.setServiceUpTimestamp(existingLease.getServiceUpTimestamp());
}

public Lease(T r, int durationInSecs) {
    holder = r;
    registrationTimestamp = System.currentTimeMillis(); // 當前時間
    lastUpdateTimestamp = registrationTimestamp;
    duration = (durationInSecs * 1000);
}

同步給其他peer
- InstanceInfo 寫入到本地的registry之後，然後同步給其他peer節點，對應的方法com.netflix.eureka.registry.PeerAwareInstanceRegistryImpl#replicateToPeers，如果當前節點接收到的InstanceInfo 本身就是另一個節點同步過來，則不會繼續同步給其他節點，避免形成廣播效應， InstanceInfo 同步時，會排除當前節點
- InstanceInfo 的狀態有依次以下幾種：Heartbeat， Register、cancel、StatusUpadte, DeleteStatusOverride, 默認情況下同步操作時批量異步執行的，同步請求首先緩存到Map中，key爲requestType + appName +id ,然後由發送線程將請求發送到peer節點
  
  Peer 之間的狀態是採用異步的方式同步的，所以不保證節點間狀態一定是一致的，不過基本能保證最終狀態一致性的，結合服務發現的場景，實際上也並不需要節點間的狀態強制一致性，在一段時間內（30s），節點A比節點B多一個服務實例或少一個服務實例，在業務上也是完全可以接受的（Service Consumser 則一般也會實現錯誤重試和負載均衡機制），所以按照CAP理論，Eureka的選擇是AP
  
  如果同步過程中，出現異常怎麼辦？這個時候根據異常信息做對應的處理，如果讀取超時或網路連接異常，則稍後重試，如果其他異常則打印錯誤日誌不在後續處理
提供註冊表
- 服務消費者在調用服務時，如果Eurake Client 沒有緩存註冊表的話，會從Eureka Server獲取最新的註冊表
同步狀態
- Eureka Client 通過註冊、心跳機制和Eureka Server 同步當前客戶端的狀態
Eureka Server 的伸縮容
- Eureka Server是怎麼知道有多少Peer的呢？Eureka Server在啓動後會調用EurekaClientConfig.getEurekaServerServiceUrls來獲取所有的Peer節點，並且會定期更新，定期更新頻率可以通過eureka.server.peerEurekaNodesUpdateIntervalMs 配置。
- 這個方法的默認實現是從配置文件中讀取，所以如果Eureka Server節點相對固定的話，可以通過在配置文件中配置來實現，如果希望能更加靈活的控制Eureka Server節點，比如動態擴容、縮容，那麼可以override getEurekaServerServiceUrls方法，提供自己的實現。比如我們的項目中會通過數據庫Eureka Server列表。
  
  eureka server啓動時把自己當做是Service Consumer 從其他Peer Eureka獲取所有服務的註冊信息，然後對每個服務信息，在自己這裏執行Register， isReplication=true, 從而完成初始化

1.2、Eureka client 的註冊中心客戶端

Eureka Client 是一個java客戶端，用於簡化與EurekaServer的交互，Eureka Client 會拉取，更新和緩存Eureka Server中的信息，因此當所有的Eureka Server節點都宕掉，服務消費者依然可以使用緩存中的信息找到服務提供者，但是當服務有更改的時候出現信息不一致
Register : 服務註冊
- 服務提供者，將自身註冊到註冊中心，服務提供者也是一個Eureka Client，當Eureka Client 想Eureka Server 註冊時，他提供自身的元數據，比如IP地址，端口，運行狀態指示符URL，主頁等,需要注意的是，需要確保配置eureka.client.registerWithEureka=true，register邏輯在方法AbstractJerseyEurekaHttpClient.register中，Server Provider 會依次註冊到配置的EurekaServer URL上，如果註冊出現異常，則會繼續註冊其他的url
Renew 服務續約
- Eureka Client 會每隔30秒發送一次心跳來續約，通過續約來告知Eureka Server該 Eureka Client 運行正常，沒有出現問題i，默認情況下，如果Eurake Server 在90秒內沒有收到Eureka Client的續約，Server端會實例從其註冊表中刪除，此時間可以配置，一般情況不建議更改
服務續約的兩個屬性

服務續約任務的調用間隔時間，默認爲30秒
eureka.instance.lease-renewal-interval-in-seconds=30

服務失效的時間，默認爲90秒。
eureka.instance.lease-expiration-duration-in-seconds=90

Eviction 服務剔除
- 當Eureka Client和Eureka Server 不再有心跳時，Eureka Server 會將該服務實例從服務註冊列表中刪除，即服務剔除
Cancel 服務下線（com.netflix.eureka.registry.PeerAwareInstanceRegistryImpl#cancel）
- Eureka Client 在程序關閉時想Eureka Server 發送取消請求，發送請求後，該客戶端實例信息將從Eureka Server的實例註冊表中刪除。該下線請求不會自動完成，他需要調用以下內容，需用及時通知Eureka Server 把自己剔除，從而避免客戶端調用已經下線的服務，邏輯本身比較簡單，通過對方法標記爲@PreDestroy, 從而在服務shutdown的時候會被觸發。
- ```
DiscoveryManager.getInstance().shutdownComponent()；
```
GetRegisty :獲取註冊列表信息
- EurekaClient 從服務器獲取註冊表信息，並將其緩存到本地，客戶端會使用該信息查找其他服務，從而進行遠程調用，該註冊列表信息定期（每30秒鐘）更新一次，每次返回註冊列表信息可能與Eureka Client 緩存信息不同， Eureka Client 自動處理。
- 如果由於某中原因導致註冊列表信息不能及時匹配，Eureka Client 則會重新獲取整個註冊表的信息。 Eureka Server緩存註冊表信息，整個註冊表以及每個應用程序的信息進行壓縮了，壓縮內容和沒有壓縮的內存完全一樣。Eureka Client 和 Eureka Server 可以使用JSON/XML 格式進行通訊，在默認情況下Eureka Client 使用壓縮JSON格式來獲取註冊列表的信息。
- Eureka consumer 服務信息的拉取分爲增量拉取和全量拉取，eureka consumer啓動時進行全量拉取，運行過程中有定時任務進行增量拉取，如果網絡出現異常，可能導致先拉取的數據被舊數據覆蓋（比如上一次拉取線程獲取結果較慢，數據已更新情況下使用返回結果再次更新，導致數據版本落後）產生髒數據，對此，eureka通過類型AtomicLong 和 fetchRegistryGeneration對數據版本進行跟蹤，版本不一致則表示此次拉取的數據過期
  
  fetchRegistryGeneration過程是在拉取數據之前，執行fetchRegistryGeneration.get獲取當前版本號，獲取到數據後，通過fetchRegistryGeneration.compareAndSet 來判斷當前版本是否已經更新，
  
  注意：如果增量式更新出現意外，會再次進行一次全量拉取更新。
獲取服務是服務消費者的基礎，所以必須有兩個重要參數需要注意：

# 啓用服務消費者從註冊中心拉取服務列表的功能
eureka.client.fetch-registry=true

# 設置服務消費者從註冊中心拉取服務列表的間隔
eureka.client.registry-fetch-interval-seconds=30

Remote Call :遠程調用
- 當Eureka Client 從註冊中心獲取到服務提供者信息後，就可以通過Http 請求調用對應的服務；服務提供者多個時候，Eureka Client 客戶端會通過Ribbon 自動進行負載均衡。

2、自我保護機制

默認情況下，如果Eureka Server 在一定的90s內沒有收到某個微服務實例的心跳，會註銷該實例。但是在微服務架構下服務之間通常都是跨進程調用，網絡通信往往會面臨着各種問題，比如微服務狀態正常，網路分區故障，導致該實例被註銷
固定時間內大量實例被註銷，可能會嚴重威脅整個微服務的可用性，爲了解決這個問題，Eureka開發了自我保護機制，那麼什麼是自我保護機制呢？
Eureka Server 在運行期間會去統計心跳失敗比例在15分鐘內是否低於85% ，如果低於85%，Eureka Server 即會進入自我保護機制
Eureka Server觸發自我保護機制後，頁面會出現提示
Eureka Server 進入自我保護機制，會出現以下幾種情況：
1. Eureka 不在從註冊列表中移除因爲長時間沒有收到心跳而應該過期的服務
2. Eureka 仍然能夠接受新服務的註冊和查詢請求，但是不會同步到其他節點上（即保證當前節點依然可用）
3. 當網絡穩定時，當前實例新的註冊信息會被同步給其他節點中。
Eureka 自我保護機制是爲了防止誤殺服務而提供一種機制，當個別客戶端出現心跳失聯時，則認爲是客戶端的問題，剔除客戶端，當Eureka 捕獲到大量的心跳失效時，則認爲是可能是網絡問題，進而自我保護機制，當客戶端恢復心跳時，Eureka 會自動退出自我保護機制。
如果在保護期內剛好這個服務提供者非正常下線了，此時服務消費者就會拿到無效的服務實例，即會調用失敗，對於這個問題需要服務消費端要有一些容錯機制，如重試，斷路器等。
通過在Eureka Server 配置如下參數，開啓或關閉保護機制，生產環境建議打開
```
eureka.server.enable-self-preservation=true
```

3、Eureka 集羣原理

再看看Eureka 集羣的工作原理，我們假設有三臺Eureka SErver 組成的集羣，第一臺Eureka Server在北京機房，另外兩臺 Eureka Server在深圳和西安機房，這樣三臺Eureka Server就組成了一個跨區域的高可用的集羣，只要是三個地方的任意一個機房不出問題，都不會影響到整個架構的穩定性
從圖中可以看出Eureka Server 集羣相互之間通過Replicate 來同步數據，相互之間不區分主節點和從節點，所有節點的都是平等的，在這架構中節點通過彼此相互註冊來提高可用性，每個節點需要添加一個或多個有效的serviceUrl指向其他節點。
如果某臺Eureka Server 宕機， Eureka Client 的請求會自動切換到新的Eureka Server 節點。當宕機的服務器重新恢復後，Eureka 會再次將其納入到服務集羣管理中，當節點開始接受客戶端請求時，所有的操作都會進行節點間複製，將請求複製到其他Eureka Server 當前所知的所有節點中。
另外Eureka Server 同步遵循着一個非常簡單的原則，只要一條邊將節點連接，就可以進行信息傳播與同步，所以如果存在多個節點，只需要節點之間兩兩連接起來形式通路，那麼其他註冊中心都可以共享信息，每個Eureka Server 同時也是Eureka Client，多個Eureka Server之間通過P2P的方式完成服務註冊表的同步
Eureka Server 集羣之間的狀態是採用異步方式同步的，所以不保證節點間的狀態一致性的，不過基本保證最終一致性的
Eureka 分區
- Eureka 提供了Region 和Zone 兩個概念來進行分區，這個兩個概念均來自亞馬遜的AWS：
region
- 可以理解爲地理上不同區域，比如亞洲地區，中區，深圳，等等，沒有具體的大小的限制，根據項目具體的情況，可以自行合理劃分region
zone ：
- 可以理解爲region內的具體機房號，比如說region劃分了深圳，然後深圳有兩個機房，就可以再此region之下劃分出zone1，zone2 兩個zone。
- 上圖中的us-east-1c/ us-east-1d , us-east-1e 就是代表不同的Zone，Zone 內的Eureka Client 優先和Zone 內的Eureka Server進行心跳同步，同樣調用端優先在Zone內的Eureka Server 獲取服務列表，當Zone 內的Eureka Server掛掉之後，纔會從別的Zone中獲取信息。
Eureka 保證AP
- Eureka Server各個節點都是平等的，幾個節點掛掉不會影響到正常節點的工作，剩餘的節點依然可以提供註冊和查詢的服務，而Eureka Client 在向某個Eureka註冊時，如果發現連接失敗，則會自動切換到其他節點，只有一臺Eureka Server 還在，就能保證註冊服務可用（保證可用性），只不過查到的信息可能不是最新的（不保證強一致性）

4、Eureka 工作流程

Eureka Server 啓動成功，等待服務端註冊，在啓動過程中如果配置集羣，集羣之間定時通過Replicate 同步註冊表，每個Eureka Server 都存在獨立完整的服務註冊表信息
Eureka Client 啓動時根據配置的Eureka Server 地址去註冊中心註冊服務
Eureka Client 會每30秒想Eureka Server 發送一次心跳請求，證明客戶端服務正常
當Eureka Server 90s內沒有收到Eureka Client 的心跳，註冊中心則認爲該節點失效了，會註銷該實例
單位時間內Eureka Server 統計到大量的Eureka Client 沒有上送心跳，則認爲可能爲網絡異常，進入自我保護機制，不在剔除沒有上送心跳的客戶端
當Eureka Client 心跳請求恢復正常之後，Eureka Server 自動退出自我保護模式
Eureka Client 定時全量或增量從註冊中心獲取服務註冊表，並將獲取到的信息緩存到本地
服務調用時，Eureka Client 會先從本地緩存找尋調取的服務，如果獲取不到，先從註冊中心刷新註冊表，再同步到本地緩存
Eureka Client 獲取目標服務器的信息，發起服務調用
Eureka Client 程序關閉時，向Eureka Server 發送取消請求， Eureka Server 將實例從註冊表中刪除

Eureka 爲了保障註冊中心的高可用性，容忍了數據的非強一致性，服務節點間的數據可能不一致，Client-Server 間的數據可能不一致，比較適合跨越多機房，對註冊中心服務可用性要求較高的使用場景。

5、dubbo ,zookeeper , eureka之間的關係與區別

Dubbo 相當於Spring Cloud
- Dubbo是個微服務整體架構的框架，提供的功能包括服務註冊發現，遠程調用，監控等待，對標的項目是Spring Cloud，但Spring Cloud 是一系列軟件，有很多組件來拼裝提供微服務的總體架構。Dubbo自己全部封裝了。
zookeeper 集成在Dubbo中以後，相當於Spring Cloud 中的Eureka
- Dubbo的服務發現模塊基於zookeeper實現。
- Eureka是spring cloud 下一個專門負責微服務服務註冊和發現的組件，Eureka就是爲了服務發現而設計的，是Dubbo對應的概念的一部分
原本的zookeeper
- zookeeper是用來保證分佈式一致性的一個軟件，不是爲了服務發現註冊而設計。只不過他的特性也可以被二次開發服務發現註冊中心罷了。

6、作爲服務註冊中心，Eureka 比Zookeeper 好在哪裏？

著名的CAP理論指出，一個分佈式系統不可能同時滿足C (一致性) A（可用性）和 P（分區容錯性）,由於分區容錯性在是分佈式系統中必須要保證的，因此我們只能在A和C之間進行權衡，在此zookeeper 保證的是CP，而Eureka 保證是AP
zookeeper 保證 CP
- 當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊信息，但不能接受服務註解down掉不可用，也就是服務註冊對可用性的要求高於一致性，但是zk會出現這樣一種情況，當master節點因爲網絡故障與其他節點失去聯繫時，剩餘節點會重新進行leader選舉，問題在於，選舉leader的時間太長，30~120s，且選舉期間整個zk集羣是不可用的，這就導致在選舉期間註冊服務癱瘓，在雲部署的環境下，因爲網絡問題使得整個zk集羣失去master節點是較大概率發生的事情，雖然服務能夠最終恢復，但是漫長的選舉時間導致了的註冊長期不可用是不能容忍的。
Eureka 保證AP
- Eureka 看明白了這點，因此在設計時就先保證可用性，Eureka各個節點都是平等的，幾個節點掛掉不會影響到正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務。而Eureka的客戶端在向其中一個Eureka 註冊或時如果發現連接失敗，則會自動切換到其他節點，只有有一臺Eureka還在，就能保證註冊服務可用（保證可用性）只不過查到的信息可能不是最新的（不保證強一致性），那麼除此之外，Eureka還是有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認爲客戶端與註冊中心出現網絡故障，此時會出現以下幾種情況：
  1. Eureka 不在從註冊列表中移除因爲長時間沒有收到心跳而應該過期的服務。
  2. Eureka仍然能夠接受服務的註冊和查詢請求，但不會被同步到其他節點上（即保證當前節點仍然可用）
  3. 網絡穩定時，當前實例新的註冊信息會被同步到其他節點中，
- 因此，Eureka可以很好的應對網絡故障導致部分接地那失去聯繫的情況，而不會像zookeeper那麼使得整個真粗服務癱瘓
數據一致性
- ZAB 是zookeeper的原子廣播協議，基於Paxos 算法改的。分佈式一致性算法 Paxos
- Raft 是工程上使用較爲廣泛的強一致性，去中心話，高可用的分佈式協議分佈式一致性算法 Raft
技術對照表

7、consul、eureka、nacos 對比

配置中心
- eureka 不支持
- consul 支持但用起來偏麻煩，不太符合Spring Boot框架的命名風格，支持動態刷新
- nacos 支持，用起來簡單，服務Spring Boot的命名風格，支持動態刷新
註冊中心
- eureka
  - 依賴：依賴Zookeeper
  - 應用內外：依賴於應用自身完成服務註冊與發現
  - ACP原則：遵循AP（可用性+分區容忍）原則，有較強的可用性，服務註冊塊，但是犧牲了一定的一致性。
  - 版本迭代：目前已經不進行升級
  - 集成支持：只支持SpringCloud集成
  - 訪問協議：HTTP
  - 雪崩保護：支持雪崩保護
  - 界面：英文界面，不符合國人習慣
  - 上手：容易
- consul
  - 依賴：不依賴其他組件
  - 應用內外：屬於外部應用，入侵性小
  - ACP原則：遵循CP原則（一致性和分區容忍）服務註冊稍慢，由於其一致性導致在Leader掛掉時重新選舉期間整個consul不可用
  - 版本迭代：目前仍然進行版本迭代
  - 集成支持：只支持SpringCloud K8S集成
  - 訪問協議：HTTP/DNS
  - 雪崩保護：不支持雪崩保護
  - 界面：英文界面，不符合國人習慣
  - 上手：複雜一些
- consul
  - 依賴：不依賴其他組件
  - 應用內外：屬於外部應用，入侵性小
  - ACP原則：通知遵循CP原則（一致性+分區容忍）和 AP（可用性+分區容忍）原則
  - 版本迭代：目前仍然進行版本迭代
  - 集成支持：支持dubbo，springcloud ，k8s繼承
  - 訪問協議：HTTP/動態DNS/UDP
  - 雪崩保護：支持雪崩保護
  - 界面：中文界面
  - 上手：容易
Nacos 的CP模式切換
- ```
curl -X PUT `$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'
```
- 一般來說，如果不需要存儲服務級別的信息且服務實例是通過nacos-client 註冊，並能保持心跳上報，那麼就可以選擇AP模式，當前主流的服務如Spring Cloud和Dubbo服務，都是適用於AP模式，AP模式爲了服務的可能性而減弱了一致性，因此AP模式下只支持註冊臨時實例。
- 如果需要在服務級別編輯或存儲配置信息，那麼CP是必須的，K8s服務和DNS服務則適用於CP模式，CP模式下支持註冊持久化實例，此時則是以Raft協議爲集羣運行模式，該模式下注冊實例之間必須先註冊服務，如果服務不存在，則會返回錯誤。

8、Eureka 應用解決客戶端容錯問題（hystrix）

hystrix是一個實現了超時機制和斷路器模式的工具類庫，在正常情況下，斷路器關閉，可正常請求依賴的服務，當一段時間內，請求失敗率達到一定閾值，斷路器就會打開，此時，不會再去請求依賴的服務，斷路器打開一段時間後，會自動進入半開狀態，此時斷路器允許一個請求訪問依賴的服務，如果請求能夠調用成功，則關閉斷路器，否則繼續保持打開的狀態。
通過上述機制保護應用，從而防止雪崩效應並提高應用的可用性
其實，在我們日誌訪問網站的過程中，每次請求都對應一個線程，如果響應太慢，這個線程就得不到釋放，而如果線程得不到釋放會越積越多，最後系統資源耗盡，導致服務不可用

10、Q&A

Eureka Server如何實現高可用？
- 機制：將自己做爲註冊中心向其他服務註冊中心註冊自己，這樣就形式一組相互註冊的服務的註冊中心
- 實現： Eureka 服務端，我們稱爲服務註冊中心，他同其他服務註冊中心一樣，支持高可用配置、他依託於強一致性提供良好的服務實例可用性，可以應對多種不同的故障場景，如果Eurake以集羣方式部署，當集羣中有分區出現故障時，那麼Eureka就轉入自我保護機制，其他分片會把他們的狀態再次同步過來，以及在AWS的實例爲例，Netflix推薦每個可用的區域運行一個Eureka服務端，通過他形式集羣，不同可用區域的服務註冊中心通過異步模式相互複製各自的狀態，這意味着在任意給定的時間點每個實例關於所有服務的狀態是有細微的差別的。
- Eureka客戶端，主要處理服務的註冊與發現，客戶端服務通過註解和參與配置方式，嵌入在客戶端應用程序的代碼中，在應用程序運行時，Eureka客戶端向註冊中心註冊自身提供的服務並週期性第發送心跳來更新他的服務租約，同時他也能從服務端查詢當前註冊的服務信息並把它們緩存到本地並週期性地刷新服務的狀態

11、Eureka 不足

eureka consumer 本身有緩存，服務狀態更新滯後，最常見的狀態就是，服務下線了，但是服務消費者還是未及時感知，此時調用到已經下線服務導致請求失敗，只能依靠consumer端的容錯機制來保證

文章目錄

0、爲什麼需要註冊中心

從系統架構的演變到對於微服務架構的思考

1、 Eurake 核心概念

1.1 Eurake Server: 註冊中心服務端

1.2、Eureka client 的註冊中心客戶端

2、自我保護機制

3、Eureka 集羣原理

4、Eureka 工作流程

5、dubbo ,zookeeper , eureka之間的關係與區別

6、作爲服務註冊中心，Eureka 比Zookeeper 好在哪裏？

7、consul、eureka、nacos 對比

8、Eureka 應用解決客戶端容錯問題（hystrix）

10、Q&A

11、Eureka 不足

12、參考引用

「Pygors跨平臺GUI」1：Pygors跨平臺GUI應用研究

[轉帖]

python列出centos7內存使用前50的進程信息

「Pygors跨平臺GUI」2：安裝MinGW-w64、MSYS2還是WSL2

一鍵自動化博客發佈工具,用過的人都說好(掘金篇)

通義千問 2.5 “客串” ChatGPT4，你分的清嗎？

Garnet：微軟官方基於.NET開源的高性能分佈式緩存存儲數據庫

Flink執行圖

Java響應式編程

評估統計算法在銀行僞造鈔票檢測中的價值

synchronized重入鎖實例(簡單）

Eureka大雜燴

Bootstrap佈局自動拉伸改變大小

java.util.Formatter(File file)文件寫不進去數據

製作相冊集軟件軟件推薦

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

Eureka大雜燴

文章目錄

0、爲什麼需要註冊中心

從系統架構的演變到對於微服務架構的思考

1、 Eurake 核心概念

1.1 Eurake Server: 註冊中心服務端

1.2、Eureka client 的註冊中心客戶端

2、自我保護機制

3、Eureka 集羣原理

4、Eureka 工作流程

5、dubbo ,zookeeper , eureka之間的關係與區別

6、作爲服務註冊中心，Eureka 比Zookeeper 好在哪裏？

7、consul、eureka、nacos 對比

8、Eureka 應用解決客戶端容錯問題 （hystrix）

10、Q&A

11、Eureka 不足

12、 參考引用

8、Eureka 應用解決客戶端容錯問題（hystrix）

12、參考引用