【面试题 - springcloud】 - 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