「javaeureka」javaeureka面试题

今天给各位分享javaeureka的知识，其中也会对javaeureka面试题进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、Eureka工作原理
• 2、Eureka官方教程（一） Eureka一览
• 3、如何启动eureka服务
• 4、eureka 只支持java吗
• 5、字节三面：到底知不知道什么是Eureka？

Eureka工作原理

Eureka 作为 Spring Cloud 体系中最核心、默认的注册中心组件，研究它的运行机制，有助于我们在工作中更好地使用它。

回到上节的服务注册调用示意图，服务提供者和服务的消费者，本质上也是 Eureka Client 角色。整体上可以分为两个主体：Eureka Server 和 Eureka Client。

Eureka Server：注册中心服务端

注册中心服务端主要对外提供了三个功能：

服务注册 服务提供者启动时，会通过 Eureka Client 向 Eureka Server 注册信息，Eureka Server 会存储该服务的信息，Eureka Server 内部有二层缓存机制来维护整个注册表

提供注册表 服务消费者在调用服务时，如果 Eureka Client 没有缓存注册表的话，会从 Eureka Server 获取最新的注册表

同步状态 Eureka Client 通过注册、心跳机制和 Eureka Server 同步当前客户端的状态。

Eureka Client：注册中心客户端 Eureka Client 是一个 Java 客户端，用于简化与 Eureka Server 的交互。Eureka Client 会拉取、更新和缓存 Eureka Server 中的信息。因此当所有的 Eureka Server 节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者，但是当服务有更改的时候会出现信息不一致。

Register: 服务注册 服务的提供者，将自身注册到注册中心，服务提供者也是一个 Eureka Client。当 Eureka Client 向 Eureka Server 注册时，它提供自身的元数据，比如 IP 地址、端口，运行状况指示符 URL，主页等。

Renew: 服务续约 Eureka Client 会每隔 30 秒发送一次心跳来续约。 通过续约来告知 Eureka Server 该 Eureka Client 运行正常，没有出现问题。 默认情况下，如果 Eureka Server 在 90 秒内没有收到 Eureka Client 的续约，Server 端会将实例从其注册表中删除，此时间可配置，一般情况不建议更改。

服务续约的两个重要属性

Eviction 服务剔除 当 Eureka Client 和 Eureka Server 不再有心跳时，Eureka Server 会将该服务实例从服务注册列表中删除，即服务剔除。

Cancel: 服务下线 Eureka Client 在程序关闭时向 Eureka Server 发送取消请求。 发送请求后，该客户端实例信息将从 Eureka Server 的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容：

GetRegisty: 获取注册列表信息 Eureka Client 从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与 Eureka Client 的缓存信息不同，Eureka Client 自动处理。

如果由于某种原因导致注册列表信息不能及时匹配，Eureka Client 则会重新获取整个注册表信息。 Eureka Server 缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka Client 和 Eureka Server 可以使用 JSON/XML 格式进行通讯。在默认情况下 Eureka Client 使用压缩 JSON 格式来获取注册列表的信息。

获取服务是服务消费者的基础，所以必有两个重要参数需要注意：

Remote Call: 远程调用 当 Eureka Client 从注册中心获取到服务提供者信息后，就可以通过 Http 请求调用对应的服务；服务提供者有多个时，Eureka Client 客户端会通过 Ribbon 自动进行负载均衡。

默认情况下，如果 Eureka Server 在一定的 90s 内没有接收到某个微服务实例的心跳，会注销该实例。但是在微服务架构下服务之间通常都是跨进程调用，网络通信往往会面临着各种问题，比如微服务状态正常，网络分区故障，导致此实例被注销。

固定时间内大量实例被注销，可能会严重威胁整个微服务架构的可用性。为了解决这个问题，Eureka 开发了自我保护机制，那么什么是自我保护机制呢？

Eureka Server 在运行期间会去统计心跳失败比例在 15 分钟之内是否低于 85%，如果低于 85%，Eureka Server 即会进入自我保护机制。

Eureka Server 触发自我保护机制后，页面会出现提示：

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

