投稿
  1. 首页
  2. java

SpringCloud-Eureka服务注册与发现、Eureka与Zookeeper的区别、自我保护机制、集群环境配置

code • 2022-5-13 • java • 阅读 48

SpringCloud-Eureka服务注册与发现、Eureka与Zookeeper的区别、自我保护机制、集群环境配置,第1张

SpringCloud-Eureka服务注册与发现
  • 前言
    • 什么是Eureka
    • 两大组件
    • 三大角色
  • Eureka注册中心
    • 创建Eureka
    • 导包
    • 编写配置文件
    • 编写一个主启动类
    • 启动
  • 将服务注册进注册中心
    • 在服务提供者中导入相关依赖
    • 配置文件
    • 启动类配置
    • 注册中心查看
    • 配置监控信息
      • 导入依赖
      • 在配置文件中配置描述
    • 通过请求获取服务信息（服务发现）（拓展）
  • Eureka自我保护机制
    • 关闭自我保护机制（不建议关闭）
    • 微服务修改减短服务心跳的时间
  • 集群环境配置
    • 创建多个注册中心
    • 设置关联
    • 总结
  • CAP原则以及对比ZooKeeper（面试高频）
    • 什么是ACID
    • 什么是CAP
    • 对比Zookeeper

前言 什么是Eureka

它是作为服务注册与发现的，这个Zookeeper相似，但是Zookeeper有一个客户端，但是Eureka是基于CS架构的，遵循AP原则，基于REST的服务，通过Eureka Server作为服务注册的服务器。
我们上一个项目消费者是直接从提供者手中拿到服务的，这是不符合逻辑的，应该从注册中心中获取服务。

替换成：

系统中的微服务，使用Eureka客户端连接到EurekaServer并维持心跳连接，通过EurekaServer来监控各个微服务是否正常运行。

简单来说，就是消费者和提供者都会去连接注册中心，并产生心跳，注册中心会监控彼此有没有心跳，是不是服务宕机了。

两大组件

Eureka Server和Eureka Client 遵循CS架构

  • Eureka Server
    提供服务注册
  • Eureka Client
    简化交互，向Eureka Server发送心跳（默认周期30s），如果在多个心跳周期中没有接收到心跳，Eureka Server将会从服务注册表中把这个服务节点移除
三大角色
  • Eureka Server：提供服务的注册与发现
  • Server Provider：将自身服务注册到 Eureka
  • Server Consumer：服务消费方从Eureka中获取注册服务列表，从而找到消费服务。
Eureka注册中心

Eureka与Zookeeper不同，Eureka是需要手动创建注册中心的，而Zookeeper自己本身就有注册中心，启动即可。

创建Eureka

我们在Idea中创建一个基本的Maven项目——springcloud-eureka，在这里写我们的注册中心

导包 
  <!--导包-->
    <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>
        </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/
编写一个主启动类


EurekaServer_7001：

package com.cjh.springcloud;

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

@SpringBootApplication
@EnableEurekaServer  //表示它是一个服务端的启动类，它可以接收别人注册进来
public class EurekaServer_7001 {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServer_7001.class,args);
    }
}

我们只需要加入@EnableEurekaServer这一个注解即可。

启动


这就是Eureka默认的注册中心页面。
接下来，就是把我们的服务注册进注册中心

将服务注册进注册中心

我们已经写好了我们的注册中心了，接下来就是把服务提供者注册进注册中心中，以便于我们消费者从注册中心拿到服务。

在服务提供者中导入相关依赖

配置文件 
#eureka的配置,服务注册到哪里
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka/
启动类配置 
package com.cjh.springcloud;

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

//启动类
@SpringBootApplication
@EnableEurekaClient //在服务启动后，自动注册到Eureka中
public class DeptProvider_8081{
    public static void main(String[] args) {
        SpringApplication.run(DeptProvider_8081.class,args);
    }

}

只需要加入一个注解@EnableEurekaClient在服务启动后，自动注册到Eureka中

注册中心查看


我们可以发现，当我们的服务提供者启动之后，在注册中心可以看到已经注册进来了。
当然你也可以修改它的默认描述：


#eureka的配置,服务注册到哪里
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka/
  instance:
    instance-id: springcloud-provider-dept8001 #修改默认描述

当服务断了怎么办，eureka会触发自我保护机制

这就说明有服务断了

配置监控信息

当我们启动服务后，在注册中心可以看到我们的服务，并且在我们的注册中心可以看到状态有一个服务链接，这里是我们的监控信息

点击可以跳转到监控信息页面
那么我们如何配置监控信息呢？

导入依赖 
   <!--添加监控信息-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
在配置文件中配置描述

在application.yml中添加描述

#监控信息
info:
  app.name: caicai
  company.name: caicai-study

这样就可以查看到描述了，这些描述是以Json格式返回的。

通过请求获取服务信息（服务发现）（拓展）

这个功能在企业中用的比较多
我们在提供者中controller中写一个方法


    //获取一些配置信息，得到具体的微服务！
    @Autowired
    private DiscoveryClient client;

