二：SpringCloud-Eureka

五：Eureka服务注册与发现

1. 是什么

Spring Cloud 封装了 Netflix 公司开发的 Eureka 模块来实现==服务注册和发现==(请对比Zookeeper)。

Eureka 采用了 ==C-S 的设计架构==。Eureka Server 作为服务注册功能的服务器，它是服务注册中心。

而系统中的其他微服务，使用 Eureka 的客户端连接到 Eureka Server并维持心跳连接。这样系统的维护人员就可以通过 Eureka Server 来监控系统中各个微服务是否正常运行。SpringCloud 的一些其他模块（比如Zuul）就可以通过 Eureka Server 来发现系统中的其他微服务，并执行相关的逻辑。

2. 原理讲解

三大角色：
==Eureka Server== 提供服务注册和发现
==Service Provider== 服务提供方将自身服务注册到Eureka，从而使服务消费方能够找到
==Service Consumer== 服务消费方从Eureka获取注册服务列表，从而能够消费服务

Eureka：

Dubbo：

Eureka包含两个组件：Eureka Server和Eureka Client。

==Eureka Server== 提供服务注册。各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。

==EurekaClient== 是一个Java客户端，用于简化Eureka Server的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除（默认90秒）。

3. 构建步骤

1. Eureka服务注册中心Module

1.新建microservicecloud-eureka-7001
2.POM
3.YML
4.EurekaServer7001_App主启动类
5.测试 http://localhost:7001/
​ 结果页面：No application available 没有服务被发现
​ 因为没有注册服务进来当然不可能有服务被发现

1.2 POM

<!--eureka-server服务端 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka-server</artifactId>
</dependency>
<!-- 修改后立即生效，热部署 -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>springloaded</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-devtools</artifactId>
</dependency>

1.3 YML

server:
    port: 7001
eureka:
    instance:
        hostname: localhost  #eureka服务端的实例名称
    client:
        register-with-eureka: false  #false表示不向注册中心注册自己
        fetch-registry: false  #false表示自己端就是注册中心
        service-url:  #单机  #设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址
            defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

1.4 EurekaServer7001_App主启动类

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

2. 将已有的部门微服务注册进eureka服务中心

修改microservicecloud-provider-dept-8001：

2.1 修改POM：

<!-- 将微服务provider者注册进eureka -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>

2.2 修改YML：

eureka:
    client:  #客户端注册进eureka服务列表内
        service-url: 
            defaultZone: http://localhost:7001/eureka/

2.3 DeptProvider8001_App主启动类：

@EnableEurekaClient  //本服务启动后会自动注册进eureka服务中

2.4 测试：

==先要启动EurekaServer==
http://localhost:7001/
==微服务注册名==配置说明：==spring.application.name== = microservicecloud-dept

3. actuator与注册微服务信息完善

修改microservicecloud-provider-dept-8001：

3.1 主机名称：服务名称修改：

eureka:
    instance:
        instance-id: microservicecloud-dept8001  #自定义服务名称信息

3.2 访问信息有IP信息展示：

eureka:
    instance:
        prefer-ip-address: true  #访问路径可以显示IP地址

3.3 微服务info内容详细信息：

3.3.1 修改microservicecloud-provider-dept-8001(POM)：

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

3.3.2 总的父工程microservicecloud修改pom.xml添加构建build信息(POM)：

<build>
  <finalName>microservicecloud</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>
      <configuration>
        <delimiters>
          <!-- 使用maven-resources-plugin插件读取src/mai/resources文件下的application.yml -->
          <!-- 读取application.yml文件里的以$开头，以$结尾之间的信息 -->
          <delimit>$</delimit>
        </delimiters>
      </configuration>
    </plugin>
  </plugins>
</build>

3.3.3 修改microservicecloud-provider-dept-8001(YML)：

info: 
  app.name: atguigu-microservicecloud
  company.name: www.atguigu.com
  build.artifactId: $project.artifactId$    #由maven-resources-plugin插件来进行读取
  build.version: $project.version$

4. eureka自我保护

什么是自我保护模式？

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

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

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

在Spring Cloud中，可以使用==eureka.server.enable-self-preservation = false== 禁用自我保护模式。

导致原因：一句话：==某时刻某一个微服务不可用了，eureka不会立刻清理，依旧会对该微服务的信息进行保存==

5. 服务发现Discovery

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

5.1 修改microservicecloud-privider-dept-8001工程的DeptController

@Autowired
private DiscoveryClient client;

