十、（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节点上

如何开启自我保护

通过

eurekaserverenable-self-preservation=true/false来开启或关闭自我保护机制。

其他关键配置：

清理失效服务节点的时间间隔：

eurekaserverevication-interval-timer-in-ms默认60s

续约间隔时间：

eurekainstancelease-renewal-interval-in-seconds默认30s

续约到期时间：

eurekainstancelease-expiration-duration-in-seconds默认90s

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

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

第二步，我们找到eureka-core jar包下的路径为comnetflixeureka下的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。

第二步，配置文件中添加

eurekaclienthealthcheckenabled=true 配置

原理分析：

首先在 EurekaDiscoveryClientConfiguration 中根据 eurekaclienthealthcheckenabled 的值来决定是否要装配 EurekaHealthCheckHandler ，然后在 EurekaClientAutoConfiguration 中会注册 HealthCheck ，但我们注册完成后会有调用任务来进行状态的更新，在 comnetflixdiscoveryInstanceInfoReplicatorrun() 中会进行状态更新。

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的服务。

基本配置

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

然后在配置文件中配置

springcloudloadbalancerretryenabled参数来控制重试机制的开关，因为 Spring Retry默认是开启的，所以说我们只要引入依赖即可，如果说我们想要关闭的话只需要将 springcloudloadbalancerretryenabled设置为false即可。

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

实战 Eureka 注册中心的部署

Eureka Server 项目搭建

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

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

2在pomxml文件中新增

spring-cloud-starter-netflix-eureka-server依赖

3在启动类

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

4添加配置文件applicationproperties

5启动项目，然后访问 >

Eureka意为我发现了，我找到了。

据传最早来自于阿基米德，他在泡澡时找到了通过浮力检测黄金的方法，大喊改词。

为了支撑高并发的互联网开发需求，各大互联网系统开始采用分布式开发的方式来应对。

Spring Cloud应运而生，Spring Cloud并没有从头开发组件，部分采用了已经开源的组件。

整合提供了一系列组件用于构建微服务，如服务发现、配置中心、负载均衡、短路器等。

Eureka为Netflix开源的服务发现与治理组件，后被Spring整合进Spring Cloud。

官方地址： >

我们先来看看Eureka的集群架构图

1，服务注册。

Eureka Server作为服务注册中心，为微服务架构提供服务注册功能。微服务节点启动后，会在Eureka中进行注册，Eureka Server中会存储所有的可用微服务节点信息。

2，Eureka客户端。

Eureka Client是一个java客户端，用于简化与Eureka Server的交互。客户端同时也具备一个内置的、使用轮询算法的负载均衡器。

3，心跳检测。

在应用启动后，客户端将会向Eureka Server发送心跳（默认为30秒，我们项目配置的是30秒）。Eureka Serber如果在多个心跳周期内没有收到某个微服务节点的心跳，将会剔除该节点（默认90秒，我们项目配置的是90秒）。

4，集群数据同步。

Eureka Server之间通过复制的方式来进行数据同步。

5，客户端缓存功能。

Eureka Client具有缓存功能，即使所有的Eureka Server都挂掉，客户端依然可以利用缓存中的信息消费其他服务的API。

6，清理失效节点。

7，自我保护模式。

自我保护模式是指在网络出现异常的情况下，由于Eureka Server无法收到客户端的心跳续约，Eureka Server会判断该节点不可用，但其实该节点可能是正常的，可用的。为了避免误删，Eureka Server引入了自我保护模式。一旦Eureka Server发现当前收到的心跳总次数小于心跳阈值的85%（默认值），就会进入自我保护模式，此时Eureka Server不会清理任何节点。直到Eureka Server收到的心跳总次数大于等于心跳阈值的85%。

自我保护模式的设计哲学是：在不确定节点是否可用的情况下，尽可能保留节点。

问题：Eureka Server的服务发现，是如何工作的？

答：服务发现和服务注册是同一个概念。

以上就是关于十、（Eureka篇）服务发现和自我保护机制全部的内容，包括:十、（Eureka篇）服务发现和自我保护机制、基于DNS搭建高可用Eureka注册中心、字节三面：到底知不知道什么是Eureka等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！