Spring Cloud（二）Eureka 服务注册与发现

什么是 Eureka？

Netflix 在设计 Eureka 时，遵循的就是 AP 原则。

CAP 原则又称 CAP 定理，指的是在一个分布式系统中

一致性（Consistency）

可用性（Availability）

分区容错性（Partition tolerance）

CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

Eureka 是 Netflflix 的一个子模块，也是核心模块之一。Eureka 是一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移，服务注册与发现对于微服务来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了，功能类似于 Dubbo 的注册中心，比如 Zookeeper。

Eureka 采用了 C-S 的架构设计，EurekaServer 作为服务注册功能的服务器，他是服务注册中心而系统中的其他微服务。使用 Eureka 的客户端连接到 EurekaServer 并维持心跳连接。这样系统的维护人员就可以通过 EurekaServer 来监控系统中各个微服务是否正常运行，SpringCloud 的一些其他模块（比如 Zuul）就可以通过 EurekaServer 来发现系统中的其他微服务，并执行相关的逻辑。

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

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

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

三大角色

Eureka Server：提供服务的注册于发现。
Service Provider：将自身服务注册到 Eureka 中，从而使消费方能够找到。
Service Consumer：服务消费方从 Eureka 中获取注册服务列表，从而找到消费服务。

项目构建

建立 springcloud-eureka-7003 模块

编辑 pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <parent>
        <artifactId>springcloud</artifactId>
        <groupId>com.wlgzs</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <artifactId>springcloud-eureka-7003</artifactId>

    <dependencies>
        <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>
            <scope>runtime</scope>
        </dependency>
    </dependencies>

</project>

application.yml

server:
  port: 7003

eureka:
  instance:
    hostname: localhost
  client:
    register-with-eureka: false #表示是否注册自己
    fetch-registry: false #false表示自己是注册中心
    service-url:
    defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

编写主启动类

启动，访问测试：

System Status：系统信息
DS Replicas：服务器副本
Instances currently registered with Eureka：已注册的微服务列表
General Info：一般信息
Instance Info：实例信息
建立 Service Provider：将 8001 的服务入驻到 7003 的 eureka 中
修改 8001 服务的 pom 文件，增加 eureka 的支持
<!-- Eureka -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
            <version>1.4.6.RELEASE</version>
        </dependency>

yaml 中配置 eureka 的支持
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7003/eureka

8001 的主启动类注解支持
@SpringBootApplication
@EnableEurekaClient  // 本服务启动之后会自动注册进Eureka中
public class DeptProvider_8001 {
    public static void main(String[] args) {
        SpringApplication.run(DeptProvider_8001.class,args);
    }
}

启动 7001，再启动 8001，测试访问

Eureka 的自我保护机制
某时刻某一个微服务不可以用了，eureka 不会立刻清理，依旧会对该微服务的信息进行保存！
  默认情况下，如果 EurekaServer 在一定时间内没有接收到某个微服务实例的心跳，EurekaServer 将会注销该实例（默认 90 秒）。但是当网络分区故障发生时，微服务与 Eureka 之间无法正常通行，以上行为可能变得非常危险了--因为微服务本身其实是健康的，此时本不应该注销这个服务。Eureka 通过 自我保护机制 来解决这个问题--**Eureka Server 在运行期间会去统计心跳失败比例在 15 分钟之内是否超过 85%，如果超过 85%，那么这个节点就会进入自我保护模式。**一旦进入该模式，EurekaServer 就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该 EurekaServer 节点会自动退出自我保护模式。
  在自我保护模式中，EurekaServer 会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该 EurekaServer 节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。
服务发现 Discovery
对于注册进 eureka 里面的微服务，可以通过服务发现来获得该服务的信息。【对外暴露服务】
修改 springcloud-provider-dept-8001 工程中的 DeptController
@Autowired
    private 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;
    }

主启动类增加一个注解
@SpringBootApplication
@EnableEurekaClient
@EnableDiscoveryClient
public class DeptProvider_8001 {
    public static void main(String[] args) {
        SpringApplication.run(DeptProvider_8001.class,args);
    }
}

启动 Eureka 服务，启动 8001 提供者，后台输出：

consumer 访问服务
在 springcloud-consumer-dept-80 中修改 DeptConsumerController 增加一个方法
@GetMapping("/discovery")
    public Object discovery() {
        return restTemplate.getForObject(REST_URL_PREFIX + "/discovery", Object.class);
    }


集群配置
新建工程 springcloud-eureka-7004、springcloud-eureka-7005；
按照 7003 为模板粘贴 POM；
修改 7004 和 7005 的主启动类；
修改映射配置 , windows 域名映射。

修改 3 个 EurekaServer 的 yml 文件
server:
  port: 7003

eureka:
  instance:
    hostname: eureka7003.com
  client:
    register-with-eureka: false #表示是否注册自己
    fetch-registry: false #false表示自己是注册中心
    service-url:
      # defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
      defaultZone: http://eureka7004.com:7004/eureka/,http://eureka7005.com:7005/eureka/

7004，7005 同上（只需要修改 defaultZone 的地址和端口）
启动集群测试

对比 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：满足可用性，分区容错性的系统，通常可能对一致性要求低一些



作为服务注册中心，Eureka 比 Zookeeper 好在哪里？
Zookeeper 保证的是 CP
  当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接 down 掉不可用。也就是说，服务注册功能对一致性的要求高于可用性。但是 zk 会出现这样一种情况，当 master 节点因为网络故障与其他节点失去联系时，剩余节点会重新进行 leader 选举。问题在于，选举 leader 的时间太长，30~120s，且选举期间整个 zk 集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得 zk 集群失去 master 节点是较大概率会发生的事件，虽然服务最终能够恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。
Eureka 保证的是 AP
  Eureka 优先保证可用性。Eureka 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而 Eureka 的客户端在向某个 Eureka 注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台 Eureka 还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka 还有一种自我保护机制，如果在 15 分钟内超过 85% 的节点都没有正常的心跳，那么 Eureka 就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

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

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

Spring Cloud（二）Eureka 服务注册与发现

什么是 Eureka？

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

三大角色

项目构建

建立 springcloud-eureka-7003 模块

编辑 pom.xml

application.yml

编写主启动类

建立 Service Provider：将 8001 的服务入驻到 7003 的 eureka 中

修改 8001 服务的 pom 文件，增加 eureka 的支持

yaml 中配置 eureka 的支持

8001 的主启动类注解支持

启动 7001，再启动 8001，测试访问

Eureka 的自我保护机制

服务发现 Discovery

修改 springcloud-provider-dept-8001 工程中的 DeptController

主启动类增加一个注解

启动 Eureka 服务，启动 8001 提供者，后台输出：

consumer 访问服务

在 springcloud-consumer-dept-80 中修改 DeptConsumerController 增加一个方法

集群配置

修改 3 个 EurekaServer 的 yml 文件

启动集群测试

对比 Zookeeper

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

相关帖子

基于 SpringBoot+Vue 框架实现前后端分离【企业级】项目，欢迎大家体验 [看]......

基于 SpringBoot+Vue 框架实现前后端分离【企业级】项目，欢迎大家体验......

Spring 事务 @Transaction 讲解

软件架构设计原则

Spring Boot 2.4 版本升级指南：夯实你的多环境配置

开启 Spring Boot 配置的大门

Springboot+Netty+WebSocket 配置

欢迎来到这里！