SpringCloud：4-Eureka服务注册与发现

阅读量

Eureka服务注册与发现

一、什么是Eureka

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

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

  • 功能类似于Dubbo的注册中心，如Zookeeper。

二、原理讲解

  • Eureka的基本架构

    • SpringCloud封装了Netflix公司开发的Eureka模块来实现服务注册与发现（对比Zookeeper）
    • Eureka采用c/s架构，EurekaServer作为服务注册功能的服务器，他是服务注册中心。
    • 而系统中的其他微服务（如本例中的消费者），使用Eureka的客户端连接到EurekaServer，并维持心跳连接。这样系统维护人员可通过EurekaServer来监控系统中各个微服务是否正常运行。SpringCloud的一些模块（比如Zuul）就可以通过EurekaServer来发现系统中的其他微服务，并执行相关逻辑。
    • Eureka包含两个组件：Eureka Server和Eureka Client
    • Eureka Server提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册。这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
    • EurekaClient是一个Java客户端，用于简化Eureka Server的交互。客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除（默认90秒）

  • 三大角色

    • Eureka Server：提供服务的 注册与发现
    • Server Provider：将自身服务注册到Eureka中，从而使消费方能够找到（服务提供方）
    • Server Consumer：服务消费方从Eureka中 获取注册服务列表，从而找到消费服务。（服务消费方）
      加载图片！

三、环境搭建——Eureka服务端

所有工程套路步骤：导入依赖、编写配置文件、开启此功能（@EnableXXX）、配置类。

3.1.导入依赖：

1
2
3
4
5
6
<!-- eureka-server -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka-server</artifactId>
    <version>1.4.6.RELEASE</version>
</dependency>

3.2.编写配置文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
server:
  port: 7001

# Eureka配置（自己是谁，该干嘛，到哪去访问）
eureka:
  instance:
    hostname: localhost # Eureka服务端名字
  client:
    # 表示 是否向Eureka注册中心注册自己（这里定义的就是注册中心，所以不用）
    register-with-eureka: false 
    fetch-registry: false # false表示自己是注册中心（为true表示 是客户端）
    service-url: # 监控页面
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

3.3.在主启动类中开启Eureka 注册中心

1
2
3
4
5
6
7
@SpringBootApplication
@EnableEurekaServer  // Eureka服务端，即注册中心
public class EurekaServer_7001 {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServer_7001.class, args);
    }
}

3.4.配置类（不需要，因为在配置文件中已经都写好了）

3.5.启动主启动类后，访问http://localhost:7001/ ，可以看到注册中心页面。

四、环境搭建——Eureka服务提供者

在上一节创建的springcloud-provider-dept-8001服务提供者项目里，修改以下东西。

4.1.导入依赖：

1
2
3
4
5
6
<!-- eureka -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
    <version>1.4.6.RELEASE</version>
</dependency>

4.2.编写配置文件：添加以下配置

1
2
3
4
5
# Eureka配置（把服务注册到哪里）
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka/

4.3.在主启动类中开启Eureka 服务端

1
2
3
4
5
6
7
@SpringBootApplication
@EnableEurekaClient // 在服务启动后，自动注册到Eureka注册中心中
public class DeptProvider_8001 {
    public static void main(String[] args) {
        SpringApplication.run(DeptProvider_8001.class, args);
    }
}

4.4.启动主启动类后，访问http://localhost:7001/ 注册中心页面，显示以下内容
加载图片！

4.5.关闭springcloud-provider-dept-8001，只开启7001注册中心项目，过一段时间刷新注册中心，会发现以下提示。
加载图片！

Eureka自我保护：什么是自我保护模式？

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

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

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

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

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

五、环境搭建——eureka的服务发现

在springcloud-provider-dept-8001项目里做如下配置。

5.1. 主启动类加上 启动服务发现

1
2
3
4
5
6
7
8
@SpringBootApplication
@EnableEurekaClient // 在服务启动后，自动注册到Eureka注册中心中
@EnableDiscoveryClient //服务发现
public class DeptProvider_8001 {
    public static void main(String[] args) {
        SpringApplication.run(DeptProvider_8001.class, args);
    }
}

5.2.控制层做如下配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// 获取一些配置信息，得到具体的微服务
@Autowired
private DiscoveryClient discoveryClient;

