阿里面试官问我：到底知不知道什么是Eureka，这次，我没沉默

Posted 2021-03-29 Java学习部落

什么是服务注册？

首先我们来了解下，服务注册、服务发现和服务注册中心的之间的关系。

举个形象的例子，三者之间的关系就好像是供货商，顾客和商店。

首先各地的供货商会将各种商品提供给商店，然后顾客需要商品的时候会去商店购买。

注册中心就好比是这个商店，供货商的动作就是服务注册，商品就是注册的服务。

当部署的服务启动后，会注册到注册中心，消费者需要什么样的服务，就自己去注册中心拉取。

那么到底什么是服务注册，为什么要将服务注册到注册中心呢？

服务注册指的是服务在启动时将服务的信息注册到注册中心中，由注册中心统一对所有的注册的服务进行管理。

现在我们想想，假如你是消费者，你需要买一个商品，你可以去商店，也可以直接去供货商。

是不是就很麻烦了，倘若此时有一家商店，汇总了多家供货商的商品，那你是不是只需要去这一家商店就能购买到你需要的所有的商品了呢？

这样是不是就方便了。

在我们现实开发中，比如我们需要获取用户信息的时候，而此时，我们的用户服务只部署了一个节点，那我们就可以使用IP+端口的形式访问服务。

当此时我们的服务部署了10个节点后，我们可以通过域名访问，通过nginx转发到某一个节点上，访问该节点的服务。

使用过nginx的小伙伴们都知道，每当我们需要新增一个节点的时候，我们就需要去修改nginx的配置文件，一旦服务部署的节点过多，频繁修改配置文件就变成了一件极其麻烦的事情。

这个时候，我们的注册中心，就应该粉墨登场了。

注册中心一登场，我们就尽管部署服务节点，部署完成后，服务启动，服务的信息就会被注册到注册中心，我们就不需要担心是不是又要去修改配置文件了。

什么是服务发现？

服务发现有两种模式：一种是客户端发现模式，一种是服务端发现模式。Eureka采用的是客户端发现模式。

客户端发现模式就好比我是一个土豪顾客，我去了商店，我把所有的商品都买回家，需要的时候在这些商品里面寻找。

因为我是土豪，所以我当然不能忍受商店里有新品上架，而我却没有，所以我每隔一段时间就会商店增量获取最新的商品。

这就是Eureka中的Fetch Registry，抓取注册信息。

Eureka Client 从 Eureka Server 获取注册表信息并在本地缓存。

这里我们注意一下，Eureka Client并不是直接去服务注册表中获取数据，而是从ReadOnly缓存中获取数据。

并且会通过在上一个获取周期和当前获取周期之间获取增量更新，这些信息会定期更新(每30秒更新一次)。

获取的时候可能返回相同的实例。Eureka Client会自动处理重复信息。

因为我的土豪行为，我已经被商店老板记录在它的VVIP名单上了。可惜天有不测风云，我破产了，我再也不能这么土豪了，没办法，我告诉了老板我破产了，老板听了我的话，想都没想，直接从他的VVIP名单上将我的名字给剔除了，社会就是这么现实。

这就是Eureka中的Cancel，取消。

每一个微服务节点关闭时，Eureka Client会向Eureka Server发送一个取消请求。

Eureka Server收到你的取消请求后，就会将你从服务注册表中给剔除。

商店老板是个傲娇的人，她制定了一个规则，如果你是她VVIP名单上的人，你必须每隔一段时间就要去商店采购商品。

一旦你在一段时间内没有来采购，她就觉得你已经没有购买能力，不适合在她的VVIP名单上存在了。

她就会狠心的将你从她的VVIP名单上将我的名字给剔除了。

这就是Eureka中的Renew（更新 / 续借）

Eureka Client 内部具备一个内置的负载均衡器，它使用轮训（round-robin）负载算法。

在服务启动后，每隔一定周期（默认30秒）向Eureka Server发送心跳。

如果Eureka Server在多个心跳周期内（默认90秒）没有收到Eureka Client发送过来的心跳，Eureka Server将会在服务注册表中将该节点剔除。

什么是注册中心，注册中心的作用？

注册中心就是一个管理器，各个服务提供者将服务注册到注册中心，有注册中心进行统一的存储和管理。

注册中心同时还有着判断服务是否可用，对于不可用的服务进行剔除的功能。

