SpringCloud Eureka 學習筆記
準備與說明
- 源碼地址：
https://github.com/hlmk/microservicecloud.git - springcloud版本：
Dalston.SR1 - springboot版本：
1.5.9.RELEASE - jdk：
1.8 - 開發工具：
Eclipse Java EE IDE for Web Developers - 本篇博客來自尚硅谷SpringCloud視頻學習整理的筆記
eureka是什麼
Eureka是Netflix的一個子模塊，也是核心模塊之一，Eureka是一個基於REST的服務，用於定位服務，以實現雲端中間層服務發現和故障轉移。服務註冊與發現對於微服務架構來說是非常重要的，有了服務發現與註冊，只需要使用服務的標識符，就可以訪問到服務，而不需要修改服務調用的配置文件了。功能類似於dubbo的註冊中心，比如Zookeeper。
eureka採用了CS的設計架構。Eureka Server作爲服務註冊功能的服務器，它是服務註冊中心。
而系統中的其他微服務，使用eureka client連接到eureka server並維持心跳連接。這樣系統的維護人員就可以通過eureka server來監控系統中各個微服務是否正常運行。spring cloud的一些其他模塊（比如Zuul）就可以通過eureka server來發現系統中的其他微服務，並執行相關的邏輯。
Eureka包含兩個組件：Eureka Server和Eureka Client
Eureka Server提供服務註冊服務
各個節點啓動後 ，會在Eureka Server中進行註冊，這樣Eureka Server中的服務註冊表中將會存儲所有可用服務節點的信息，服務節點的信息可以在界面中直觀的看到
Eureka Client是一個Java客戶端，用於簡化Eureka Server的交互，客戶端同時也具備一個內置的、使用輪詢（round-robin）負載算法的負載均衡器，在啓動應用後，將會向EurekaServer發送心跳（默認週期爲30秒）。如果EurekaServer在多個心跳週期內沒有接收到某個節點的心跳，EurekaServer將會從服務註冊表中把這個服務節點移除（默認90秒）
三大角色
- Eureka Server 提供服務註冊和發現
- Service Provider 服務提供方將自身服務註冊到Eureka，從而使服務消費方能夠找到。
- Service Consumer 服務消費方從Eureka獲取註冊服務列表，從而能夠消費服務。
Eureka的自我保護模式
什麼事自我保護模式
默認情況下，如果EurekaServer在一定時間內沒有接收到某個微服務實例的心跳，EurekaServer將會註銷該實例（默認90秒）。但是當網絡分區發生故障時，微服務與EurekaServer之間無法正常通信，以上行爲可能變得非常危險了----因爲微服務本身其實是健康的，此時本不應該註銷這個微服務。Eureka通過“自我保護模式”來解決這個問題----當EurekaServer節點在短時間內丟失過多客戶端時（可能發生了網絡分區故障），那麼這個節點就會進入自我保護模式。一旦進入該模式，EurekaServer就會保護服務註冊表中的信息，不再刪除服務註冊表中的數據（也就是不會註銷任何微服務）。當網絡故障恢復後，該Eureka節點會自動退出自我保護模式。
在自我保護模式中，EurekaServer會保護服務註冊表中的信息，不再註銷任何服務實例。當它收到的心跳數重新恢復到閾值以上時，該EurekaServer節點就會自動退出自我保護模式。它的設計哲學是另可保留錯誤的服務註冊信息，也不盲目註銷任何可能健康的實例。
綜上，自我保護模式是一種應對網絡異常的安全保護措施。它的架構哲學是另可同事保留所有微服務（健康的微服務和不健康的微服務都會保留），也不盲目註銷任何健康的微服務。使用自我保護模式，可以讓Eureka集羣更加的健壯、穩定。
在Spring Cloud中，可以使用eureka.server.enable-self-preservation=false來禁用自我保護模式。
練習項目模塊簡介
總父工程
通用模塊API
服務提供者Provider
服務消費者Consumer
其他模塊
github地址：https://github.com/Netflix/eureka/wiki
設計原則：Netflix在設計Eureka時遵守的是AP原則
關係型數據庫的ACID
- A（Atomicity）原子性
- C（Consistency）一致性
- I（Isolation）獨立性
- D（Durability）持久性
非關係型數據庫的CAP - C（Consistency）強一致性
- A（Availability）可用性
- P（Partition tolerance）分區容錯性
最多隻能同時較好的滿足兩個
CAP理論的核心是：一個分佈式系統不可能同時很好的滿足一致性、可用性和分區容錯性這三個需求，因此，根據CAP原理將NoSQL數據庫分成了滿足CA原則、滿足CP原則和滿足AP原則三大類：
CA - 單點集羣，滿足一致性，可用性的系統，通常在可擴展性上不太強大。
CP - 滿足一致性，分區容忍性的系統，通常性能不是特別高。
AP - 滿足可用性，分區容忍性的系統，通常可能對一致性要求低一些。
CAP理論就是說在分佈式存儲系統中，最多隻能實現上面的兩點。
而由於當前的網絡硬件肯定會出現延遲丟包等問題，所以分區容忍性是我們必須需要實現的。
所以我們只能在一致性和可用性之間進行權衡，沒有 NoSQL系統能同時保證這三點。
c：強一致性 A：高可用性 P：分佈式容忍性
CA：傳統Oracle數據庫
AP：大多數網站架構的選擇
CP：Redis、Mongodb
注意：分佈式架構的時候必須做出取捨
eureka與zookeeper
著名的CAP理論指出，一個分佈式 系統不可能同時滿足C（一致性）、A（可用性）和P（分區容錯性）。由於分區容錯性P在分佈式系統中必須要保證的，因此我們只能在A和C之間進行權衡。
Zookeeper保證的是CP
當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的信息，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。但是zk會出現這樣一種情況，當master節點因爲網絡故障與其它節點失去聯繫時，剩餘節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30~120s，且選舉期間整個zk集羣都是不可用的，這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下，因網絡問題使得zk集羣失去master節點是大概率發生事件，雖然服務能夠最終恢復，但是漫長的選舉時間導致的註冊長期不可用是不能容忍的。
Eureka則是AP
Eureka看明白了這一點。因此再設計時就優先保證可用性。Eureka各個節點都是平等的，幾個幾點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢的服務。而Eureka的客戶端在向某個Eureka註冊或者發現連接失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用（保證可用性），只不過查到的信息可能不是最新的（不保證強一致性）。除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認爲客戶端與註冊中心出現了網絡故障，此時會出現以下幾種情況：
- Eureka不再從註冊列表中移除因爲長時間沒收到心跳而應該過期的服務
- Eureka依然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上（即保證當前節點依然可用）
- 當網絡穩定後，當前實例新的註冊信息會被同步到其他節點中
因此，Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況，而不會像zookeeper那樣使整個註冊服務癱瘓。