㈠ Spring Cloud
本文中我們主要介紹微服務開發框架——Spring Cloud。盡管Spring Cloud帶有"Cloud"的字樣，但它並不是雲計算解決方案，而是Spring Boot的基礎上構建的，用於快速構建分布式系統的通用模式的工具集。
Spring Cloud有以下特點:
由上圖可知，Spring Cloud是以 英文單詞+SR+數字 的形式命名版本號的。那麼英文單詞和SR分別表示什麼呢？
因為Spring Cloud是一個綜合項目，它包含很多子項目。由於子項目也維護著自己的版本號，Spring Cloud採用了這種命名方式，從而避免與子項目的版本混淆。其中英文單詞如Edware是倫敦某地鐵站名，它們按照字母順序發行，可以將其理解為主版本的演進。SR表示"Service Release"，一般表示Bug修復。
版本兼容性如下
版本內容
可參考官方文檔： https://spring.io/projects/spring-cloud#overview
我的上一篇博客(微服務理論篇)中談到，對單體應用進行服務拆分得到各個微服務，而這些服務又是相互獨立的，那麼我們如何知道各個微服務的健康狀態、如何知道某個微服務的存在呢？由此、一個擁有服務發現的框架顯得尤為重要。這也就是Eureka誕生的原因。
綜上，Eureka通過心跳檢查、客戶端緩存等機制，確保了系統的高可用性、靈活性和可伸縮性。
通過使用Eureka已經實現了微服務的注冊與發現。啟動各個微服務時，Eureka Client會把自己的網路信息注冊到Eureka Server上。似乎一切更美好了一些。然而，這樣的架構依然有一些問題，如負載均衡。一般來說，各個微服務都會部署多個實例。那麼服務消費者要如何將請求分攤到多個服務提供實例上呢？
如果服務提供者相應非常慢，那麼消費者對提供者的請求就會被強制等待，知道提供者響應或超時。在高負載場景下，如果不作任何處理，此類問題可能會導致服務消費者的資源耗竭甚至整個系統崩潰。
微服務架構的應用系統通常包含多個服務層。微服務之間通過網路進行通信，從而支撐起整個應用系統，因此，微服務之間難免存在依賴關系。而這種由於"基礎服務故障"導致"級聯故障"的現象稱為雪崩效應。
如圖所示，A最為服務提供者（基礎服務），B為A的服務消費者，C和D是B的服務消費者。當A不可用引起了B的不可用，並將不可用像滾雪球一樣放大到C和D時，雪崩效應就形成了。
那麼Hystrix是如何容錯的呢？
以下對該圖做個簡單講解：
Zuul作為微服務架構中的微服務網關。微服務架構經過前幾個組件的組合，已經有了基本的雛形了，那麼我們為什麼還要使用微服務網關呢？我們可以想像，一般情況下我們一個業務並不是只調用一個介面就可以完成一個業務需求。
如果讓客戶端直接與各個微服務通信，會有以下問題：
如圖，微服務網關封裝了應用程序的內部結構，客戶端只須跟網關交互，而無須直接調用特定微服務介面。同時，還有以下優點：
為什麼要同一管理微服務配置？
對於傳統的單體應用，常常使用配置文件管理所有配置。例如一個Spring Boot 項目開發的單體應用，可以將配置內容放到application.yml文件中。如果需要切換環境，可以設置多個Profile,並在啟用應用時指定spring.profile.active={profile}。
而在微服務架構中，微服務的配置管理一般有以下需求：
㈡ nacos和eureka的區別
nacos和eureka的范圍不同，Nacos的閾值是針對某個具體Service的，而不是針對所有服務的；但Eureka的自我保護閾值是針對所有服務的。nacos支持CP和AP兩種；eureka只支持AP。nacos使用netty，是長連接；eureka是短連接，定時發送。
Nacos與Eureka的保護方式不同
Eureka保護方式：當在短時間內，統計續約失敗的比例，如果達到一定閾值，則會觸發自我保護的機制，在該機制下，Eureka Server不會剔除任何的微服務，等到正常後，再退出自我保護機制。自我保護開關(eureka.server.enable-self-preservation: false)
Nacos保護方式：當域名健康實例 (Instance) 占總服務實例(Instance) 的比例小於閾值時，無論實例 (Instance) 是否健康，都會將這個實例 (Instance) 返回給客戶端。這樣做雖然損失了一部分流量，但是保證了集群的剩餘健康實例 (Instance) 能正常工作。
㈢ Eureka工作流程
是Netflix開發的服務發現框架，本身是一個基於REST的服務，主要用於定位運行在AWS域中的中間層服務，以達到負載均衡和中間層服務故障轉移的目的。
注冊中心服務端主要對外提供了三個功能：
服務提供者啟動時，會通過 Eureka Client 向 Eureka Server 注冊信息，Eureka Server 會存儲該服務的信息，Eureka Server 內部有二層緩存機制來維護整個注冊表
服務消費者在調用服務時，如果 Eureka Client 沒有緩存注冊表的話，會從 Eureka Server 獲取最新的注冊表
Eureka Client 通過注冊、心跳機制和 Eureka Server 同步當前客戶端的狀態。
Eureka Client 是一個 Java 客戶端，用於簡化與 Eureka Server 的交互。Eureka Client 會拉取、更新和緩存 Eureka Server 中的信息。因此當所有的 Eureka Server 節點都宕掉，服務消費者依然可以使用緩存中的信息找到服務提供者，但是當服務有更改的時候會出現信息不一致。
服務的提供者，將自身注冊到注冊中心，服務提供者也是一個 Eureka Client。當 Eureka Client 向 Eureka Server 注冊時，它提供自身的元數據，比如 IP 地址、埠，運行狀況指示符 URL，主頁等。
Eureka Client 會每隔 30 秒發送一次心跳來續約。 通過續約來告知 Eureka Server 該 Eureka Client 運行正常，沒有出現問題。 默認情況下，如果 Eureka Server 在 90 秒內沒有收到 Eureka Client 的續約，Server 端會將實例從其注冊表中刪除。
當服務進行正常關閉操作時，它會觸發一個服務下線的REST請求給Eureka Server，告訴服務注冊中心：「我要下線 了」。服務中心接受到請求之後，將該服務置為下線狀態
有時我們的服務可能由於內存溢出或網路故障等原因使得服務不能正常的工作，而服務注冊中心並未收到「服務下線」的請求。相對於服務提供者的「服務續約」操作，服務注冊中心在啟動時會創建一個定時任務，默認每隔一段時間 （默認為60秒）將當前清單中超時（默認為90秒）沒有續約的服務剔除，這個操作被稱為失效剔除。 可以通過 eureka.server.eviction-interval-timer-in-ms 參數對其進行修改，單位是毫秒。
我們關停一個服務，在Eureka面板看到一條警告： 這是觸發了Eureka的自我保護機制。
當一個服務未按時進行心跳續約時，Eureka會統計最近15分鍾心跳失敗的服 務實例的比例是否超過了85%，當EurekaServer節點在短時間內丟失過多客戶端（可能發生了網路分區故障）。在 生產環境下，因為網路延遲等原因，心跳失敗實例的比例很有可能超標，但是此時就把服務剔除列表並不妥當，因 為服務可能沒有宕機。Eureka就會把當前實例的注冊信息保護起來，不予剔除。生產環境下這很有效，保證了大多 數服務依然可用。
Eureka 自我保護機制是為了防止誤殺服務而提供的一個機制。當個別客戶端出現心跳失聯時，則認為是客戶端的問題，剔除掉客戶端；當 Eureka 捕獲到大量的心跳失敗時，則認為可能是網路問題，進入自我保護機制；當客戶端心跳恢復時，Eureka 會自動退出自我保護機制。
如果在保護期內剛好這個服務提供者非正常下線了，此時服務消費者就會拿到一個無效的服務實例，即會調用失敗。對於這個問題需要服務消費者端要有一些容錯機制，如重試，斷路器等。
了解完 Eureka 核心概念，自我保護機制，以及集群內的工作原理後，我們來整體梳理一下 Eureka 的工作流程：
1、Eureka Server 啟動成功，等待服務端注冊。在啟動過程中如果配置了集群，集群之間定時通過 Replicate 同步注冊表，每個 Eureka Server 都存在獨立完整的服務注冊表信息
2、Eureka Client 啟動時根據配置的 Eureka Server 地址去注冊中心注冊服務
3、Eureka Client 會每 30s 向 Eureka Server 發送一次心跳請求，證明客戶端服務正常
4、當 Eureka Server 90s 內沒有收到 Eureka Client 的心跳，注冊中心則認為該節點失效，會注銷該實例
5、單位時間內 Eureka Server 統計到有大量的 Eureka Client 沒有上送心跳，則認為可能為網路異常，進入自我保護機制，不再剔除沒有上送心跳的客戶端
6、當 Eureka Client 心跳請求恢復正常之後，Eureka Server 自動退出自我保護模式
7、Eureka Client 定時全量或者增量從注冊中心獲取服務注冊表，並且將獲取到的信息緩存到本地
8、服務調用時，Eureka Client 會先從本地緩存找尋調取的服務。如果獲取不到，先從注冊中心刷新注冊表，再同步到本地緩存
9、Eureka Client 獲取到目標伺服器信息，發起服務調用
10、Eureka Client 程序關閉時向 Eureka Server 發送取消請求，Eureka Server 將實例從注冊表中刪除
參考鏈接： https://blog.csdn.net/qwe86314/article/details/94552801
㈣ 如何啟動eureka服務
使用Eureka做服務發現
Zookeeper做注冊中心的缺陷
Peter Kelley(個性化教育初創公司Knewton的一名軟體工程師)發表了一篇文章說明為什麼ZooKeeper用於服務發現是一個錯誤的做法，他主要提出了三個缺點[1]：
ZooKeeper無法很好的處理網路分區問題，當網路分區中的客戶端節點無法到達Quorum時，會與ZooKeeper失去聯系，從而也就無法使用其服務發現機制。
服務發現系統應該是一個AP系統，設計上針對可用性；而ZooKeeper是一個CP系統。
ZooKeeper的設置和維護非常困難，實際操作的時候也容易出錯，比如在客戶端重建Watcher，處理Session和異常的時候。
當然，Peter Kelley提出的這幾個問題並不是不能克服的，並不能說明基於ZooKeeper就不能做好一個服務發現系統，但是我們可能有更簡潔的方案來實現。
Eureka介紹
什麼是Eureka
官方的介紹在這里Eureka wiki。Eureka是Netflix開源的一個RESTful服務，主要用於服務的注冊發現。Eureka由兩個組件組成：Eureka伺服器和Eureka客戶端。Eureka伺服器用作服務注冊伺服器。Eureka客戶端是一個java客戶端，用來簡化與伺服器的交互、作為輪詢負載均衡器，並提供服務的故障切換支持。Netflix在其生產環境中使用的是另外的客戶端，它提供基於流量、資源利用率以及出錯狀態的加權負載均衡。
在我看來，Eureka的吸引力來源於以下幾點：
開源：大家可以對實現一探究竟，甚至修改源碼。
可靠：經過Netflix多年的生產環境考驗，使用應該比較靠譜省心
功能齊全：不但提供了完整的注冊發現服務，還有Ribbon等可以配合使用的服務。
基於Java：對於Java程序員來說，使用起來，心裡比較有底。
spring cloud可以使用Spring Cloud, 與Eureka進行了很好的集成，使用起來非常方便。
Eureka架構
Netflix主要是在AWS中使用Eureka的，雖然同時也支持本地環境，但是了解AWS的一些基礎概念對於理解Eureka的設計非常有幫助。
㈤ nacos和eureka的區別是什麼
nacos和eureka的區別區別如下：
springcloud eureka是注冊中心，負責微服務的注冊與發現，起到承上啟下的作用，在微服務架構中相當於人體的 大腦，很重要，nacos是阿里巴巴出的，功能類似eureka。
nacos的部署方式與springcloud eureka不太一樣，euraka是需要創建springboot項目，然後將euraka服務端通過gav的方式載入進來，然後部署項目。nacos是直接從阿里巴巴nacos的官網下載jar包，啟動服務。
Eureka Server：
之間通過復制的方式完成數據的同步，Eureka還提供了客戶端緩存機制，即使所有的Eureka Server都掛掉，客戶端依然可以利用緩存中的信息消費其他服務的API。綜上，Eureka通過心跳檢查、客戶端緩存等機制，確保了系統的高可用性、靈活性和可伸縮性。
㈥ 位元組三面：到底知不知道什麼是Eureka
什麼是服務注冊？
首先我們來了解下，服務注冊、服務發現和服務注冊中心的之間的關系。
舉個形象的例子，三者之間的關系就好像是供貨商，顧客和商店。
首先各地的供貨商會將各種商品提供給商店，然後顧客需要商品的時候會去商店購買。
注冊中心就好比是這個商店，供貨商的動作就是服務注冊，商品就是注冊的服務。
當部署的服務啟動後，會注冊到注冊中心，消費者需要什麼樣的服務，就自己去注冊中心拉取。
那麼到底什麼是服務注冊，為什麼要將服務注冊到注冊中心呢？
服務注冊指的是服務在啟動時將服務的信息注冊到注冊中心中，由注冊中心統一對所有的注冊的服務進行管理。
現在我們想想，假如你是消費者，你需要買一個商品，你可以去商店，也可以直接去供貨商。
但是如果今天你要買很多商品，而且我們並不知道每個商品對應的供應商的地址，那麼你就得挨家挨戶的去跑供貨商購買商品。
是不是就很麻煩了，倘若此時有一家商店，匯總了多家供貨商的商品，那你是不是只需要去這一家商店就能購買到你需要的所有的商品了呢？
這樣是不是就方便了。
在我們現實開發中，比如我們需要獲取用戶信息的時候，而此時，我們的用戶服務只部署了一個節點，那我們就可以使用IP+埠的形式訪問服務。
當此時我們的服務部署了10個節點後，我們可以通過域名訪問，通過nginx轉發到某一個節點上，訪問該節點的服務。
使用過nginx的小夥伴們都知道，每當我們需要新增一個節點的時候，我們就需要去修改nginx的配置文件，一旦服務部署的節點過多，頻繁修改配置文件就變成了一件極其麻煩的事情。
這個時候，我們的注冊中心，就應該粉墨登場了。
注冊中心一登場，我們就盡管部署服務節點，部署完成後，服務啟動，服務的信息就會被注冊到注冊中心，我們就不需要擔心是不是又要去修改配置文件了。
什麼是服務發現？
服務發現有兩種模式：一種是客戶端發現模式，一種是服務端發現模式。Eureka採用的是客戶端發現模式。
客戶端發現模式就好比我是一個土豪顧客，我去了商店，我把所有的商品都買回家，需要的時候在這些商品裡面尋找。
因為我是土豪，所以我當然不能忍受商店裡有新品上架，而我卻沒有，所以我每隔一段時間就會商店增量獲取最新的商品。
這就是Eureka中的Fetch Registry，抓取注冊信息。
Eureka Client 從 Eureka Server 獲取注冊表信息並在本地緩存。
這里我們注意一下，Eureka Client並不是直接去服務注冊表中獲取數據，而是從ReadOnly緩存中獲取數據。
並且會通過在上一個獲取周期和當前獲取周期之間獲取增量更新，這些信息會定期更新(每30秒更新一次)。
獲取的時候可能返回相同的實例。Eureka Client會自動處理重復信息。
因為我的土豪行為，我已經被商店老闆記錄在它的VVIP名單上了。可惜天有不測風雲，我破產了，我再也不能這么土豪了，沒辦法，我告訴了老闆我破產了，老闆聽了我的話，想都沒想，直接從他的VVIP名單上將我的名字給剔除了，社會就是這么現實。
這就是Eureka中的Cancel，取消。
每一個微服務節點關閉時，Eureka Client會向Eureka Server發送一個取消請求。
Eureka Server收到你的取消請求後，就會將你從服務注冊表中給剔除。
商店老闆是個傲嬌的人，她制定了一個規則，如果你是她VVIP名單上的人，你必須每隔一段時間就要去商店采購商品。
一旦你在一段時間內沒有來采購，她就覺得你已經沒有購買能力，不適合在她的VVIP名單上存在了。
她就會狠心的將你從她的VVIP名單上將我的名字給剔除了。
這就是Eureka中的Renew（更新 / 續借）
Eureka Client 內部具備一個內置的負載均衡器，它使用輪訓（round-robin）負載演算法。
在服務啟動後，每隔一定周期（默認30秒）向Eureka Server發送心跳。
如果Eureka Server在多個心跳周期內（默認90秒）沒有收到Eureka Client發送過來的心跳，Eureka Server將會在服務注冊表中將該節點剔除。
當然了，服務發現去注冊中心拉取的是服務的信息，然後需要從服務信息中獲取到服務部署的節點信息，然後通過域名地址訪問到該節點的服務。
就好像一家商店，因為空間太小，只是存放了一些商品的微縮模型，模型上寫著該商品所屬的供貨商地址，我們去商店拿到該模型後，看到供貨商的地址，然後我們就可以直接去供貨商那兒直接購買商品了。
什麼是注冊中心，注冊中心的作用？
注冊中心就是一個管理器，各個服務提供者將服務注冊到注冊中心，由注冊中心進行統一的存儲和管理。
注冊中心同時還有著判斷服務是否可用，對於不可用的服務進行剔除的功能。
至於如何判斷服務的可用性和如何剔除不可用的服務，後續會有詳細的講解。
什麼是 Eureka，有什麼作用？
Eureka採用CS架構，它分為兩大組件。
一個是Eureka Server,注冊中心服務端。
當各個微服務節點啟動後，Eureka Server 會存儲服務提供者注冊上來的服務信息，並且提供二層緩存機制來維護整個注冊中心。
另一個是Eureka Client，注冊中心客戶端。
Eureka Client是一個java客戶端，它用來簡化和Eureka Server交互。
Eureka Client 會拉取、更新和緩存 Eureka Server 中的信息。
因此當所有的 Eureka Server 節點都宕掉，服務消費者依然可以使用緩存中的信息找到服務提供者，但是當服務有更改的時候會出現信息不一致。
Eureka 架構詳解
如下圖所示，這是官網提供給我們的Eureka的架構圖Eureka 的架構，主要分為 Eureka Server 和 Eureka Client 兩部分，Eureka Client 又分為 Applicaton Service 和 Application Client，Applicaton Service 就是服務提供者，Application Client 就是服務消費者。
我們首先會在應用程序中依賴 Eureka Client，項目啟動後 Eureka Client 會向 Eureka Server 發送請求，進行注冊，並將自己的一些信息發送給 Eureka Server。
注冊成功後，每隔一定的時間，Eureka Client 會向 Eureka Server 發送心跳來續約服務，也就是匯報健康狀態。如果客戶端長時間沒有續約，那麼 Eureka Server 大約將在 90 秒內從伺服器注冊表中刪除客戶端的信息。
Eureka Client 還會定期從 Eureka Server 拉取注冊表信息，然後根據負載均衡演算法得到一個目標，並發起遠程調用，關於負載均衡在後面的課時會詳細介紹，也就是 Ribbon 組件。
應用停止時也會通知 Eureka Server 移除相關信息，信息成功移除後，對應的客戶端會更新服務的信息，這樣就不會調用已經下線的服務了，當然這個會有延遲，有可能會調用到已經失效的服務，所以在客戶端會開啟失敗重試功能來避免這個問題。
Eureka Server 會有多個節點組成一個集群，保證高可用。Eureka Server 沒有集成其他第三方存儲，而是存儲在內存中。
所以 Eureka Server 之間會將注冊信息復制到集群中的 Eureka Server 的所有節點。
這樣數據才是共享狀態，任何的 Eureka Client 都可以在任何一個 Eureka Server 節點查找注冊表信息。
Eureka 的工作流程
Eureka 的自我保護機制
什麼是自我保護機制
官方定義：自我保護模式正是一種針對網路異常波動時的安全保護措施，使用自我保護模式能使Eureka集群更加健壯穩定的運行。
為什麼要開啟自我保護機制？
如果Eureka Server在一定時間內（默認90s）（可優化）沒有收到某一個服務節點的心跳，Eureka Server將會移除該服務實例。
但是在某些時候，遇到網路分區故障，服務節點實際上是正常存活狀態，但是卻無法和Eureka Server正常通信，此時如果沒有引入自我保護機制，Eureka Server就會將該服務節點剔除。
自我保護模式的工作機制
如果15分鍾內超過85%的客戶端節點都沒有正常的心跳，那麼Eureka Server就會認為客戶端與注冊中心發生了網路故障，Eureka Server進入自我保護機制。
自我保護機制的缺點
如果在自我保護機制中，剛好某些服務節點非正常下線，但是Eureka Server並不會剔除該服務節點，服務消費者就會獲取到一個無效的服務實例。
解決方案
① ：關閉自我保護機制(不推薦)
② ：切換請求或斷路器，使用負載均衡的方式，設置當一個請求超過多少秒還未得到響應，速度切換請求到下一個注冊服務，例如使用Ribbon+Hystrix配置負載均衡和斷路器。
Eureka Server 進入自我保護機制後
1、Eureka Server不再從注冊表中剔除因為長時間沒有和注冊中心續約的服務節點
2、Eureka Server仍然能夠接受新服務的注冊和查詢請求，但是不會同步到其他Eureka Server節點上
3、網路正常後，當前Eureka Server節點會將新的服務節點信息同步到其他Eureka Server節點上
如何開啟自我保護
通過
eureka.server.enable-self-preservation=true/false來開啟或關閉自我保護機制。
其他關鍵配置：
清理失效服務節點的時間間隔：
eureka.server.evication-interval-timer-in-ms默認60s
續約間隔時間：
eureka.instance.lease-renewal-interval-in-seconds默認30s
續約到期時間：
eureka.instance.lease-expiration-ration-in-seconds默認90s
通過源碼窺探Eureka是如何開啟自我保護機制的
第一步，我們引入Eureka Server 依賴。
第二步，我們找到eureka-core jar包下的路徑為com.netflix.eureka下的registry包
第三步，進入AbstractInstanceRegistry 類，找到evict方法，這個是定期剔除任務的線程最終執行的方法
第四步，我們找到isLeaseExpirationEnabled()方法的實現
第五步，我們注意到
numberOfRenewsPerMinThreshold這個變數很關鍵，它的含義是每分鍾最小的續約次數
在服務注冊register和服務下線cancel兩個方法中會更新這個變數，更新該變數方法如下：
以上就是Eureka開啟自我保護的整個邏輯流程。
解除自我保護機制
1.當服務的網路分區故障解除之後，客戶端能夠和服務進行交互時，在續約的時候，更新每分鍾的續約數，當每分鍾的續約數大於85%時，則自動解除。
2.重啟服務
Eureka 的健康檢查
其實很多框架的健康狀態監控都是通過 actuator 來管理健康狀態的，並且擴展了 health 端點。
所以說我們只要在項目中集成Actuator，我們就能管理監控項目的健康狀態。
Eureka也是一樣，我們可以將某些不健康的服務節點的狀態告知Eureka Server，然後Eureka Server 會主動讓其下線。
這個就是Eureka的健康檢查。
如何實現Eureka-Actuator健康檢查？
首先我們要在pom中依賴
spring-boot-starter-actuator。
第二步，配置文件中添加
eureka.client.healthcheck.enabled=true 配置
原理分析：
首先在 中根據 eureka.client.healthcheck.enabled 的值來決定是否要裝配 EurekaHealthCheckHandler ，然後在 EurekaClientAutoConfiguration 中會注冊 HealthCheck ，但我們注冊完成後會有調用任務來進行狀態的更新，在 com.netflix.discovery.InstanceInfoReplicator.run() 中會進行狀態更新。
Eureka 的多級緩存機制
什麼是多級緩存機制
Eureka Server 為了避免同時讀取內存數據造成的並發沖突問題，採用了多級緩存機制提升服務請求的響應速度。
Eureka Server的緩存是通過一個只讀，一個讀寫緩存來實現的。
一級緩存：concurrentHashMap<key,value>readOnlyCacheMap本質是HashMap，無過期時間，保存數據信息對外輸出。
readOnlyCacheMap依賴於定時器的更新，通過與readWriteCacheMap的值做對比，以readWriteCacheMap為准。
responseCacheUpdateIntervalMs：readOnlyCacheMap緩存更新間隔，默認30s
二級緩存：LoaDing<key,value>readWriteCacheMap本質是Guava緩存，包含失效機制，保護數據信息對外輸出。
：readWriteCacheMap 緩存過期時間，默認180s。
當服務節點發生注冊，下線，過期，狀態變更等變化時
1.在內存中更新注冊表信息
2.同時過期掉readWriteCacheMap緩存，緩存清除只是會去清除readWriteCacheMap這個緩存， readOnlyCacheMap 只讀 緩存並沒有更新，也就說當客戶端的信息發生變化之後， 只讀緩存不是第一時間感知到的。只讀緩存的更新只能依賴那個30秒的定時任務來更新。
3.一段時間後（默認30s），後台線程發現readWriteCacheMap緩存為空，於是也將readOnlyCacheMap中的緩存清空
4.當有服務消費者拉取注冊表信息時，會調用ClassLoader的load方法，將內存中的注冊表信息載入到各級緩存中，並返回注冊表信息。
在Eureka Server 中會有兩個線程，一個是定時同步兩個緩存的數據，默認30s，一個是定時檢測心跳故障，默認90s。
服務拉取
1.服務消費者，默認每30s，拉取注冊表信息
2.從readOnlyCacheMap中獲取信息，如果獲取為空
3.從readWriteCacheMap中獲取，如果還是為空
4.調用ClassLoader的load方法，將內存中的注冊表信息載入到各級緩存中，並返回注冊表信息。
Eureka的區域配置
當用戶地理分布范圍很廣的時候，比如公司在上海、杭州、青島等都有分公司的時候，一般都會有多個機房。
那麼對於用戶而言，當然是希望調用本地分公司的機房中的微服務應用。
比如：上海用戶A，調用OAuth2服務，用戶A當然希望調用上海機房裡面的微服務應用。如果上海用戶A調用杭州機房的OAuth2服務，就增加的延時時間。
所以我們希望一個機房內的服務優先調用同一個機房內的服務，當同一個機房的服務不可用的時候，再去調用其它機房的服務，以達到減少延時的作用。
為此，eureka提供了region和zone兩個概念來進行分區，Eureka基於Amazon設計的，所以對於地域的區分也與Amazon一致，Amazon分為多個region，每個region包含多個zone，所以Eureka設計時也是可以設置region與zone，請求時可以優先選擇與請求服務在同一個zone的服務。
基本配置
此時無論我們調用多少次，調用的都是shanghai下面的zone1下面的服務。
一般來說我們都會結合Ribbon來實現微服務的負載均衡，而Ribbon內部會有一些專門的負載策略演算法，雖然剛剛我們說過會優先請求的是指定region下指定 Zone 區域的服務實例。
但有些時候比如當在Region=shanghai下沒有可用的zone，系統會默認載入 DEFAULT_ZONE，或者說或者同區域的服務負載過高...等等，也會自動切換成其他區域的服務。
Eureka的重試機制
由於 Spring Cloud Eureka 實現的服務治理機制強調了 CAP 原理中的 AP，即可用性與可靠性，犧牲了一定的一致性（在極端情況下它寧願接受故障實例也不要丟掉"健康"實例，如同如我們上面所說的自我保護機制）。
但不論是由於觸發了保護機制還是服務剔除的延遲，引起服務調用到這些不正常的服務，調用就會失敗，從而導致其它服務不能正常工作！
這顯然不是我們願意看到的，我們還是希望能夠增強對這類問題的容錯。所以，我們在實現服務調用的時候通常會加入一些重試機制。
從 Camden SR2 版本開始，Spring Cloud 就整合了 Spring Retry 來增強 RestTemplate 的重試能力，對於開發者來說只需通過簡單的配置，原來那些通過 RestTemplate 實現的服務訪問就會自動根據配置來實現重試策略。
開啟Eureka的重試機制很簡單，首先我們在pom中引入Spring Retry的依賴：
然後在配置文件中配置
spring.cloud.loadbalancer.retry.enabled參數來控制重試機制的開關，因為 Spring Retry默認是開啟的，所以說我們只要引入依賴即可，如果說我們想要關閉的話只需要將 spring.cloud.loadbalancer.retry.enabled設置為false即可。
其實在SpringCloud的架構組件中無論是Fegin，Ribbon，還是Zuul都提供了重試機制，這些暫且不論，後續再講到具體的組件時再進行具體的分析。
實戰 Eureka 注冊中心的部署
Eureka Server 項目搭建
1、創建一個 springcloud-eureka-server 的項目，然後在 pom 中增加
spring-cloud-starter-netflix-eureka-server 的依賴。
2.在pom.xml文件中新增
spring-cloud-starter-netflix-eureka-server依賴
3.在啟動類
上使用 @EnableEurekaServer 開啟 EurekaServer 的自動裝配功能。
4.添加配置文件application.properties
5.啟動項目，然後訪問 http://localhost:8761/ ,可以看到 Eureka 的管理頁面，表示 Eureka 啟動成功了。
1、創建一個 springcloud-eureka-client 的項目，然後在 pom 中增加
spring-cloud-starter-netflix-eureka-client 的依賴。
2.在啟動類
上使用 @EnableEurekaClient 開啟 EurekaServer 的自動裝配功能。
配置
eureka.client.serviceUrl.defaultZone 的地址，也就是剛剛啟動的 Eureka Server 的地址， http://localhost:8761/eureka/ 。
啟動客戶端，然後刷新剛剛打開的Eureka主頁，我們發現服務已經注冊成功。
Eureka 注冊中心添加密碼認證
上面我們看到我們搭建好Eureka Server 後訪問 http://localhost:8761/ ,沒有登陸就可以直接看到 Eureka 的管理頁面。
如果在實際使用中，注冊中心地址有公網 IP 的話，必然能直接訪問到，這樣是不安全的。所以我們需要對 Eureka 進行改造，通過集成 Spring-Security 來進行安全認證，加上許可權認證來保證安全性。
首先，在 pom.xml 中引入 Spring-Security 的依賴
然後在 application.properties 中加上認證的配置信息
最後增加Spring Security 配置類
這樣我們啟動Eureka Server成功後在訪問 http://localhost:8761/ ，此時瀏覽器會提示你輸入用戶名和密碼，輸入正確後才能繼續訪問 Eureka 提供的管理頁面。
總結
本章我們主要學習了Eureka相關知識，雖然Eureka已經停更了，但是很多公司還在使用它，而它也足夠穩定，它所提供的功能也足夠大多數公司使用。所以說現在面試中，Eureka相關題目還是經常出現的。反正學到了就是自己的。
祝願大家早日成為大牛，有一頭烏黑秀發的大牛。
㈦ Spring Cloud Eureka服務注冊中心
服務治理：Spring Cloud Eureka
Spring Cloud Eureka是Spring Cloud Netflix微服務套件中的一部分，它基於Netflix
Eureka做了二次封裝，主要負責完成微服務架構中的服務治理功能。Spring Cloud通過為
Eureka增加了Spring Boot風格的自動化配置，我們只需通過簡單引入依賴和註解配置就能
讓Spring Boot構建的微服務應用輕松地與Eureka服務治理體系進行整合。
在本章中，我們將指引讀者學習下面這些核心內容，並構建起用於服務治理的基礎設
施。
·構建服務注冊中心
·服務注冊與服務發現
。Eureka的基礎架構
Eureka的服務治理機制
Eureka的配置
服務治理
服務治理可以說是微服務架構中最為核心和基礎的模塊，它主要用來實現各個微服務
實例的自動化注冊與發現。為什麼我們在微服務架構中那麼需要服務治理模塊呢？微服務
系統沒有它會有什麼不好的地方嗎？
在最初開始構建微服務系統的時候可能服務並不多，我們可以通過做一些靜態配置來
完成服務的調用。比如，有兩個服務A和B,其中服務A需要調用服務B來完成一個業務
操作時，為了實現服務的高可用，不論採用服務端負載均衡還是客戶端負載均衡，都需
要手工維護服務的具體實例清單。但是隨著業務的發展，系統功能越來越復雜，相應一下的
微服務應用也不斷增加，我們的靜態配置就會變得越來越難以維護。並且面對不斷發展的
業務，我們的集群規模、服務的位置、服務的命名等都有可能發生變化，如果還是通過手
工維護的方式，那麼極易發生錯誤或是命名沖突等間題。同時，對於這類靜態內容的維護
為了解決微服務架構中的服務實例維護問題，產生了大量的服務治理框架和產品。這
也必將消耗大量的人力。
些框架和產品的實現都圍繞著服務注冊與服務發現機制來完成對微服務應用實例的自動化
管理。
服務注冊：在服務治理框架中，通常都會構建一個注冊中心，每個服務單元向注冊
中心登記自己提供的服務，將主機與埠號、版本號、通信協議等一些附加信息告
知注冊中心，注冊中心按服務名分類組織服務清單。比如，我們有兩個提供服務A
的進程分別運行於192.168.0.100：8000和192.168.0.101：8000位置上，
另外還有三個提供服務B的進程分別運行於192.168.0.100：9000、
192.168.0.101:9000、192.168.0.102:9000位置上。當這些進程均啟動，
並向注冊中心注冊自己的服務之後，注冊中心就會維護類似下面的一個服務清單。
另外，服務注冊中心還需要以心跳的方式去監測清單中的服務是否可用，若不可用
需要從服務清單中剔除，達到排除故障服務的效果。
服務名
位置
服務A
192.168.0.100:8000、192.168.0.101:8000
服務B
192.168.0.100:9000、192.168.0.101:9000、192.168.0.102:9000
服務發現：由於在服務治理框架下運作，服務間的調用不再通過指定具體的實例地
址來實現，而是通過向服務名發起請求調用實現。所以，服務調用方在調用服務提
供方介面的時候，並不知道具體的服務實例位置。因此，調用方需要向服務注冊中
心咨詢服務，並獲取所有服務的實例清單，以實現對具體服務實例的訪問。比如，
現有服務C希望調用服務A,服務C就需要向注冊中心發起咨詢服務請求，服務注
冊中心就會將服務A的位置清單返回給服務C,如按上例服務A的情況，C便獲得
了服務A的兩個可用位置192.168.0.100：8000和192.168.0.101：8000。
當服務要發起調用的時候，便從該清單中以某種輪詢策略取出一個位置來進行服
務調用，這就是後續我們將會介紹的客戶端負載均衡。這里我們只是列舉了一種簡
單的服務治理邏輯，以方便理解服務治理框架的基本運行思路。實際的框架為了性
能等因素，不會採用每次都向服務注冊中心獲取服務的方式，並且不同的應用哦場景
在緩存和服務剔除等機制上也會有一些不同的實現策略。
㈧ Eureka工作原理
Eureka 作為 Spring Cloud 體系中最核心、默認的注冊中心組件，研究它的運行機制，有助於我們在工作中更好地使用它。
回到上節的服務注冊調用示意圖，服務提供者和服務的消費者，本質上也是 Eureka Client 角色。整體上可以分為兩個主體：Eureka Server 和 Eureka Client。
Eureka Server：注冊中心服務端
注冊中心服務端主要對外提供了三個功能：
服務注冊 服務提供者啟動時，會通過 Eureka Client 向 Eureka Server 注冊信息，Eureka Server 會存儲該服務的信息，Eureka Server 內部有二層緩存機制來維護整個注冊表
提供注冊表 服務消費者在調用服務時，如果 Eureka Client 沒有緩存注冊表的話，會從 Eureka Server 獲取最新的注冊表
同步狀態 Eureka Client 通過注冊、心跳機制和 Eureka Server 同步當前客戶端的狀態。
Eureka Client：注冊中心客戶端 Eureka Client 是一個 Java 客戶端，用於簡化與 Eureka Server 的交互。Eureka Client 會拉取、更新和緩存 Eureka Server 中的信息。因此當所有的 Eureka Server 節點都宕掉，服務消費者依然可以使用緩存中的信息找到服務提供者，但是當服務有更改的時候會出現信息不一致。
Register: 服務注冊 服務的提供者，將自身注冊到注冊中心，服務提供者也是一個 Eureka Client。當 Eureka Client 向 Eureka Server 注冊時，它提供自身的元數據，比如 IP 地址、埠，運行狀況指示符 URL，主頁等。
Renew: 服務續約 Eureka Client 會每隔 30 秒發送一次心跳來續約。 通過續約來告知 Eureka Server 該 Eureka Client 運行正常，沒有出現問題。 默認情況下，如果 Eureka Server 在 90 秒內沒有收到 Eureka Client 的續約，Server 端會將實例從其注冊表中刪除，此時間可配置，一般情況不建議更改。
服務續約的兩個重要屬性
Eviction 服務剔除 當 Eureka Client 和 Eureka Server 不再有心跳時，Eureka Server 會將該服務實例從服務注冊列表中刪除，即服務剔除。
Cancel: 服務下線 Eureka Client 在程序關閉時向 Eureka Server 發送取消請求。 發送請求後，該客戶端實例信息將從 Eureka Server 的實例注冊表中刪除。該下線請求不會自動完成，它需要調用以下內容：
GetRegisty: 獲取注冊列表信息 Eureka Client 從伺服器獲取注冊表信息，並將其緩存在本地。客戶端會使用該信息查找其他服務，從而進行遠程調用。該注冊列表信息定期（每30秒鍾）更新一次。每次返回注冊列表信息可能與 Eureka Client 的緩存信息不同，Eureka Client 自動處理。
如果由於某種原因導致注冊列表信息不能及時匹配，Eureka Client 則會重新獲取整個注冊表信息。 Eureka Server 緩存注冊列表信息，整個注冊表以及每個應用程序的信息進行了壓縮，壓縮內容和沒有壓縮的內容完全相同。Eureka Client 和 Eureka Server 可以使用 JSON/XML 格式進行通訊。在默認情況下 Eureka Client 使用壓縮 JSON 格式來獲取注冊列表的信息。
獲取服務是服務消費者的基礎，所以必有兩個重要參數需要注意：
Remote Call: 遠程調用 當 Eureka Client 從注冊中心獲取到服務提供者信息後，就可以通過 Http 請求調用對應的服務；服務提供者有多個時，Eureka Client 客戶端會通過 Ribbon 自動進行負載均衡。
默認情況下，如果 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 集群的工作原理。我們假設有三台 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 中獲取信息。
Eurka 保證 AP
Eureka Server 各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供注冊和查詢服務。而 Eureka Client 在向某個 Eureka 注冊時，如果發現連接失敗，則會自動切換至其它節點。只要有一台 Eureka Server 還在，就能保證注冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。
了解完 Eureka 核心概念，自我保護機制，以及集群內的工作原理後，我們來整體梳理一下 Eureka 的工作流程：
1、Eureka Server 啟動成功，等待服務端注冊。在啟動過程中如果配置了集群，集群之間定時通過 Replicate 同步注冊表，每個 Eureka Server 都存在獨立完整的服務注冊表信息
2、Eureka Client 啟動時根據配置的 Eureka Server 地址去注冊中心注冊服務
3、Eureka Client 會每 30s 向 Eureka Server 發送一次心跳請求，證明客戶端服務正常
4、當 Eureka Server 90s 內沒有收到 Eureka Client 的心跳，注冊中心則認為該節點失效，會注銷該實例
5、單位時間內 Eureka Server 統計到有大量的 Eureka Client 沒有上送心跳，則認為可能為網路異常，進入自我保護機制，不再剔除沒有上送心跳的客戶端
6、當 Eureka Client 心跳請求恢復正常之後，Eureka Server 自動退出自我保護模式
7、Eureka Client 定時全量或者增量從注冊中心獲取服務注冊表，並且將獲取到的信息緩存到本地
8、服務調用時，Eureka Client 會先從本地緩存找尋調取的服務。如果獲取不到，先從注冊中心刷新注冊表，再同步到本地緩存
9、Eureka Client 獲取到目標伺服器信息，發起服務調用
10、Eureka Client 程序關閉時向 Eureka Server 發送取消請求，Eureka Server 將實例從注冊表中刪除
這就是Eurka基本工作流程
講了 Eureka 核心概念、Eureka 自我保護機制和 Eureka 集群原理。通過分析 Eureka 工作原理，我可以明顯地感覺到 Eureka 的設計之巧妙，通過一些列的機制，完美地解決了注冊中心的穩定性和高可用性。
Eureka 為了保障注冊中心的高可用性，容忍了數據的非強一致性，服務節點間的數據可能不一致， Client-Server 間的數據可能不一致。比較適合跨越多機房、對注冊中心服務可用性要求較高的使用場景。