// 注册进来的微服务，获取一些信息
@RequestMapping(value = "/dept/discovery", method = RequestMethod.GET)
public Object discovery(){
    // 获得微服务列表的清单
    List<String> services = discoveryClient.getServices();
    System.out.println("discovery=>services: " + services);

    // 得到一个具体的微服务信息(参数为具体服务的id，applicationName)
    List<ServiceInstance> srvList = discoveryClient.getInstances("MICROSERVICECLOUD-DEPT");
    for (ServiceInstance element : srvList) {
        System.out.println(
                element.getServiceId() + "\t" +
                element.getHost() + "\t" +
                element.getPort() + "\t" +
                element.getUri());
    }
    return this.discoveryClient;
}

5.3.直接测试http://localhost:8001/dept/discovery
加载图片！

消费端调用方式：

在springcloud-consumer-dept-80项目 的Controller类中添加以下东西。（当前项目主启动类要加@EnableDiscoveryClient注解）

1
2
3
4
5
6
7
8
9
// 填写的是客户端主机名称
private static final String REST_URL_PREFIX = "SPRINGCLOUD-PROVID";

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

六、Eureka集群环境配置

注册中心Eureka Server 的集群，这里在本机创建3个服务器，分别配置不同的端口。

大致结构如下：
加载图片！

  1. 创建工程springcloud-eureka-7002， springcloud-eureka-7003

  2. 导入相关的依赖，并创建启动类。这里以7002工程为例。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    <!-- 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>
    1
    2
    3
    4
    5
    6
    7
    @SpringBootApplication
    @EnableEurekaServer  // Eureka服务端，即注册中心
    public class EurekaServer_7002 {
        public static void main(String[] args) {
            SpringApplication.run(EurekaServer_7003.class, args);
        }
    }

  3. 配置文件（端口号 与 关联其他 注册中心服务器）

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    server:
      port: 7002

    # Eureka配置
    eureka:
      instance:
        hostname: localhost # Eureka服务端名字
      client:
        register-with-eureka: false # 表示是否 向Eureka注册中心注册自己
        fetch-registry: false # false表示自己是注册中心（为true表示 是客户端）
        service-url: # 关联其他注册中心服务器
          defaultZone: http://localhost:7001/eureka/, http://localhost:7003/eureka/

  4. 服务提供者发布服务到三个注册中心，配置文件如下

    1
    2
    3
    4
    5
    # Eureka配置（把服务注册到哪里）
    eureka:
      client:
        service-url:
          defaultZone: http://localhost:7001/eureka/, http://localhost:7002/eureka/, http://localhost:7003/eureka/

  5. 开启服务提供者springcloud-provider-dept-8001，注册中心springcloud-eureka-7002，springcloud-eureka-7002， springcloud-eureka-7003。

  6. 打开7002服务器页面看效果：
    加载图片！

基本原理：
加载图片！
上图是来自eureka的官方架构图，这是基于集群配置的eureka；

处于不同节点的eureka通过Replicate进行数据同步

  • Application Service为服务提供者
  • Application Client为服务消费者
  • Make Remote Call完成一次服务调用

服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。

当服务注册中心Eureka Server检测到服务提供者因为宕机、网络原因不可用时，则在服务注册中心将服务置为DOWN状态，并把当前服务提供者状态向订阅者发布，订阅过的服务消费者更新本地缓存。

服务提供者在启动后，周期性（默认30秒）向Eureka Server发送心跳，以证明当前服务是可用状态。Eureka Server在一定的时间（默认90秒）未收到客户端的心跳，则认为服务宕机，注销该实例。

七、对比Zookeeper

回顾数据库原则

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好在哪？

著名的CAP理论指出，一个分布式系统不可能同时满足C（一致性）、A（可用性）、P（容错性）。

由于分区容错性P在分布式系统中是必须要保证的，因此只能在A和C之间进行权衡。

  • Zookeeper保证的是CP；
  • Eureka保证的是AP；

Zookeeper保证的是CP：

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息（可用性降低了），但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性(但是也会存在一点点延迟,毕竟需要网络传输和数据拉取处理,一般可能就几十毫秒,很短的时间)。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的(这也就是ZK的缺点之一,牺牲部分的可用性)。

Eureka保证的是AP：
Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，就算全部挂掉，服务还能通过读取本地缓存的服务列表信息来进行调用,就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)(注：前提是服务提供者的ip:port信息没有发生变化)。

除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

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

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

赏

失败是成功之母

支付宝
微信

扫一扫，分享到微信

微信分享二维码

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

JAVA<br><br>学习永不止步<br>简简单单