当前位置:   article > 正文

【面试题 - springcloud】 - Eureka服务注册中心_eureka面试题

eureka面试题

1. Eureka服务注册中心

Eureka注册中心,负责服务的注册与发现。

1.1 两大组件(Eureka Server 和 Eureka Client)

Eureka Client:负责将当前服务的信息注册到Eureka Server中。
Eureka Server:注册中心,里面有一个注册表,保存了各个服务所在的机器和端口号(各个节点启动后,会在EurekaServer中进行注册)

在这里插入图片描述
在应用启动后,将会向EurekaServer发送心跳 (默认周期为30秒) 。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳,EurekaServer将会从服务注册表中把这个服务节点移除掉 (默认周期为90s)。

1.2 三大角色(注册中心,服务提供者,服务消费者)

Eureka Server:提供服务的注册与发现
Service Provider:服务生产方,将自身服务注册到Eureka中,从而使服务消费方能找到
Service Consumer:服务消费方,从Eureka中获取注册服务列表,从而找到消费服务(自己也会注册到Eureka Server,因为消费方也有可能是提供方)

1.3 面试题

1.3.1 消费者如何获取提供者信息?

服务提供者启动的时候会向eureka注册自己的信息
eureka保存这些信息
消费者根据服务者名称向eureka拉取提供者信息

1.3.2 如果有多个提供者,消费者如何选择

消费者根据负载均衡算法从服务列表选出一个

1.3.3 消费者如何感知提供者健康状态

服务提供者每隔30秒会像EurekaServer发送心跳请求
eureka会更新服务列表信息,90秒内心跳不正常会被剔除(默认90秒)
消费者拉取最新数据(不包含被剔除的地址)

2. Eureka配置

2.1 搭建EurekaServer

在这里插入图片描述

2.2 服务注册

在这里插入图片描述

2.3 服务发现

在这里插入图片描述

3. EureKa自我保护机制

  • 某时刻某一个微服务不可用,eureka不会立即清理,依旧会对该微服务的信息进行保存!
  • 默认情况下,当eureka server在一定时间内没有收到实例的心跳,便会把该实例从注册表中删除(默认是90秒),但是,如果短时间内丢失大量的实例心跳,便会触发eureka server的自我保护机制。
  • Eureka服务端会检查最近15分钟内所有Eureka 实例正常心跳占比,如果低于85%就会触发自我保护机制。触发了保护机制,Eureka将暂时把这些失效的服务保护起来,不让其过期,但这些服务也并不是永远不会过期。Eureka在启动完成后,每隔60秒会检查一次服务健康状态,如果这些被保护起来失效的服务过一段时间后(默认90秒)还是没有恢复,就会把这些服务剔除。如果在此期间服务恢复了并且实例心跳占比高于85%时,就会自动关闭自我保护机制。

3.1 为什么会有自我保护机制?

Eureka服务端为了防止Eureka客户端本身是可以正常访问的,但是由于网路通信故障等原因,造成Eureka服务端失去于客户端的连接,从而形成的不可用。
因为网络通信是可能恢复的,但是Eureka客户端只会在启动时才去服务端注册。如果因为网络的原因而剔除了客户端,将造成客户端无法再注册到服务端。

3.2 如何选择关闭还是开启

Eureka服务端默认情况下是会开启自我保护机制的。但我们在不同环境应该选择是否开启保护机制。

一般情况下,我们会选择在 开发环境下关闭自我保护机制,而在生产环境下启动自我保护机制。

开发环境下,我们我们启动的服务数量较少而且会经常修改重启。如果开启自我保护机制,很容易触发Eureka客户端心跳占比低于85%的情况。使得Eureka不会剔除我们的服务,从而在我们访问的时候,会访问到可能已经失效的服务,导致请求失败,影响我们的开发。
在生产环境下,我们启动的服务多且不会反复启动修改。环境也相对稳定,影响服务正常运行的人为情况较少。适合开启自我保护机制,让Eureka进行管理。

4. 对比zk(CAP)

4.1 CAP是什么?

C (Consistency) 强一致性
A (Availability) 可用性
P (Partition tolerance) 分区容错性

4.2 对比zk

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

  • Zookeeper 保证的是 CP —> 满足一致性,分区容错的系统,通常性能不是特别高
  • Eureka 保证的是 AP —> 满足可用性,分区容错的系统,通常可能对一致性要求低一些

4.3 ZK保证CP

当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30-120s,且选举期间整个zookeeper集群是不可用的,这就导致在选举期间注册服务瘫痪,漫长的选举时间导致注册长期不可用。

4.4 Eureka保证AP

Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时,如果发现连接失败,则会自动切换至其他节点,只要有一台Eureka还在,就能保住注册服务的可用性,只不过查到的信息可能不是最新的。

来源:https://www.kuangstudy.com/bbs/1374942542566551554
https://www.bilibili.com/video/BV1LQ4y127n4?p=13&vd_source=b901ef0e9ed712b24882863596eab0ca

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/神奇cpp/article/detail/890509
推荐阅读
相关标签
  

闽ICP备14008679号