Eureka集群配置

集群配置

1. 新建microservicecloud-eureka-7002/microservicecloud-eureka-7003
2. 按照7001为模板粘贴POM
3. 修改7002和7003的主启动类
4. 修改映射配置
   1. 知道C：\Windows\System32\drivers\etc路径下的hosts文件
   
   2. 修改映射配置添加进hosts文件

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

5. 3台eureka服务器的yml配置
   7001

server: 
  port: 7001
eureka: 

  instance:

    hostname: eureka7001.com #eureka服务端的实例名称

  client: 

    register-with-eureka: false     #false表示不向注册中心注册自己。

    fetch-registry: false     #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务

    service-url: 

      #单机 defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/       #设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址（单机）。

      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/

7002

server: 
  port: 7002
eureka: 

  instance:

    hostname: eureka7002.com #eureka服务端的实例名称

  client: 

    register-with-eureka: false     #false表示不向注册中心注册自己。

    fetch-registry: false     #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务

    service-url: 

      #单机 defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/       #设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址（单机）。

      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7003.com:7003/eureka/

7001

server: 
  port: 7003
eureka: 

  instance:

    hostname: eureka7001.com #eureka服务端的实例名称

  client: 

    register-with-eureka: false     #false表示不向注册中心注册自己。

    fetch-registry: false     #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务

    service-url: 

      #单机 defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/       #设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址（单机）。

      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7001.com:7001/eureka/

6. microservicecloud-provider-dept-8001微服务发布到上面3台eureka集群配置中

eureka:

  client: #客户端注册进eureka服务列表内

    service-url: 

      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/

CAP

RDBMS(mysql/oracle/sqlServer)>ACID
A(Atomicity)原子性
C(Consistency)一致性
I(Isolation)独立性
D(Durability)持久性
NOSQL(redis/mongdb)========>CAP
C(Consistency)强一致性
A(Availability)可用性
P(Partition tolerance)分区容错性
最多只能同时较号的满足两个
CAP理论的核心是：一个分布式系统不可能同时满足一致性、可用性、和分区容错行这三个需求，因此，根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三大类；
CA-单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
CP-满足一致性，分区容错的系统，通常性能不是特别高
AP-满足可用性，分区容错性的系统，通常可能对一致性要求低一些

CAP的3进2

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延时丢包等问题，所以分区容错性是我们必须要实现的。
所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

作为服务注册中心，Eureka比Zookeeper好在哪里

著名的CAP理论指出，一个分布式系统不可能同时满足C（一致性）A（可用性）P（分区容错性）。由于分区容错性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那样使整个服务瘫痪。