SpringCloud Eureka集羣及CAP原則對比Zookeeper

內容簡介：

在之前的文章中，我們詳細介紹了Eureka的服務註冊與發現，今天呢我們重點來做一下Eureka的集羣配置，捎帶介紹一下CAP原則及eureka和zookeeper的對比

Eureka集羣配置：

項目結構：

爲了簡便，我們這裏只搭建兩個Eureka服務註冊中心，具體代碼可以參考之前的Eureka的服務註冊與發現

修改Eureka server配置(pom.xml)：

修改7001的application.yml

#Eureka配置
eureka:
  instance:
    hostname: eurekaServer7001.com
  client:
    register-with-eureka: false #不向服務器註冊自己
    fetch-registry: false #false 自己爲註冊中心，true客戶端
    service-url:
      #單機：defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
      #集羣,多個服務以‘,’隔開：defaultZone: http://${eureka.instance.hostname}:7002/eureka/,http://eurekaServer7003.com:7003/eureka/
      defaultZone: http://eurekaServer7002.com:7002/eureka/

修改7002的application.yml

#Eureka配置
eureka:
  instance:
    hostname: eurekaServer7002.com
  client:
    register-with-eureka: false #不向服務器註冊自己
    fetch-registry: false #false 自己爲註冊中心，true客戶端
    service-url:
      #單機：defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
      #集羣,多個服務以‘,’隔開：defaultZone: http://${eureka.instance.hostname}:7002/eureka/,http://eurekaServer7003.com:7003/eureka/
      defaultZone: http://eurekaServer7001.com:7001/eureka/

修改服務提供者配置

應對eureka集羣，服務提供者需要向集羣中的所有結點註冊自己，修改配置文件

#Eureka 配置
eureka:
  client:
    service-url:
      #集羣註冊中心：defaultZone: http://eurekaServer7001.com:7001/eureka/,http://eurekaServer7002.com:7002/eureka/
      defaultZone: http://eurekaServer7001.com:7001/eureka/,http://eurekaServer7002.com:7002/eureka/
  instance:
    instance-id: peo8081

至此Eureka server的集羣搭建完畢

CAP原則

CAP是什麼？
C(consistency) : 強一致性
A(availability) : 可用性
P(partition tolerance) : 分區容錯性
CAP的三進二：AP\CP\AC

CAP理論的核心：

• 一個分佈式系統不能同時滿足一致性、可用性、分區容錯性
• 根據CAP原則，將NoSql數據庫分爲滿足三進二的三大類
  • AC： 單點集羣：滿足一致性，可用性系統，可擴展性比較差
  • CP： 滿足一致性，分區容錯性的系統，可用性不是特別高
  • AP：滿足可用性，分區容錯性，一致性相對較差

作爲服務註冊中心，eureka和zookeeper的對比

前面說到，一個分佈式系統不能同時滿足CAP原則，相對的分錯容錯性是分佈式系統必不可少的一個部分，所以對於分佈式系統只有兩種原則實現：AP\CP

ZOOKEEPER：保證的是CP原則，即當我們向服務中心請求資源時，我們可以容忍服務中心返回的是幾分鐘前的信息，但不接受服務器直接掛掉不可用，也就是說，一致性相對高於可用性，BUG：zk存在一個問題，集羣中當master節點掛掉，集羣會進行一次內部選舉，選一個新的節點作爲master，這個時間是很長的(30~120s)，在此期間集羣處於不可用狀態，導致服務癱瘓，這是不可容忍的。

EUREKA：保證的是AP原則，相對zookeeper來說eureka的各個節點都是平等的，幾個節點掛掉並不會影響服務的使用，客戶端再向服務中心註冊服務時，只要有一個節點可用，就不影響服務的註冊，另外eureka提供自我保護機制，當一段時間（15min）內超過85%的服務沒有心跳時，eureka會認爲客戶端與服務中心出現網絡故障，eureka會採用以下方式處理：

• eureka不再移除服務列表中因爲長時間沒有心跳而應該過期的服務
• eureka仍可以接受新服務的註冊即查詢請求，但不會同步到其他節點，保證當前節點可用，
• 一旦其他節點恢復，再同步

Eureka可以很好的應對網絡故障導致部分節點掛掉的故障，而不會出現zookeeper的整個服務癱瘓，直至選舉出新的master