前言
我們在上篇講到，使用Ribbon負載均衡用戶端，實作對
Provider
叢集的通路。微服務注冊在Eureka中，通路服務通過，微服務在Eureka中的ID。先在有一個問題，如果我們這個Eureka服務挂掉了，那麼整個微服務是不是都會癱瘓呢。那麼我們必須保證Eureka服務系統的高可用,為了達到這一目的，我們可以通過搭建Eureka叢集來實作。
什麼是叢集：不同的伺服器上運作一個相同的服務，而這些伺服器群體，對外作一個超大運算的整體。
作用：高可用，其中一台機器當機，還是叢集的其他機器還能提供相同的服務。
一、Eureka-server叢集搭建
工程搭建：
microservice_eureka_7002
microservice_eureka_7003
搭建過程過程同
microservice_eureka_7001
子產品。子產品建立完成之後，在本機
hosts
配置位址映射
//之前eureka7001也配置了
127.0.0.1 eureka7002
127.0.0.1 eureka7003
建立好了三個eureka-server之後。我們要考慮的問題是，如何讓他們3個之間捆綁在一起，形成一個整體。我們可以想象A B C ,三個人，手牽手圍成一個圈。
A 牽着 B和C
B牽着 A和B
C牽着 A和B
那麼這樣，他們三個是不是就捆綁在一起了呢。Eureka，也可以效仿這種模式。在每一個Eureka-server中都注冊指向兩個Eureka-server.
配置如下：
microservice_eureka_7001
microservice_eureka_7001
server:
port: 7001 #服務端口名稱
eureka:
instance:
hostname: eureka7001
client:
fetch-registry: false # 不用檢索服務 自己是注冊中心
register-with-eureka: false #不向注冊中心注冊自己
service-url:
defaultZone: http://eureka7002:7002/eureka,http://eureka7003:7003/eureka
microservice_eureka_7002
microservice_eureka_7002
server:
port: 7002 #服務端口名稱
eureka:
instance:
hostname: eureka7002
client:
fetch-registry: false # 不用檢索服務 自己是注冊中心
register-with-eureka: false #不向注冊中心注冊自己
service-url:
#叢集版本 配置7001 7003eureka服務的位址資訊
defaultZone: http://eureka7001:7001/eureka,http://eureka7003:7003/eureka
microservice_eureka_7003
microservice_eureka_7003
server:
port: 7003 #服務端口名稱
eureka:
instance:
hostname: eureka7003
client:
fetch-registry: false # 不用檢索服務 自己是注冊中心
register-with-eureka: false #不向注冊中心注冊自己
service-url:
defaultZone: http://eureka7001:7001/eureka,http://eureka7002:7002/eureka
二、測試
啟動我們配置好叢集關系的3個
Eureka
服務，啟動過程過程可能會有點慢，等待啟動成功之後，随便通路其中一個eureka服務
http://eureka7001:7001/
到此處，這三個Eureka-server，注冊中心也就關聯起來了。
三、修改服務的注冊位址
因為我的Eureka位址已經由原來的一個，變成三個，是以，我們注冊的服務的時候，應該向Eureka叢集服務注冊。将三個服務的提供者
provider
的配置檔案裡的
defaultZone
修改如下：
eureka: #設定eureka注冊服務的位址
client:
service-url:
defaultZone: http://eureka7001:7001/eureka,http://eureka7003:7003/eureka,http://eureka7002:7002/eureka
四、修改服務的發現位址
同樣需要修改
microservice_product_consumer80
發現服務的Eureka位址，也就是加上另外兩個注冊中心的位址，
eureka:
client:
service-url:
#eureka發現服務的清單
defaultZone: http://eureka7001:7001/eureka,http://eureka7003:7003/eureka,http://eureka7002:7002/eureka
五、測試
這樣三個Eureka注冊中心，就可以達到高可用狀态，其中某個Eureka因為延遲，或者網絡故障，并不會使得整個微服務癱瘓，一個不行了，還有兩個幫忙。
啟動三個服務的提供者
8001
8002
8003
和服務的消費者
microservice_product_consumer80
。進入Eureka背景。
服務已經正常注冊了，當我們通路
http://localhost/consumer/product/list
時。也能得到我們的資料，我們開始嘗試關掉某一個Eureka注冊中心，看看請求是不是還能正常發送。再次發送請求
http://localhost/consumer/product/list
，也是能夠正常通路的，也就說明，整個微服務還是能夠正常運轉的，Eureka高可用，就的目的也就達到啦。
六、Eureka相對于Zookeeper的優勢
Zookeeper遵守CP（一緻性，分區容錯性），但是不能保證高可用，因為當zookeeper叢集某一台機器不可用之後，剩餘節點會重新選舉leader,但是leader選舉的時候過長，會導緻在選舉這段時候30-120s期間，zookeeper叢集是癱瘓的狀态。
Eureka遵守AP（高可用，分區容錯性），Eureka各個節點都是平等的，幾個節點挂點，不會影響的剩餘的節點提供服務。隻要有Eureak服務還在工作，當Eureka-client向某個eureka節點注冊或查詢服務時如果發現連接配接失敗，就會自動連接配接到其他eureka伺服器，隻不過查詢到是資料可能不是最新的（因為eureka無法保證資料的一緻性）
在應用啟動後，将會向Eureka Server發送心跳,預設周期為30秒，如果Eureka Server在多個心跳周期内沒有接收到某個節點的心跳，Eureka Server将會從服務系統資料庫中把這個服務節點移除(預設90秒)。
如果在15分鐘内，超過85%節點沒喲正常的心跳，那麼Eureka就認為用戶端與注冊中心出現了網絡故障
自我保護機制：
1、Eureka不會從注冊清單中移除長時間沒有心跳的服務（好死不如賴活着）。
2、Eureka仍然能夠接受新服務的注冊和查詢請求，但是不會被同步到其他的節點當中。
3、當網絡穩定時候，目前新執行個體的注冊資訊會被同步到其他節點當中。
我們經常看到的下面這個警告，其實就是自我保護機制的 提示
是以：Eureka能很好的應對因為網絡故障和部分節點失去聯系的狀況，不會像zookeeper一樣，需要重新選舉leader，然後導緻在選舉期間，整個注冊中心系統都會癱瘓