給大家推薦個靠譜的公眾號程式設計師探索之路，大家一起加油 ​  

1.Eureka是什麼

Eureka是Netflix的一個子模組之一，AP設計原則。Eureka是一個以及Rest的服務，用於定位服務，以實現雲端中間層服務發現和故障轉移。服務註冊與發現對於微服務架構來說是非常重要的，有了服務發現與註冊，只需要使用服務的識別符號，就可以訪問到服務，而不需要修改服務呼叫的配置檔案了。功能類似於dubbo的註冊中心，比如zookeeper

                                                 Eureka Server  註冊中心示意圖

                     Dubbo示意圖                                               

2.Eureka包含兩個元件：Eureka Server和Eureka Client

Eureka Server 提供服務註冊服務

各個節點啟動後，會在EurekaServer中進行註冊，這樣EurekaServer中的服務登錄檔中將會儲存所有可用服務節點的資訊，服務節點的資訊可以在介面中直觀的看到

EurekaClient 是一個Java客戶端，用於簡化EurekaServer的互動，客戶端同時也具備一個內建的，使用輪詢（roud-robin）負載演算法的負載均衡器。在應用啟動後，將會想EurekaServer傳送心跳（預設週期為30秒）。如果EurekaServer在多個心跳週期內沒有接收到某個節點的心跳，EurekaServer將會從服務登錄檔中把這個服務節點移除（預設90秒）

3.Eureka自我保護機制

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.

       預設情況下，如果RurekaServer在一定時間內沒有接收端哦某個微服務例項的心跳，EurekaServer將會登出該例項（預設90秒）。但是當網路分割槽故障發生時，微服務與EurekaServer之間無法正常通訊，以上行為可能變得危險了---因為微服務本身其實是健康的，此時本不應該登出這個微服務。Eureka通過“自我保護模式”來解決這個問題—當EurekaServer節點在短時間內丟失過多客戶端時（可能發生了網路分割槽故障），那麼這節點就會進入自我保護模式。一旦進入該模式，EurekaServer就會保護服務登錄檔中的資訊，不在刪除服務主表中的資料（也就是不會登出任何微服務）。當網路故障恢復後，該EurekaServer節點會自動推出自我保護模式。

       在自我保護模式中，EurekaServer會保護服務登錄檔中的資訊，不在登出任何服務例項。當它收到的心跳數重新恢復到閾值以上時，該EurekaServer節點就會自動推出自我保護模式。它的設計哲學就是寧可保留錯誤的服務註冊資訊，也不盲目登出任何可能健康的服務例項。一句話講解：好死不如賴活著

綜上，自我保護模式是一種應對網路異常的安全保護措施。他的架構哲學是寧可同時保留所有微服務（健康的微服務和不健康的微服務都會保留），也不盲目登出任何健康的微服務。使用自我保護模式，可以讓Eureka叢集更加的健壯,穩定。

在SrpingCloud，可以使用eureka.server.enable-self-preservation=false禁用自我保護機制

4.ACID是什麼？關係型資料庫遵循ACID原則

A Atomicity 原子性

原子性很容易理解，也就是說事務裡的所有操作要麼全部做完，要麼都不做，事務成功的條件是事務裡的所有操作都成功，只要有一個操作失敗，整個事務就失敗，需要回滾。

C Consistency 一致性  

一致性比較容易理解，也就是說資料庫要一直處於一致的狀態，事務的執行不會改變資料庫原本的一致性約束

I Isolation 獨立性  

所謂的獨立性是指併發的事務之間不會互相影響，如果一個事務要訪問資料正在被另外一個事務修改，只要另外一個事務未提交，他所訪問的資料就不收未提交事務的影響。

D durability 永續性

永續性是指一旦事務提交後，他所作的修改將會永久的儲存在資料庫上，即使出現宕機也不會丟失。

CAP是什麼？

C Consistency 強一致性

A Availability 可用性

P Partition tolerance 分割槽容錯性

                                                 經典CAP圖

CAP理論的核心是：一個分散式系統不可能同時很好的滿足一致性，可用性和分割槽容錯性這三個需求，因此根據CAP原理將NoSQL資料庫分成了滿足CA原則，滿足CP原則和滿足AP原則三大類

CA-單點叢集，滿足一致性，可用性的系統，通常在可擴充套件性上不太強大

CP- 滿足一致性，分割槽容忍性的系統，通常效能不是特別高

AP- 滿足可用性，分割槽容忍性的系統，通常可能對一致性要求低一些

CAP理論就是說在分散式儲存系統中，最多隻能實現上面的兩點。

而由於當前的網路硬體肯定會出現演示丟包等問題，所以，分佈容錯性我們必須選擇的

5.作為服務註冊中心，Eureka比Zookeeper好在哪裡

著名的CAP理論指出，一個分散式系統不可能同時滿足CAP。由於分割槽容錯性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那樣使整個註冊服務癱瘓

本次新增eurekatest7001,7002,7003專案

C:\Windows\System32\drivers\etc 修改houst檔案

127.0.0.1    eureka7001.com
127.0.0.1    eureka7002.com
127.0.0.1    eureka7003.com

程式碼地址https://github.com/ZhZGod/spring-cloud-codes

效果截圖：