Eureka 自我保护机制是为了防止误杀服务而提供的一个机制。当个别客户端出现心跳失联时，则认为是客户端的问题，剔除掉客户端；当 Eureka 捕获到大量的心跳失败时，则认为可能是网络问题，进入自我保护机制；当客户端心跳恢复时，Eureka 会自动退出自我保护机制。

如果在保护期内刚好这个服务提供者非正常下线了，此时服务消费者就会拿到一个无效的服务实例，即会调用失败。对于这个问题需要服务消费者端要有一些容错机制，如重试，断路器等。

通过在 Eureka Server 配置如下参数，开启或者关闭保护机制，生产环境建议打开：

再来看看 Eureka 集群的工作原理。我们假设有三台 Eureka Server 组成的集群，第一台 Eureka Server 在北京机房，另外两台 Eureka Server 在深圳和西安机房。这样三台 Eureka Server 就组建成了一个跨区域的高可用集群，只要三个地方的任意一个机房不出现问题，都不会影响整个架构的稳定性。

从图中可以看出 Eureka Server 集群相互之间通过 Replicate 来同步数据，相互之间不区分主节点和从节点，所有的节点都是平等的。在这种架构中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。

如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点。当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会进行节点间复制，将请求复制到其它 Eureka Server 当前所知的所有节点中。

另外 Eureka Server 的同步遵循着一个非常简单的原则：只要有一条边将节点连接，就可以进行信息传播与同步。所以，如果存在多个节点，只需要将节点之间两两连接起来形成通路，那么其它注册中心都可以共享信息。每个 Eureka Server 同时也是 Eureka Client，多个 Eureka Server 之间通过 P2P 的方式完成服务注册表的同步。

Eureka Server 集群之间的状态是采用异步方式同步的，所以不保证节点间的状态一定是一致的，不过基本能保证最终状态是一致的。

Eureka 分区 Eureka 提供了 Region 和 Zone 两个概念来进行分区，这两个概念均来自于亚马逊的 AWS: region ：可以理解为地理上的不同区域，比如亚洲地区，中国区或者深圳等等。没有具体大小的限制。根据项目具体的情况，可以自行合理划分 region。 zone ：可以简单理解为 region 内的具体机房，比如说 region 划分为深圳，然后深圳有两个机房，就可以在此 region 之下划分出 zone1、zone2 两个 zone。

上图中的 us-east-1c、us-east-1d、us-east-1e 就代表了不同的 Zone。Zone 内的 Eureka Client 优先和 Zone 内的 Eureka Server 进行心跳同步，同样调用端优先在 Zone 内的 Eureka Server 获取服务列表，当 Zone 内的 Eureka Server 挂掉之后，才会从别的 Zone 中获取信息。

Eurka 保证 AP

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

了解完 Eureka 核心概念，自我保护机制，以及集群内的工作原理后，我们来整体梳理一下 Eureka 的工作流程：

1、Eureka Server 启动成功，等待服务端注册。在启动过程中如果配置了集群，集群之间定时通过 Replicate 同步注册表，每个 Eureka Server 都存在独立完整的服务注册表信息

2、Eureka Client 启动时根据配置的 Eureka Server 地址去注册中心注册服务

3、Eureka Client 会每 30s 向 Eureka Server 发送一次心跳请求，证明客户端服务正常

4、当 Eureka Server 90s 内没有收到 Eureka Client 的心跳，注册中心则认为该节点失效，会注销该实例

5、单位时间内 Eureka Server 统计到有大量的 Eureka Client 没有上送心跳，则认为可能为网络异常，进入自我保护机制，不再剔除没有上送心跳的客户端

6、当 Eureka Client 心跳请求恢复正常之后，Eureka Server 自动退出自我保护模式

7、Eureka Client 定时全量或者增量从注册中心获取服务注册表，并且将获取到的信息缓存到本地

8、服务调用时，Eureka Client 会先从本地缓存找寻调取的服务。如果获取不到，先从注册中心刷新注册表，再同步到本地缓存

9、Eureka Client 获取到目标服务器信息，发起服务调用

10、Eureka Client 程序关闭时向 Eureka Server 发送取消请求，Eureka Server 将实例从注册表中删除

这就是Eurka基本工作流程