@RequestMapping(value = "/dept/discovery", method = RequestMethod.GET)
public Object discovery()
{
    List<String> list = client.getServices();
    System.out.println("**********" + list);

    List<ServiceInstance> srvList = client.getInstances("MICROSERVICECLOUD-DEPT");
    for (ServiceInstance element : srvList) {
     System.out.println(element.getServiceId() + "\t" + element.getHost() + "\t" + element.getPort() + "\t" + element.getUri());
    }
    return this.client;
}

5.2 DeptProvider8001_App主启动类

@EnableDiscoveryClient //服务发现

5.3 自测

先要启动EurekaServer
再启动DeptProvider8001_App主启动类，需要稍等一会
http://localhost:8001/dept/discovery

5.4 修改microservicecloud-consumer-dept-80工程的DeptController_Consumer

// 测试@EnableDiscoveryClient,消费端可以调用服务发现
@RequestMapping(value = "/consumer/dept/discovery")
public Object discovery()
{
  return restTemplate.getForObject(REST_URL_PREFIX + "/dept/discovery", Object.class);
}

//DeptConsumer80_App主启动类上添加@EnableEurekaClient注解标签
@EnableEurekaClient

4. 集群配置

1. 原理说明

2. 新建microservicecloud-eureka-7002/microservicecloud-eureka-7003

3. 按照7001为模板粘贴POM

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

5. 修改映射配置

在C:\Windows\System32\drivers\etc路径下的hosts文件中添加：

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

6. 在3台eureka服务器的yml配置

# 7001配置
server:
    port: 7001
eureka:
    instance:
        hostname: eureka7001.com    #eureka服务端的实例名称
    client:
        service-url:    # 服务注册与发现的交互地址
            defaultZone:    http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
# 7002配置
server:
    port: 7002
eureka:
    instance:
        hostname: eureka7002.com    #eureka服务端的实例名称
    client:
        service-url:    # 服务注册与发现的交互地址
            defaultZone:    http://eureka7001.com:7001/eureka/,http://eureka7003.com:7003/eureka/
# 7003配置
server:
    port: 7003
eureka:
    instance:
        hostname: eureka7003.com    #eureka服务端的实例名称
    client:
        service-url:    # 服务注册与发现的交互地址
            defaultZone:    http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/

7.微服务8001注册到上面3台eureka集群配置中

eureka:
  client: #客户端注册进eureka服务列表内
    service-url: 
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/

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

1. 传统的ACID分别是什么？关系型数据库遵循ACID规则

事务在英文中是transaction,和现实世界中的交易很类似,它有如下四个特性:
1,1 A (Atomicity)原子性

原子性很容易理解,也就是说事务里的所有操作要么全部做完,要么都不做,事务成功的条件是事务里的所有操作都成功,只要有一个操作失败整个事务就失败,需要回滚。比如银行转账,从A账户转100元至B账户,分为两个步骤: 1)从A账户取100元; 2)存入100元至B账户。这 1两步要么一起完成,要么一起不完成,如果只完成第一步,第二步失败,钱会莫名其妙少了100元。

1.2c (Consistency)一致性

1. 一致性也比较容易理解,也就是说数据库要一直处于一致的状态,事务的运行不会改变数据库原本的一致性约束。

1.3I (Isolation)独立性

所谓的独立性是指并发的事务之间不会互相影响,如果一个事务要访问的数据正在被另外一个事务修改,只要另外一个事务未提交,它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户,在这个交易还未完成的情况下,如果此时B查询自己的账户,是看不到新增加的100元的

1.4D（Durability）持久性

持久性是指一旦事务提交后，他所做的修改将永久的保存在数据库上，即使出现宕机也不会丢失。

2.经典CAP图

最多只能同时较好的满足两个。

CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,因此,根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三大类:

CA-单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大。
CP-满足一致性,分区容忍必的系统,通常性能不是特别高。
AP-满足可用性,分区容忍性的系统,通常可能对一致性要求低一些。

3.CAP的3进2

CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题,所以==分区容忍性是我们必须需要实现的==。

所以我们只能在==一致性==和==可用性==之间进行权衡,没有NoSQL系统能同时保证这三点。

C:强一致性A:高可用性P:分布式容忍性
CA 传统Oracle数据库
AP 大多数网站架构的选择
CP Redis, Mongodb
注意:分布式架构的时候必须做出取舍。

4.Eureka比Zookeeper好在哪里

著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡。
因此 ==Zookeeper保证的是CP，Eureka则是AP==。

4.1 Zookeeper保证CP

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

4.2 Eureka保证AP

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

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