至于如何判断服务的可用性和如何剔除不可用的服务，后续会有详细的讲解。

什么是 Eureka，有什么作用？

Eureka采用CS架构，它分为两大组件。

一个是Eureka Server,注册中心服务端。

当各个微服务节点启动后，Eureka Server 会存储服务提供者注册上来的服务信息，并且提供二层缓存机制来维护整个注册中心。

另一个是Eureka Client，注册中心客户端。

Eureka Client是一个java客户端，它用来简化和Eureka Server交互。

Eureka Client 会拉取、更新和缓存 Eureka Server 中的信息。

因此当所有的 Eureka Server 节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者，但是当服务有更改的时候会出现信息不一致。

Eureka 架构详解

如下图所示，这是官网提供给我们的Eureka的架构图Eureka 的架构，主要分为 Eureka Server 和 Eureka Client 两部分，Eureka Client 又分为 Applicaton Service 和 Application Client，Applicaton Service 就是服务提供者，Application Client 就是服务消费者。

我们首先会在应用程序中依赖 Eureka Client，项目启动后 Eureka Client 会向 Eureka Server 发送请求，进行注册，并将自己的一些信息发送给 Eureka Server。

注册成功后，每隔一定的时间，Eureka Client 会向 Eureka Server 发送心跳来续约服务，也就是汇报健康状态。如果客户端长时间没有续约，那么 Eureka Server 大约将在 90 秒内从服务器注册表中删除客户端的信息。

Eureka Client 还会定期从 Eureka Server 拉取注册表信息，然后根据负载均衡算法得到一个目标，并发起远程调用，关于负载均衡在后面的课时会详细介绍，也就是 Ribbon 组件。

应用停止时也会通知 Eureka Server 移除相关信息，信息成功移除后，对应的客户端会更新服务的信息，这样就不会调用已经下线的服务了，当然这个会有延迟，有可能会调用到已经失效的服务，所以在客户端会开启失败重试功能来避免这个问题。

Eureka Server 会有多个节点组成一个集群，保证高可用。Eureka Server 没有集成其他第三方存储，而是存储在内存中。

所以 Eureka Server 之间会将注册信息复制到集群中的 Eureka Server 的所有节点。

这样数据才是共享状态，任何的 Eureka Client 都可以在任何一个 Eureka Server 节点查找注册表信息。

Eureka 的工作流程

   高清图片可以添加小编微信获取。  

Eureka 的自我保护机制

什么是自我保护机制

官方定义：自我保护模式正是一种针对网络异常波动时的安全保护措施，使用自我保护模式能使Eureka集群更加健壮稳定的运行。

为什么要开启自我保护机制？

如果Eureka Server在一定时间内（默认90s）（可优化）没有收到某一个服务节点的心跳，Eureka Server将会移除该服务实例。

但是在某些时候，遇到网络分区故障，服务节点实际上是正常存货状态，但是却无法和Eureka Server正常通信，此时如果没有引入自我保护机制，Eureka Server就会将该服务节点剔除。

自我保护模式的工作机制

如果15分钟内超过85%的客户端节点都没有正常的心跳，那么Eureka Server就会认为客户端与注册中心发生了网络故障，Eureka Server进入自我保护机制。

自我保护机制的缺点

如果在自我保护机制中，刚好某些服务节点非正常下线，但是Eureka Server并不会剔除该服务节点，服务消费者就会获取到一个无效的服务实例。

解决方案

① ：关闭自我保护机制(不推荐)

② ：切换请求或断路器，使用负载均衡的方式，设置当一个请求超过多少秒还未得到响应，速度切换请求到下一个注册服务，例如使用Ribbon+Hystrix配置负载均衡和断路器。

Eureka Server 进入自我保护机制后

1、Eureka Server不在从注册表中剔除因为长时间没有和注册中心续约的服务节点

2、Eureka Server仍然能够接受新服务的注册和查询请求，但是不会同步到其他Eureka Server节点上

3、网络正常后，当前Eureka Server节点会将新的服务节点信息同步到其他Eureka Server节点上

如何开启自我保护

通过 eureka.server.enable-self-preservation=true/false 来开启或关闭自我保护机制。

其他关键配置：

清理失效服务节点的时间间隔：eureka.server.evication-interval-timer-in-ms 默认60s

续约间隔时间：eureka.instance.lease-renewal-interval-in-seconds 默认30s

续约到期时间：eureka.instance.lease-expiration-duration-in-seconds 默认90s