讲了 Eureka 核心概念、Eureka 自我保护机制和 Eureka 集群原理。通过分析 Eureka 工作原理，我可以明显地感觉到 Eureka 的设计之巧妙，通过一些列的机制，完美地解决了注册中心的稳定性和高可用性。

Eureka 为了保障注册中心的高可用性，容忍了数据的非强一致性，服务节点间的数据可能不一致， Client-Server 间的数据可能不一致。比较适合跨越多机房、对注册中心服务可用性要求较高的使用场景。

Eureka官方教程（一） Eureka一览

Eureka官方教程（一） Eureka一览

Eureka官方教程（二） 配置Eureka

Eureka官方教程（三） Eureka客户端服务器通信

Eureka官方教程（四） 自我保护模式

Eureka官方教程（五） Eureka REST操作

Eureka是一种基于REST（Representational State Transfer）的服务，主要用于AWS云，用于定位服务，以实现中间层服务器的负载平衡和故障转移。我们将此服务称为Eureka Server。Eureka还附带了一个基于Java的客户端组件Eureka Client，它使与服务的交互变得更加容易。客户端还有一个内置的负载均衡器，可以进行基本的循环负载均衡。在Netflix，一个更复杂的负载均衡器包含Eureka基于流量，资源使用，错误条件等多种因素提供加权负载平衡，以提供卓越的弹性。

在AWS云中，由于其固有的特性，服务器来来去去。与使用具有众所周知的IP地址和主机名的服务器的传统负载均衡器不同，在AWS中，负载均衡在使用负载均衡器注册和取消注册服务器时需要更加复杂。由于AWS尚未提供中间层负载均衡器，因此Eureka填补了中间层负载均衡领域的巨大空白。

AWS Elastic Load Balancer是面向最终用户Web流量的边缘服务的负载平衡解决方案。Eureka满足了中层负载平衡的需求。虽然理论上您可以将您的中间层服务置于AWS ELB之后，但在EC2 classic中，您会将它们暴露给外部世界，从而失去AWS安全组的所有实用性。

AWS ELB也是传统的基于代理的负载平衡解决方案，而使用Eureka则不同之处在于负载平衡发生在实例/服务器/主机级别。客户端实例知道他们需要与哪些服务器通信的所有信息。这是一种祝福或诅咒，取决于你看待它的方式。如果您正在寻找AWS现在提供的基于粘性用户会话的负载平衡，Eureka不提供开箱即用的解决方案。在Netflix，我们更喜欢我们的服务是无状态（非粘性）。这有助于实现更好的可扩展性模型，Eureka非常适合解决这个问题。

使用Eureka将基于代理的负载平衡与负载平衡区分开来的另一个重要方面是，您的应用程序可以适应负载均衡器的中断，因为有关可用服务器的信息会缓存在客户端上。这确实需要少量内存，但可以获得更好的弹性。

Route 53是一个命名服务，Eureka可以为中间层服务器提供相同的服务，但相似性在那里停止。Route 53是一种DNS服务，即使对于非AWS数据中心，它也可以托管您的DNS记录。Route 53还可以跨AWS区域执行基于延迟的路由。Eureka类似于内部DNS，与世界各地的DNS服务器无关。Eureka也是区域隔离的，因为它不了解其他AWS区域中的服务器。保存信息的主要目的是在区域内进行负载平衡。

虽然您可以使用Route 53注册中间层服务器并依赖AWS安全组来保护您的服务器免受公共访问，但您的中间层服务器身份仍然会暴露给外部世界。它还具有传统的基于DNS的负载平衡解决方案的缺点，其中流量仍然可以路由到可能不健康或甚至不存在的服务器（在AWS云的情况下，服务器可以随时消失）。

您通常在AWS云中运行，并且您有许多中间层服务，您不希望向AWS ELB注册或暴露来自外部世界的流量。您要么寻找一个简单的循环负载平衡解决方案，要么愿意根据您的负载平衡需求在Eureka周围编写自己的包装器。您不需要粘性会话并在外部缓存（例如memcached）中加载会话数据。更重要的是，如果您的架构适合基于客户端的负载均衡器的模型，Eureka可以很好地适应这种用途。

如何启动eureka服务

使用Eureka做服务发现

Zookeeper做注册中心的缺陷

