三：Springcloud--服务注册中心--Eureka

1.Eureka含义
Eureka是基于Rest服务，用于定位服务，实现云端中间层服务发现和故障转移，服务注册与发现对于微服务非常重要，只需要使用服务的标识符，就可以访问到服务，功能类似于Dubbo的注册中心 zookeeper.
Eureka采用了C-S架构，Eureka-server作为服务注册功能的服务器，称为注册中心，而系统中其他的微服务，使用Eureka的客户端连接到Eureka-Server并维持心跳链接，这样用户可以通过Eureka-Server来监控系统中各个微服务是否正常。
三大角色：

• Eureka-server:提供服务注册与发现
• Service-Provider:将自身服务注册到Eureka中，从而使消费方能够找到
• Srtvice-Consumer:服务消费方从Eureka中获取服务消费列表，从而找到消费服务。

Eureka提供服务注册服务，各个节点启动后，在EurekaServer中注册服务，这样在界面中会展示所有的注册节点。
EurekaClient是Java的一个客户端，客户端同时具备了内置的使用轮询算法的负载均衡器，在应用启动后，回向EurekaServer中发送心跳链接（默认30s发送一次），如果EurekaServer在多个心跳周期内没有接收到某个节点的心跳连接，会从注册表中移除这个节点（默认周期为90s）.

1.基于上篇的环境，新建springcloud-eureka-7001模块，导入依赖包，编写配置类

    <dependencies>
        <!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-eureka-server -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka-server</artifactId>
            <version>1.4.6.RELEASE</version>
        </dependency>


        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
        </dependency>
    </dependencies>

application.yml:

server:
  port: 7001
eureka:
  instance:
    hostname: eureka7001.com #服务端实例名称
  client:
    register-with-eureka: false #表示是否向Eureka注册自己
    fetch-registry: false #表示自己是注册中心
    service-url: #监控页面
      defaultZone: http://eureka7002.com:7002/eureka/
#      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

添加注解，开启Eureka服务，启动类测试：

上图就是Eureka的默认页面

2.服务注册–将服务提供者注册到Eureka中
2.1在服务提供者模块中导入Eureka-client依赖

  <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
            <version>1.4.6.RELEASE</version>
        </dependency>
        
        <!--        完善监控信息-->
        <!-- https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-actuator -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

2.2在服务提供者模块在配置文件中和添加相关Eureka的配置

#Eureka注册,服务注册到哪里
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7002/eureka/,http://localhost:7001/eureka/
  instance:
    prefer-ip-address: true
    instance-id: springcloud-provider-8001 #修改Eureka上的默认描述信息
#信息配置
info:
  app.name: wang.springcloud
  company.name: wang

2.3开启注解

重启测试：
如下图：服务 已被注册到Eureka中 测试成功
点击上图位置，则会看到编写监控信息：

3.Eureka的自我保护机制
自我保护机制：好死不如赖活着。即某一时刻，某个微服务突然崩掉，Eureka不会立刻清理，依旧会对该服务的信息进行保存。

• EurekaServer短时间内失去了多个客户端（可能发生了网络分区故障），那么这个节点就会进入自我保护机制，一旦进入该模式，EurekaServer就会保护这些节点信息，不会销毁任何微服务，当网络恢复故障后，EurekaServer会自动退出自我保护机制。
• 在自我保护机制中，Eureka会保护注册表中的信息，不再注销任何服务实例，当它收到心跳恢复到阈值以上时，会自动退出自我保护机制，设计原理就是：宁可保留错误信息，也不注销任何可能健康的实例。
  4.集群配置
  配置多个Eureka集群（将Eureka-servef-7001复制多份），并使集群之间互相产生关系，如一个Eureka注册中心失效，则还可以使用集群中的其他Eureka注册中心

添加服务提供者Eureka配置，将服务注册到另外两个注册中心

启动集群，注册服务 测试：
服务提供者在Eureka-7002中也已经完成注册。这样如果出现Eurea7001崩掉，则整个服务依然可以注册到Eureka7002，不影响正常进行。

5.CAP原则及Eureka对比Zookeeper
关系型数据库（Mysql Oracle sqlserver）=>ACID
非关系型数据库（redis mogodb）=>CAP

ACID原则：

• A(Atomicity):原子性
• C(Consistenty)：一致性
• I(Isolation):隔离性
• D(durabily)持久性

CAP原则：

• C(Consistency):一致性
• A(Avaiblity):可用性
• P(Participation Tolreance):分区容错性
  CAP三进二：CA CP AP

CAP理论核心
一个分布式系统不可能同时满足CAP原则，并且根据CAP原则，将非关系型数据库分成了满足以下三大类：

• CA:单点集群，满足数据一致性，可用性系统，通常扩展性较差
• CP:满足数据一致性和分区容错性，通常性能不是特别高
• AP：满足可用性和分区容错性，通常数据一致性得不到满足

Eureka和Zookeeper对比
因为分区容错性在分布式系统中是必须要保障的，所以只能在C A中权衡，
而zookeeper则保证了CP原则，Eureka则保证了AP原则

zookeeper:
当向注册中心查询服务列表的信息时，可以容忍查询到的信息是几分钟之前的注册信息，但不能接受服务down掉，也就是说服务注册功能的对可用性的要求要高于一致性，但是ZK会出现以下情况：当master节点因为网络故障与其他节点失去联系时，剩余节点会重新leader选举，由于选举时间大概在30s-120s,选举期间，整个集群是不能使用的，这样就导致选举期间服务是瘫痪的，在云部署的情况下，master节点与其他节点失去联系的情况是大概率发生的，虽然都会恢复，但是漫长的时间导致服务不可用是不能容忍的。

Eureka
Eureka看明白了这点，所以设计的时候优先保证了可用性，即各个节点都是平等的，几个节点挂掉不会影响整体服务，剩余的节点依旧可以提供注册和查询服务，另一方面，Eureka客户端在向某个Eureka服务注册时，如果发现连接失败，则会自动切换至其他节点。所以只要有一个Eureka服务还在，则整个服务都是可用的，只不过查到的信息可能不是最新的。除此以外，还有一保护机制：如果15分钟内超过85%出现节点都没有正常心跳，则会认为客户端与注册中心出现了网络故障，则会出现以下情况：

• Eureka不会从注册表中移除没有心跳而应该过期的服务
• Eureka仍然接受新服务的注册和请求，但是不会同步到其他节点上（即保障当前节点的可用性）
• 当网络故障恢复后，当前实例新的注册信息会同步到其他节点上

因此，Eureka可以很好的应对网络故障导致部分节点失去联系的情况，而不会像Zookeeper那样整个服务down掉。