Eureka 叢集搭建

我們都知道，一個註冊中心來接收服務，如果這個註冊中心崩了，放在這個註冊中心裡邊的所有服務都會有故障；所以我們可以搭建叢集的方式來避免這個問題，如下圖，有三個註冊中心，他們分別關聯。接下來分別來搭建一下

​ 1）分別建立7001,7002,7003埠（當然，這邊用的是虛擬遠端，嘻嘻嘻嘻）

server:
  port: 7001

#Eureka配置
eureka:
  instance:
    hostname: eureka7001.com   #Eureka服務端的例項名稱
  client:
    register-with-eureka: false #表示是否向Eureka註冊中心註冊自己
    fetch-registry: false  #fetch-registry如果為false，則表示自己為註冊中心
    service-url: #監控頁面
      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
 

server:
  port: 7002

#Eureka配置
eureka:
  instance:
    hostname: eureka7002.com  #Eureka服務端的例項名稱
  client:
    register-with-eureka: false #表示是否向Eureka註冊中心註冊自己
    fetch-registry: false  #fetch-registry如果為false，則表示自己為註冊中心
    service-url: #監控頁面
      #單機  defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
      #叢集 （關聯）
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7003.com:7003/eureka/
 

server:
  port: 7003

#Eureka配置
eureka:
  instance:
    hostname: eureka7003.com    #Eureka服務端的例項名稱
  client:
    register-with-eureka: false #表示是否向Eureka註冊中心註冊自己
    fetch-registry: false  #fetch-registry如果為false，則表示自己為註冊中心
    service-url: #監控頁面
      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7001.com:7001/eureka/
 

主啟動類都是一樣的

package com.mjh.springcloud;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;
@SpringBootApplication
@EnableEurekaServer   //@EnableEurekaServer  服務端啟動類，可以接受別人註冊進來（即註冊中心）
public class EurekaServer_7003 {
    /**
     * 啟動之後，訪問http://localhost:7001/
     */
    public static void main(String[] args) {
        SpringApplication.run(EurekaServer_7003.class,args);
    }
}

之後開啟任意一個埠，我們都能發現其中兩個埠都掛載進來了

最後我們開啟服務提供者，讓其把資訊註冊進來，當然我們服務提供者也要關聯他們三個埠

#Eureka配置，服務註冊到哪裡
eureka:
  client:
    service-url:
      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7001.com:7001/eureka/,http://eureka7003.com:7003/eureka/
  instance:
    instance-id: springcloud-privider-dept8001  #修改Eureka的狀態描述

由此可見，Eureka搭建叢集的好處就是如果其中一個註冊中心崩了，我們的服務還是會正常執行，只要有一個Eureka還在，就能保住註冊服務的可用性，因為一邊沒有了服務，還有另一邊；也不排除三個註冊中心都同時崩（這是少見）。

CPA原則與zookeeper對比

ACID是什麼

• A（Atomicity）原子性
• B（Consistency）一致性
• I（Isolation）隔離性
• D（Durability）永續性

CAP是什麼

• C（consistency）一致性
• A(Availability) 可用性
• P（Partition tolerance）分割槽容錯性

CAP理論的核心

• 一個分散式系統不可能同時很好的滿足一致性，可用性和分割槽容錯性這三個要求
• 根據CAP原理，將NoSQL資料庫分成了滿足CA原則，滿足CP原則和AP原則三大類
• CA：單點叢集，滿足一致性，可用性的系統，通常可擴充套件性較差
• CP：滿足一致性，分割槽容錯性的系統，通常效能不是特別高
• AP：滿足可用性，分割槽容錯性的系統，通常可能對一致性要求低一些

作為服務註冊中心，Eureka和Zookeeper好在哪裡

著名的CAP理論指出，一個分散式系統不可能同時滿足C（一致性）A（可用性）P（分割槽容錯性）

由於分割槽容錯性P在分散式系統中是必須要保證的，因此我們只能在A和C之間進行權衡

• Zookeeper保證的是CP
• Eureka保證的是AP

Zookeeper保證的是CP

當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊資訊，但不能接受服務直接Down掉不可用。也就是說，服務註冊功能對可用性的要求高於一致性。但是Zookeeper會出現這樣一種情況，當master節點因為網路故障與其他節點數去聯絡時，剩餘節點會重新進行Leader選舉，問題在於，選舉Leader的時間太長，30S——40S ，且選舉期間整個Zookeeper叢集都是不可用的，這就導致了在選舉期間註冊服務癱瘓。在雲部署的環境下，因為網路問題使得Zookeeper叢集失去master節點是較大概率會發生的失去，雖然服務最終能夠恢復，但漫長的時間選舉時間導致的註冊長期不可用是能容忍的

Eureka保證的是AP

Eureka看明白了這一點，因此在設計時就有限保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務，而Eureka的客戶端在想某個Eureka註冊時，如果發現連線失敗，則會自動切換到至其他節點，只要有一臺EUreka還在，就能保證註冊服務的可用性，只不過查詢到的資訊可能不是最新的，除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認為客戶端與註冊中心出現了網路故障，此時會出現以下幾種情況：

1.Eureka不再從註冊列表中移除因為長時間沒有收到心跳而應該過期的服務

2.Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其他節點上（即保證當前節點依舊可用）

3.當網路穩定時，當前例項行的註冊資訊會被同步到其他節點中

因此，Eureka可以很好的應對因為網路故障導致部分節點失去聯絡的情況，而不會像Zookeeper那樣使整個註冊服務癱瘓