Peter Kelley(个性化教育初创公司Knewton的一名软件工程师)发表了一篇文章说明为什么ZooKeeper用于服务发现是一个错误的做法，他主要提出了三个缺点[1]：

ZooKeeper无法很好的处理网络分区问题，当网络分区中的客户端节点无法到达Quorum时，会与ZooKeeper失去联系，从而也就无法使用其服务发现机制。

服务发现系统应该是一个AP系统，设计上针对可用性；而ZooKeeper是一个CP系统。

ZooKeeper的设置和维护非常困难，实际操作的时候也容易出错，比如在客户端重建Watcher，处理Session和异常的时候。

当然，Peter Kelley提出的这几个问题并不是不能克服的，并不能说明基于ZooKeeper就不能做好一个服务发现系统，但是我们可能有更简洁的方案来实现。

Eureka介绍

什么是Eureka

官方的介绍在这里Eureka wiki。Eureka是Netflix开源的一个RESTful服务，主要用于服务的注册发现。Eureka由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。Netflix在其生产环境中使用的是另外的客户端，它提供基于流量、资源利用率以及出错状态的加权负载均衡。

在我看来，Eureka的吸引力来源于以下几点：

开源：大家可以对实现一探究竟，甚至修改源码。

可靠：经过Netflix多年的生产环境考验，使用应该比较靠谱省心

功能齐全：不但提供了完整的注册发现服务，还有Ribbon等可以配合使用的服务。

基于Java：对于Java程序员来说，使用起来，心里比较有底。

spring cloud可以使用Spring Cloud, 与Eureka进行了很好的集成，使用起来非常方便。

Eureka架构

Netflix主要是在AWS中使用Eureka的，虽然同时也支持本地环境，但是了解AWS的一些基础概念对于理解Eureka的设计非常有帮助。

eureka 只支持java吗

Eureka，它是一个RESTful服务，用来定位运行在AWS域（Region）中的中间层服务。

Eureka由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。

目前Netflix只提供了java客户端。因为使用的是http协议，如果您要用其他语言来同服务器交互，你完全可以根据服务器提供的接口基于http自行实现一个客户端。

字节三面：到底知不知道什么是Eureka？

什么是服务注册？

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

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

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

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

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

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

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

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

但是如果今天你要买很多商品，而且我们并不知道每个商品对应的供应商的地址，那么你就得挨家挨户的去跑供货商购买商品。

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

这样是不是就方便了。

在我们现实开发中，比如我们需要获取用户信息的时候，而此时，我们的用户服务只部署了一个节点，那我们就可以使用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方法，这个是定期剔除任务的线程最终执行的方法

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

第五步，我们注意到

numberOfRenewsPerMinThreshold这个变量很关键，它的含义是每分钟最小的续约次数

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

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

解除自我保护机制

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

2.重启服务

Eureka 的健康检查

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

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

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

这个就是Eureka的健康检查。

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

首先我们要在pom中依赖

spring-boot-starter-actuator。

第二步，配置文件中添加

eureka.client.healthcheck.enabled=true 配置

原理分析：

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

Eureka 的多级缓存机制

什么是多级缓存机制

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

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

一级缓存：concurrentHashMapkey,valuereadOnlyCacheMap本质是HashMap，无过期时间，保存数据信息对外输出。

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

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

二级缓存：LoaDingkey,valuereadWriteCacheMap本质是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的服务。

基本配置

此时无论我们调用多少次，调用的都是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的依赖：

然后在配置文件中配置

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依赖

3.在启动类

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

4.添加配置文件application.properties

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

1、创建一个 springcloud-eureka-client 的项目，然后在 pom 中增加

spring-cloud-starter-netflix-eureka-client 的依赖。

2.在启动类

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

配置

eureka.client.serviceUrl.defaultZone 的地址，也就是刚刚启动的 Eureka Server 的地址， 。

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

Eureka 注册中心添加密码认证

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

如果在实际使用中，注册中心地址有公网 IP 的话，必然能直接访问到，这样是不安全的。所以我们需要对 Eureka 进行改造，通过集成 Spring-Security 来进行安全认证，加上权限认证来保证安全性。

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

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

最后增加Spring Security 配置类

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

总结

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

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

关于javaeureka和javaeureka面试题的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。