@GetMapping("/dept/discovery")
    //从注册进来的微服务获取一些信息
    public Object discovery(){
        //获取微服务列表的清单
        List<String> services = client.getServices();
        System.out.println(services);

        //得到一个具体的微服务信息,通过具体的微服务id
        List<ServiceInstance> instances = client.getInstances("SPRINGCLOUD-PROVIDER-DEPT");
        for (ServiceInstance instance : instances) {
            System.out.println(instance.getHost()+"\t"
                    +instance.getPort()+"\t"+
                    instance.getUri()+"\t"+
                    instance.getInstanceId()
            );
        }

        return this.client;
    }

然后在启动类中添加注解@EnableDiscoveryClient，启动功能。

package com.cjh.springcloud;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;

//启动类
@SpringBootApplication
@EnableEurekaClient //在服务启动后，自动注册到Eureka中
@EnableDiscoveryClient //服务发现
public class DeptProvider_8081{
    public static void main(String[] args) {
        SpringApplication.run(DeptProvider_8081.class,args);
    }

}

这样通过访问链接就可以查看到所有的微服务信息了。
在企业中很少通过配置文件去描述信息，而且信息也比较少，所以一般微服务比较多的时候，就通过服务发现，来获取微服务的信息。

Eureka自我保护机制

这样做的目的是eureka担心这个服务注册中心是不是死掉了，而做出的一种保护机制。但是当该微服务又重新活过来了之后，Eureka会将之前保存的信息还原到该微服务上。

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

  • Eureka Server不会立刻从注册列表中移除因为长时间没收到心跳而应该过期的服务。
  • Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可用。
  • 当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。
  • 因此Eureka Server可以很好的应对因网络故障导致部分节点失联的情况，而不会像ZK那样如果有一半不可用的情况会导致整个集群不可用而变成瘫痪。

一句话：好死不如赖活着

宁可同时保留所有微服务，也不盲目注销任何健康的微服务。

关闭自我保护机制（不建议关闭）

注册中心关闭自我保护机制，修改检查失效服务的时间

eureka:
  server:
     enable-self-preservation: false
     eviction-interval-timer-in-ms: 3000
微服务修改减短服务心跳的时间 
# 默认90秒
lease-expiration-duration-in-seconds:  10

# 默认30秒
lease-renewal-interval-in-seconds:  3
集群环境配置

我们目前只有一个注册中心，在企业中，肯定不仅仅只有一个注册中心，因此多个注册中心就有集群这个概念的提出
我们现在模拟搭建多个注册中心来组成集群。

创建多个注册中心


配置都是相同的，只需要修改端口号即可。

我们现在只是创建了多个注册中心，要想集群，需要都彼此都配置上对方。

这样就可以避免一个注册中心宕机影响全部服务的崩溃。

设置关联

我们分别在application.yml 中配置对方的地址，其他的都一样。

server:
  port: 7003

# Eureka配置
eureka:
  instance:
    hostname: localhost #Eureka服务端的实例名称
  client:
    register-with-eureka: false # 表示是否向eureka注册中心注册自己，我们这里是服务器，不用注册自己
    fetch-registry: false    #如果为false 则表示自己为注册中心
    service-url:  # 监控页面
      defaultZone: http://${eureka.instance.hostname}:7001/eureka/,http://${eureka.instance.hostname}:7002/eureka/

然后分别启动即可。
这个时候你会发现，可以看到集群，都会挂载到对方。

总结

我们主要是理解集群的思想，我们集群是为了避免一个注册中心宕机造成服务的崩溃，集群之后，一个注册中心宕机还有其他注册中心提供服务，不影响业务的正常进行。

CAP原则以及对比ZooKeeper（面试高频）

我们的消费者还是一样通过REST去获取服务即可，没有任何影响。

什么是ACID
  • A（Atomicity） 原子性
  • C（Consistency）一致性
  • I（Isolation） 隔离性
  • D（Durability） 持久性
    （Mysql、Oracle、sqlServer）
什么是CAP
  • C （Consistency）强一致性
  • A（Avaliability）可用性
  • P （Partition tolerance）分区容错性
    我们CAP原则只能三进二，要么CP、AP、CA原则，不能同时满足CAP原则
    （Redis、Mongdb）

Eureka和Zookeeper是满足CAP原则的，Eureka保证的是AP，Zookeeper保证的CP，都允许有容错性。

对比Zookeeper
  • Zookeeper保证CP

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

  • Eureka保证AP

Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

Eureka不会从注册列表中移除因为长时间没收到心跳而应该过期的服务

Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)

当网络稳定时，当前实例新的注册信息会被同步到其它节点中

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

欢迎分享，转载请注明来源：内存溢出

原文地址: http://outofmemory.cn/langs/872298.html

赞 (0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
code code 管理员组
0 0
上一篇 2022-05-13
下一篇 2022-05-13

发表评论

登录后才能评论

评论列表（0条）

保存