通过源码窥探Eureka是如何开启自我保护机制的

第一步，我们引入Eureka Server 依赖。

第二步，我们找到eureka-core jar包下的路径为com.netflix.eureka下的registry包

第三步，进入AbstractInstanceRegistry 类，找到evict方法，这个是定期剔除任务的线程最终执行的方法

public void evict(long additionalLeaseMs) { logger.debug("Running the evict task"); //判断自动保护是否开启，如果开启了自动保护， //那么剔除服务的操作就不往下执行，就不会剔除服务了 if (!this.isLeaseExpirationEnabled()) { logger.debug("DS: lease expiration is currently disabled."); } else { ... }}

第四步，我们找到isLeaseExpirationEnabled()方法的实现

public boolean isLeaseExpirationEnabled() { //首先判断是否在配置文件中关闭了自我保护，如果关闭了自我保护直接返回true， // evict方法也就可以继续往下执行，进行无用服务剔除操作 if (!this.isSelfPreservationModeEnabled()) { return true; } else { //如果开启了自我保护机制，则进一步判断是否开启自我保护机制 //numberOfRenewsPerMinThreshold(每分钟最小的续约次数)大于0 //而且getNumOfRenewsInLastMin(最后一分钟的续约次数)必须要大于每分钟最小的续约次数 //当满足上面两个条件时则说明续约正常，返回true，evict方法也就可以继续往下执行，进行无用服务剔除操作 //所以说，只有不满足上述两个条件的情况下，才会返回false，evict方法也就不在往下执行，即使有没有正常续约的服务，也不会剔除 return this.numberOfRenewsPerMinThreshold > 0 && this.getNumOfRenewsInLastMin() > (long)this.numberOfRenewsPerMinThreshold; }}

第五步，我们注意到numberOfRenewsPerMinThreshold这个变量很关键，它的含义是每分钟最小的续约次数

在服务注册register和服务下线cancel两个方法中会更新这个变量，更新该变量方法如下：

/*** 期望每分钟最小的续约次数 = 期望正常续约的服务实例数 * (60/(我们配置的发送一次心跳时间间隔（默认30秒）))*0.85* serverConfig.getRenewalPercentThreshold() 默认是 0.85 （可以通过eureka.server.renewal-percent-threshold）进行配置**/protected void updateRenewsPerMinThreshold() { this.numberOfRenewsPerMinThreshold = (int)((double)this.expectedNumberOfClientsSendingRenews * (60.0D / (double)this.serverConfig.getExpectedClientRenewalIntervalSeconds()) * this.serverConfig.getRenewalPercentThreshold());}

以上就是Eureka开启自我保护的整个逻辑流程。

解除自我保护机制

1.当服务的网络分区故障解除之后，客户端能够和服务进行交互时，在续约的时候，更新每分钟的续约数，当每分钟的续约数大于85%时，则自动解除。

2.重启服务

Eureka 的健康检查

其实很多框架的健康状态监控都是通过actuator来管理健康状态的，并且扩展了health端点。

所以说我们只要在项目中集成Actuator，我们就能管理监控项目的健康状态。

Eureka也是一样，我们可以将某些不健康的服务节点的状态告知Eureka Server，然后Eureka Server 会主动让其下线。

这个就是Eureka的健康检查。

如何实现Eureka-Actuator健康检查？

首先我们要在pom中依赖spring-boot-starter-actuator。

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> <version>2.3.3.RELEASE</version></dependency>

第二步，配置文件中添加 eureka.client.healthcheck.enabled=true 配置

原理分析：

首先在EurekaDiscoveryClientConfiguration 中根据 eureka.client.healthcheck.enabled 的值来决定是否要装配 EurekaHealthCheckHandler，然后在 EurekaClientAutoConfiguration 中会注册 HealthCheck，但我们注册完成后会有调用任务来进行状态的更新，在com.netflix.discovery.InstanceInfoReplicator.run() 中会进行状态更新。

Eureka 的多级缓存机制

什么是多级缓存机制

Eureka Server 为了避免同事读取内存数据造成的并发冲突问题，采用了多级缓存机制提升服务请求的响应速度。

Eureka Server的缓存是通过一个只读，一个读写缓存来实现的。

一级缓存：concurrentHashMap<key,value> readOnlyCacheMap 本质是HashMap，无过期时间，保存数据信息对外输出。

readOnlyCacheMap依赖于定时器的更新，通过与readWriteCacheMap的值做对比，以readWriteCacheMap为准。

responseCacheUpdateIntervalMs：readOnlyCacheMap缓存更新间隔，默认30s

二级缓存：LoaDing<key,value> readWriteCacheMap 本质是Guava缓存，包含失效机制，保护数据信息对外输出。

responseCacheAutoExpirationInSeconds：readWriteCacheMap 缓存过期时间，默认180s。

当服务节点发生注册，下线，过期，状态变更等变化时

1.在内存中更新注册表信息

2.同时过期掉readWriteCacheMap缓存，缓存清除只是会去清除readWriteCacheMap这个缓存， readOnlyCacheMap 只读 缓存并没有更新，也就说当客户端的信息发生变化之后， 只读缓存不是第一时间感知到的。只读缓存的更新只能依赖那个30秒的定时任务来更新。

3.一段时间后（默认30s），后台线程发现readWriteCacheMap缓存为空，于是也将readOnlyCacheMap中的缓存清空

4.当有服务消费者拉取注册表信息时，会调用ClassLoader的load方法，将内存中的注册表信息加载到各级缓存中，并返回注册表信息。

在Eureka Server 中会有两个线程，一个是定时同步两个缓存的数据，默认30s，一个是定时检测心跳故障，默认90s。

服务拉取

1.服务消费者，默认每30s，拉取注册表信息

2.从readOnlyCacheMap中获取信息，如果获取为空

3.从readWriteCacheMap中获取，如果还是为空

4.调用ClassLoader的load方法，将内存中的注册表信息加载到各级缓存中，并返回注册表信息。

Eureka的区域配置

当用户地理分布范围很广的时候，比如公司在上海、杭州、青岛等都有分公司的时候，一般都会有多个机房。

那么对于用户而言，当然是希望调用本地分公司的机房中的微服务应用。

比如：上海用户A，调用OAuth2服务，用户A当然希望调用上海机房里面的微服务应用。如果上海用户A调用杭州机房的OAuth2服务，就增加的延时时间。

所以我们希望一个机房内的服务优先调用同一个机房内的服务，当同一个机房的服务不可用的时候，再去调用其它机房的服务，以达到减少延时的作用。

为此，eureka提供了region和zone两个概念来进行分区，Eureka基于Amazon设计的，所以对于地域的区分也与Amazon一致，Amazon分为多个region，每个region包含多个zone，所以Eureka设计时也是可以设置region与zone，请求时可以优先选择与请求服务在同一个zone的服务。

基本配置

eureka: client: region: shanghai availability-zones: shanghai: zone1, zone2 service-url: zone1: http://localhost:8081/eureka, http://localhost:8082/eureka zone2: http://localhost:8083/eureka, http://localhost:8084/eureka instance: metadata-map: zone: zone1

此时无论我们调用多少次，调用的都是shanghai下面的zone1下面的服务。

一般来说我们都会结合Ribbon来实现微服务的负载均衡，而Ribbon内部会有一些专门的负载策略算法，虽然刚刚我们说过会优先请求的是指定region下指定 Zone 区域的服务实例。

但有些时候比如当在Region=shanghai下没有可用的zone，系统会默认加载 DEFAULT_ZONE，或者说活着同区域的服务负载过高...等等，也会自动切换成其他区域的服务。

Eureka的重试机制

由于 Spring Cloud Eureka 实现的服务治理机制强调了 CAP 原理中的 AP，即可用性与可靠性，牺牲了一定的一致性（在极端情况下它宁愿接受故障实例也不要丢掉"健康"实例，如同如我们上面所说的自我保护机制）。

但不论是由于触发了保护机制还是服务剔除的延迟，引起服务调用到这些不正常的服务，调用就会失败，从而导致其它服务不能正常工作！

这显然不是我们愿意看到的，我们还是希望能够增强对这类问题的容错。所以，我们在实现服务调用的时候通常会加入一些重试机制。

从 Camden SR2 版本开始，Spring Cloud 就整合了 Spring Retry 来增强 RestTemplate 的重试能力，对于开发者来说只需通过简单的配置，原来那些通过 RestTemplate 实现的服务访问就会自动根据配置来实现重试策略。

开启Eureka的重试机制很简单，首先我们在pom中引入Spring Retry的依赖：

<dependency> <groupId>org.springframework.retry</groupId> <artifactId>spring-retry</artifactId></dependency>

然后在配置文件中配置spring.cloud.loadbalancer.retry.enabled参数来控制重试机制的开关，因为 Spring Retry默认是开启的，所以说我们只要引入依赖即可，如果说我们想要关闭的话只需要将 spring.cloud.loadbalancer.retry.enabled设置为false即可。

其实在SpringCloud的架构组件中无论是Fegin，Ribbon，还是Zuul都提供了重试机制，这些暂且不论，后续再讲到具体的组件时再进行具体的分析。

实战 Eureka 注册中心的部署

Eureka Server 项目搭建

1、创建一个 springcloud-eureka-server 的项目，然后在 pom 中增加 spring-cloud-starter-netflix-eureka-server 的依赖。

2.在pom.xml文件中新增spring-cloud-starter-netflix-eureka-server依赖

<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId></dependency>

3.在启动类SpringcloudEurekaServerApplication上使用 @EnableEurekaServer 开启 EurekaServer 的自动装配功能。

@SpringBootApplication@EnableEurekaServerpublic class SpringcloudEurekaServerApplication {  public static void main(String[] args){ SpringApplication.run(SpringcloudEurekaServerApplication.class, args); }}

4.添加配置文件application.properties

# server (eureka 默认端口为：8761)server.port=8761# springspring.application.name=spring-cloud-eureka-server# eureka# 是否注册到eurekaeureka.client.register-with-eureka=false# 是否从eureka获取注册信息eureka.client.fetch-registry=false# eureka服务器的地址（注意：地址最后面的 /eureka/ 这个是固定值）eureka.client.serviceUrl.defaultZone=http://localhost:${server.port}/eureka/

5.启动项目，然后访问http://localhost:8761/ ,可以看到 Eureka 的管理页面，表示 Eureka 启动成功了。

Eureka Client 项目搭建

1、创建一个 springcloud-eureka-client 的项目，然后在 pom 中增加 spring-cloud-starter-netflix-eureka-client 的依赖。

<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId></dependency>

2.在启动类SpringcloudEurekaClientApplication上使用 @EnableEurekaClient 开启 EurekaServer 的自动装配功能。

@SpringBootApplication@EnableEurekaClientpublic class SpringcloudEurekaClientApplication {public static void main(String[] args){ SpringApplication.run(SpringcloudEurekaClientApplication.class, args); }}

server.port=8762spring.application.name=spring-cloud-eureka-clienteureka.client.serviceUrl.defaultZoon=http://localhost:8761/eureka/

启动客户端，然后刷新刚刚打开的Eureka主页，我们发现服务已经注册成功。

Eureka 注册中心添加密码认证

上面我们看到我们搭建好Eureka Server 后访问http://localhost:8761/ ,没有登陆就可以直接看到 Eureka 的管理页面。

首先，在 pom.xml 中引入 Spring-Security 的依赖

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId></dependency>

然后在 application.properties 中加上认证的配置信息

spring.security.user.name=javaer123456 #用户名 spring.security.user.password=123456 #密码

最后增加Spring Security 配置类

@Configuration @EnableWebSecurity public class WebSecurityConfig extends WebSecurityConfigurerAdapter { @Override  protected void configure(HttpSecurity http) throws Exception {  // 关闭 Spring Security 的 CSRF 验证（如果不关闭，那么客户端就连接不上）  http.csrf().disable();  // 支持httpBasic  http.authorizeRequests().anyRequest().authenticated().and().httpBasic();  }}

这样我们启动Eureka Server成功后在访问 http://localhost:8761/，此时浏览器会提示你输入用户名和密码，输入正确后才能继续访问 Eureka 提供的管理页面。

注意：在 Eureka Server开启认证后，Eureka Client注册的配置也要加上认证的用户名和密码信息

eureka.client.serviceUrl.defaultZone=http://javaer23456:123456@localhost:8761/eureka/

总结

本章我们主要学习了Eureka相关知识，虽然Eureka已经停更了，但是很多公司还在使用它，而它也足够稳定，它所提供的功能也足够大多数公司使用。所以说现在面试中，Eureka相关题目还是经常出现的。反正学到了就是自己的。

祝愿大家早日成为大牛，有一头乌黑秀发的大牛。

‍原创不易，如果大家喜欢，赏个三连吧。和大家一起成为这世界上最优秀的人。‍

福利时刻