eureka（自我保护机制）（集群）（对比zookeeper）

Eureka的基本架构：

Eureka使用的市cs架构，：包含两个组件：Eureka Server 和 Eureka Client 。

Eureka Server 提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样Eureka Server中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
Eureka Client是一个Java客户端，用于简化EurekaServer的交互，在应用启动后，将会向EurekaServer发送心跳（默认周期为30秒）。如果 Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除掉（默认周期为90秒）

三大角色 Eureka Server：提供服务的注册于发现。
Service Provider：将自身服务注册到Eureka中，从而使消费方能够找到。（图右下）
Service Consumer：服务消费方从Eureka中获取注册服务列表，从而找到消费服务。（图左下）

创建springcloud-eureka-7001模块

pom.xml

 <dependencies>
        <!-- eureka-server服务端 -->
        <!-- 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.7.RELEASE</version>
        </dependency>

<!--        热部署-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
        </dependency>
    </dependencies>

application.yml

server:
  port: 7001
#Eureka配置
eureka:
  instance:
    hostname: localhost #eureka服务端的实例名称
  client:
    register-with-eureka: false # 是否将自己注册到Eureka服务器中，本身是服务器，无需注册
    fetch-registry: false # false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
    service-url:
#      单机：
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
      # 设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个defaultZone地址

主启动类

package com.xflsh.springcloud;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
@EnableEurekaServer //EurekaServer服务器端启动类，接受其他微服务注册进来！
public class EurekaServer7001 {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServer7001.class,args);
    }
}

访问：localhost:7001

在springcloud-provider-dept-8001的pom.xml添加

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

application.yml添加eureka 的支持

#eureka配置
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka

8001 的主启动类注解支持

@SpringBootApplication
@EnableEurekaClient // 本服务启动之后会自动注册进Eureka中！
public class DeptProvider8001 {
    public static void main(String[] args){
        SpringApplication.run(DeptProvider8001.class,args);
    }
}

启动7001，再启动8001　　访问：localhost:7001

配置他的信息

在8001中application.yml添加

#info配置
info:
  app.name: xflsh-springcloud　　#服务名称修改
  company.name: www.xflsh.com　　#公司名称
  build.artifactId: ${project.artifactId}　　#项目名（pom.xml中的artifactId看到） 
　build.version: ${project.version}　　#项目版本（pom.xml中的parent看到）

info内容构建

　　点击info，出现ERROR页面

8001添加依赖

<!--actuator监控信息完善-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

<build>
<finalName>springcloud</finalName>
<resources>
    <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
    </resource>
</resources>
<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-resources-plugin</artifactId>
        <version>3.0.2</version>
        <configuration>
            <delimiters>
                <!--以$开头的或者结尾的在src/main/resources路径下的就能读取-->
                <delimit>$</delimit>
            </delimiters>
        </configuration>
    </plugin>
</plugins>
</build>

点击上图绿色字体就可以看到配置信息

Eureka的自我保护机制: 好死不如赖活着

修改一个服务名，故意制造错误

一句话总结：某时刻某一个微服务不可以用了，eureka不会立刻清理，依旧会对该微服务的信息进行保存！

默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒）。但是当网络分区故障发生时，微服务与Eureka之间无法正常通行，以上行为可能变得非常危险了--因为微服务本身其实是健康的，此时本不应该注销这个服务。Eureka通过自我保护机制来解决这个问题--当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该 EurekaServer节点会自动退出自我保护模式。

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

综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮和稳定。

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

8001服务发现 Discovery

对于注册进eureka里面的微服务，可以通过服务发现来获得该服务的信息。【对外暴露服务】

8001工程中的DeptController添加

@Autowired
    DiscoveryClient client;

@GetMapping("/discovery")
    public Object discovery(){
//获得微服务列表清单
        List<String> list = client.getServices();
        System.out.println("client.getServices()==>"+list);
//得到一个具体的微服务！
        List<ServiceInstance> serviceInstanceList =
                client.getInstances("springcloud-provider-dept");
        for (ServiceInstance serviceInstance : serviceInstanceList) {
            System.out.println(
                    serviceInstance.getServiceId()+"\t"+
                            serviceInstance.getHost()+"\t"+
                            serviceInstance.getPort()+"\t"+
                            serviceInstance.getUri()
            );
        }
        return this.client;
    }

主启动类增加一个注解

@EnableDiscoveryClient //服务发现

访问测试 http://localhost:8001/dept/discovery

集群配置

集群就是：多个服务，一个服务提供者，服务和服务之间可以绑定多个服务，当其中一个服务挂掉了，其他也可继续操作。

1.新建工程springcloud-eureka-7002、springcloud-eureka-7003 按照7001为模板粘贴POM

2.修改7002和7003的主启动类

3.修改映射配置

4.windows域名映射

修改不了host因为权限不够

(17条消息) 26-在保存hosts文件时，报错unable to save C:\windows\system32\drivers\etc\hosts error:拒绝访问----文件权限修改_汐小旅Shiory的博客-CSDN博客

就可以修改了。

7001的application.yml

server:
  port: 7001
#Eureka配置
eureka:
  instance:
    hostname: eureka7001.com #eureka服务端的实例名称
  client:
    register-with-eureka: false # 是否将自己注册到Eureka服务器中，本身是服务器，无需注册
    fetch-registry: false # false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
    service-url:
#      单机：
#      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
      #      集群：
      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
      # 设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个defaultZone地址

7002的application.yml

server:
  port: 7002
#Eureka配置
eureka:
  instance:
    hostname: eureka7002.com #eureka服务端的实例名称
  client:
    register-with-eureka: false # 是否将自己注册到Eureka服务器中，本身是服务器，无需注册
    fetch-registry: false # false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
    service-url:
      #      单机：
      #      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
      #      集群：
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7003.com:7003/eureka/

7003的application.yml

server:
  port: 7003
#Eureka配置
eureka:
  instance:
    hostname: eureka7003.com #eureka服务端的实例名称
  client:
    register-with-eureka: false # 是否将自己注册到Eureka服务器中，本身是服务器，无需注册
    fetch-registry: false # false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
    service-url:
      #      单机：
      #      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
#      集群：
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/

8080的application.yml修改eureka配置

#eureka配置
eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
#      http://localhost:7001/eureka
#  http://eureka7001:7001/,http://eureka7002:7002/,http://eureka7003:7003/
  instance:
    instance-id: springcloud-provider-dept-8001 # 重点，和client平级
    prefer-ip-address: true

对比zookeeper

CAP原则 RDBMS

（Mysql、Oracle、sqlServer）===>ACID NoSQL（redis、mongdb）===> CAP ACID是什么？

A（Atomicity）原子性

C（Consistency）一致性

I （Isolation）隔离性

D（Durability）持久性

CAP是什么？

C（Consistency）

强一致性 A（Availability）

可用性 P（Partition tolerance）

分区容错性 CAP的三进二：CA、AP、CP

CAP理论的核心

一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求

根据CAP原理，将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类：

CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差
CP：满足一致性，分区容错性的系统，通常性能不是特别高
AP：满足可用性，分区容错性的系统，通常可能对一致性要求低一些

Zookeeper保证的是CP 当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得zk集群失去master节点是较大概率会发生的事件，虽然服务最终能够恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

简单来说：Zookeeper如果leader坏掉了，选举leader的时间太长且选举期间整个zk集群都是不可用的，会导致在选举期间注册服务瘫痪

Eureka保证的是AP Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个 Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有一种自我保护机制，如果在 15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况： 1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点依然可用） 3. 当网络稳定时，当前实例新的注册信息会被同步到其他节点中。

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