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

源码地址：下载地址