SpringCloud-Eureka

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掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样的情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题是，选举的时间太长30-120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪，在云部署的环境下，因为网络问题使得zk集群失去master节点是较大概率会发生的时间，虽然服务最终能够恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证的是AP
Eureka在设计时就有限保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务，而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，会自动切换到其他节点，只要有一台节点在，就能保证注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现一下几种情况：

• Eureka不再从注册列表中移除因为长时间没有收到心跳而应该过期的服务
• Eureka仍然能够接受新服务的注册和查询，但是不会被同步到其他节点上(保证当前节点依然可用)
• 当网络稳定时，当前实例新的注册信息会被同步到其他节点中

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样是整个注册服务瘫痪

原理讲解

Eureka的基本架构
SpringCloud封装了NetFlix公司开发的Eureka模块来实现服务注册和发现
而系统中的其他服务，使用Eureka的客户端连接到EurekaServer并维持心跳连接，这样系统的维护人员就可以通过EurekaServer来监控各个微服务是否正常运行。
自我保护机制
自我保护机制：好死不如赖活着
某时刻某一个微服务不可以用了，Eureka不会立即清理，依旧会对该微服务的信息进行保存

• 默认情况下，如果EurekaServer在一定时间内没有接受到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒）。但是当网络发生故障时，微服务与Eureka之间无法正常通行，以上行为会变得非常危险–因为微服务本身其实是健康的，此时本不该注销这个服务。

• Eureka通过自我保护机制来解决这个问题–当EurekaServer节点在短时间内丢失过多客户端时（可能发生网络分区故障），那么这个节点就会进入自我保护机制，一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络恢复后，该EurekaServer节点会自动退出自我保护模式。

• 在自我保护模式中，EurekaServer会保护服务注册表中的信息，不再注销任何服务实例，当它收到的心跳数重新恢复到阈值以上时，该EurekaServer节点就会自动退出自我保护机制。他的设计哲学就是：宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。

• 在SpringCloud中，可以使用eureka.server.enable-self-preservation = false 禁用自我保护模式（不推荐关闭自我保护机制）

创建Eureka服务

导入依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka-server</artifactId>
    <version>1.4.6.RELEASE</version>
</dependency>

application.yml

server:
  port: 7001
eureka:
  instance:
    hostname: localhost #eureka服务端的实例名称
  client:
    register-with-eureka: false #表示是否向Eureka中心注册自己
    fetch-registry: false #表示自己为注册中心
    service-url:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

在启动类添加

@EnableEurekaServer

创建Eureka提供者

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    <version>2.2.1.RELEASE</version>
</dependency>
 <!--监控信息-->
 <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-actuator</artifactId>
 </dependency>

application.yml

server:
  port: 8001

spring:
  application:
    name: springcloud-pro-dept-8001
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka/
  instance:
    instance-id: springcloud-proDept-8001

#配置服务信息
info:
  app.name: wyh
  company: dagongsi

创建Eureka集群

创建两个Eureka服务，将两个Eureka服务关联起来
在yml文档中，将其他Eureka的URL添加进去
springcloud-eureka-7001 中application.yml

server:
  port: 7001
eureka:
  instance:
    hostname: eurekas7001.com

  client:
    register-with-eureka: false #表示是否向Eureka中心注册自己
    fetch-registry: false #表示自己为注册中心
    service-url:
      defaultZone: http://eurekas7001.com:7001/eureka/,http://eurekas7002.com:7002/eureka/

springcloud-eureka-7002 中application.yml

server:
  port: 7002
eureka:
  instance:
    hostname: eurekas7002.com

  client:
    register-with-eureka: false #表示是否向Eureka中心注册自己
    fetch-registry: false #表示自己为注册中心
    service-url:
      defaultZone: http://eurekas7001.com:7001/eureka/,http://eurekas7002.com:7002/eureka/

Eureka自我保护机制

某时刻某一个微服务不可以用了，eureka不会立刻清理，依旧会对该微服务的信息进行保存！
默认情况下，如果EurekaServer在一定时间内没有接受到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒）。但是当网络分区故障发生时，微服务与Eureka之间无法正常通行，此时不应该注销这个服务，这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据。当网络故障回复后，该EurekaServer节点会自动退出自我保护模式