Eureka大杂烩

$本文将多篇前辈的博客整合一下，方便自己查看$

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

0、为什么需要注册中心

• 过去每个应用都是一个CPU，一个主机上的单一系统，然而今天，随着大数据和云计算时代的到来，任何独立的程序都可以运行在多个计算机上，并且随着业务的发展，访问用户量的增加，开发人员或小组的增加，系统会被拆分多个功能模块，拆分后每个功能模块作为一个独立的子系统提供其职责范围内的功能。而多个子系统中，由于职责不同并且会存在相互调用，同时可能每个子系统还需要多个实例部署在多台服务器或者镜像中，导致子系统的相对调用形式一个错综复杂的网状结构，

• 单体应用

  • 
  • 随着业务的发展，经过了多个系统架构的演变，变成这样的

• 

从系统架构的演变到对于微服务架构的思考

• 为什么上图中的系统演变最终会变成如图所示的样子？ 是一种架构思维，这里不扩张来说，简单描述一下微服务架构是为了解决什么问题，随着系统结构、架构的演变，系统功能的增加，用户量的增加，开发人员的增加等各种增加情况下，需要由一个比较好的扩展的系统架构来快速、尽量减少代码改动的前提下以支持系统功能开发，用户增加导致的硬件资源的横向扩容，以及开发人员的增加时的协同工作效率，在此基础上，需要解决系统的稳定性、容错性、高并发性的支持性等等，以及随着系统功能的增加如何有效管理系统，排查、定位系统问题。同时当参与项目的（包括测试、运维、业务等人员）越来越多时，如何高效的彼此之间的协同办公的效率等等。
• 所以微服务架构需要考虑的不仅仅是软件架构本身，需要从参与到整个项目实施过程中的各个环节，可能的问题以及人员协同的整体情况去考虑，让整个项目做到可用（满足功能以及硬件资源的横向扩容）、可行（满足整个系统运行中的各个点的监控、拍错等）可持续（满足系统功能的可持续集成，以及系统运行的可持续性）以及高效（系统运行的高效、人员协同工作的高效、功能的迭代的高效等）

1、 Eurake 核心概念

• 服务提供者或服务的消费者，本质上也是Eureka Client角色，整体上可以分为两个主体：Eureka Server 和Eureka Client

1.1 Eurake Server: 注册中心服务端

• 

• 注册中心服务器主要对外提供了三个功能（服务注册、提供注册表、同步状态）

• 服务注册

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

  • Eureka Server同时也是一个Eureka Client， 在不禁止Eureka Server的客户端行为时，它会向配置文件中的其他Eureka Server 进行拉取注册表、服务注册和发送心跳等操作

  • eureka server端通过 appName 和 instanceInfoId 来唯一区分一个服务实例，服务实例信息是保存在哪里呢？其实就是一个Map中：

  • // 第一层的key是appName，第二层的key是instanceInfoId
    private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry 
        = new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();
    

• 写入本地reistry

  • 服务信息（InstanceInfo ) 保存在Lease中，写入本地registry对应方法com.netflix.eureka.registry.PeerAwareInstanceRegistryImpl#register，Lease 统一保存在内存的ConcurrentHashMap中，在服务注册过程中，首先加个读锁，然后从registry中判断该Lease是否已经存在，如果已经存在则比较lastDirtyTimestamp，时间戳，取二者最大的服务信息，避免发生数据覆盖，使用instanceInfo 创建一个新的InstanceInfo:

  • if (existingLastDirtyTimestamp > registrationLastDirtyTimestamp) {
        // 已存在Lease则比较时间戳，取二者最大值
        registrant = existingLease.getHolder();
    }
    Lease<InstanceInfo> lease = new Lease<InstanceInfo>(registrant, leaseDuration);
    if (existingLease != null) {
        // 已存在Lease则取上次up时间戳
        lease.setServiceUpTimestamp(existingLease.getServiceUpTimestamp());
    }
    
    public Lease(T r, int durationInSecs) {
        holder = r;
        registrationTimestamp = System.currentTimeMillis(); // 当前时间
        lastUpdateTimestamp = registrationTimestamp;
        duration = (durationInSecs * 1000);
    }
    

• 同步给其他peer

  • InstanceInfo 写入到本地的registry之后，然后同步给其他peer节点，对应的方法com.netflix.eureka.registry.PeerAwareInstanceRegistryImpl#replicateToPeers，如果当前节点接收到的InstanceInfo 本身就是另一个节点同步过来，则不会继续同步给其他节点，避免形成广播效应， InstanceInfo 同步时，会排除当前节点

  • InstanceInfo 的状态有依次以下几种：Heartbeat， Register、cancel、StatusUpadte, DeleteStatusOverride, 默认情况下同步操作时批量异步执行的，同步请求首先缓存到Map中，key为requestType + appName +id ,然后由发送线程将请求发送到peer节点

    Peer 之间的状态是采用异步的方式同步的，所以不保证节点间状态一定是一致的，不过基本能保证最终状态一致性的，结合服务发现的场景，实际上也并不需要节点间的状态强制一致性，在一段时间内（30s），节点A比节点B多一个服务实例或少一个服务实例，在业务上也是完全可以接受的（Service Consumser 则 一般也会实现错误重试和负载均衡机制），所以按照CAP理论，Eureka的选择是AP

    如果同步过程中，出现异常怎么办？ 这个时候根据异常信息做对应的处理，如果读取超时或网路连接异常，则稍后重试，如果其他异常则打印错误日志不在后续处理

• 提供注册表

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

• 同步状态

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

• Eureka Server 的伸缩容

  • Eureka Server是怎么知道有多少Peer的呢？Eureka Server在启动后会调用EurekaClientConfig.getEurekaServerServiceUrls来获取所有的Peer节点，并且会定期更新，定期更新频率可以通过eureka.server.peerEurekaNodesUpdateIntervalMs 配置。

  • 这个方法的默认实现是从配置文件中读取，所以如果Eureka Server节点相对固定的话，可以通过在配置文件中配置来实现，如果希望能更加灵活的控制Eureka Server节点，比如动态扩容、缩容，那么可以override getEurekaServerServiceUrls方法，提供自己的实现。比如我们的项目中会通过数据库Eureka Server列表。

    eureka server启动时把自己当做是Service Consumer 从其他Peer Eureka获取所有服务的注册信息，然后对每个服务信息，在自己这里执行Register， isReplication=true, 从而完成初始化

1.2、Eureka client 的注册中心客户端

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

• Register : 服务注册

  • 服务提供者，将自身注册到注册中心，服务提供者也是一个Eureka Client， 当Eureka Client 想Eureka Server 注册时，他提供自身的元数据，比如IP地址，端口，运行状态指示符URL， 主页等,需要注意的是，需要确保配置eureka.client.registerWithEureka=true，register逻辑在方法AbstractJerseyEurekaHttpClient.register中，Server Provider 会依次注册到配置的EurekaServer URL上，如果注册出现异常，则会继续注册其他的url

• Renew 服务续约

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

• 服务续约的两个属性

• 服务续约任务的调用间隔时间，默认为30秒
  eureka.instance.lease-renewal-interval-in-seconds=30
  
  服务失效的时间，默认为90秒。
  eureka.instance.lease-expiration-duration-in-seconds=90
  

• Eviction 服务剔除

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

• Cancel 服务下线（com.netflix.eureka.registry.PeerAwareInstanceRegistryImpl#cancel）

  • Eureka Client 在程序关闭时想Eureka Server 发送取消请求，发送请求后，该客户端实例信息将从Eureka Server的实例注册表中删除。该下线请求不会自动完成，他需要调用以下内容，需用及时通知Eureka Server 把自己剔除，从而避免客户端调用已经下线的服务，逻辑本身比较简单，通过对方法标记为@PreDestroy, 从而在服务shutdown的时候会被触发。

  • DiscoveryManager.getInstance().shutdownComponent()；
    

• GetRegisty :获取注册列表信息

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

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

  • Eureka consumer 服务信息的拉取分为增量拉取和全量拉取，eureka consumer启动时进行全量拉取，运行过程中有定时任务进行增量拉取，如果网络出现异常，可能导致先拉取的数据被旧数据覆盖（比如上一次拉取线程获取结果较慢，数据已更新情况下使用返回结果再次更新，导致数据版本落后）产生脏数据，对此，eureka通过类型AtomicLong 和 fetchRegistryGeneration对数据版本进行跟踪，版本不一致则表示此次拉取的数据过期

    fetchRegistryGeneration过程是在拉取数据之前，执行fetchRegistryGeneration.get获取当前版本号，获取到数据后，通过fetchRegistryGeneration.compareAndSet 来判断当前版本是否已经更新，

    注意：如果增量式更新出现意外，会再次进行一次全量拉取更新。

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

• # 启用服务消费者从注册中心拉取服务列表的功能
  eureka.client.fetch-registry=true
  
  # 设置服务消费者从注册中心拉取服务列表的间隔
  eureka.client.registry-fetch-interval-seconds=30
  
  

• Remote Call :远程调用

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

2、自我保护机制

• 默认情况下，如果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.server.enable-self-preservation=true
  
  

3、Eureka 集群原理

• 再看看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中获取信息。

• Eureka 保证AP

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

4、Eureka 工作流程

1. Eureka Server 启动成功，等待服务端注册，在启动过程中如果配置集群，集群之间定时通过Replicate 同步注册表，每个Eureka Server 都存在独立完整的服务注册表信息
2. Eureka Client 启动时根据配置的Eureka Server 地址去注册中心注册服务
3. Eureka Client 会每30秒想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 将实例从注册表中删除

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

5、dubbo ,zookeeper , eureka之间的关系与区别

• Dubbo 相当于Spring Cloud
  • Dubbo是个微服务整体架构的框架，提供的功能包括服务注册发现，远程调用，监控等待，对标的项目是Spring Cloud， 但Spring Cloud 是一系列软件，有很多组件来拼装提供微服务的总体架构。Dubbo自己全部封装了。
• zookeeper 集成在Dubbo中以后，相当于Spring Cloud 中的Eureka
  • Dubbo的服务发现模块基于zookeeper实现。
  • Eureka是spring cloud 下一个专门负责微服务服务注册和发现的组件，Eureka就是为了服务发现而设计的，是Dubbo对应的概念的一部分
• 原本的zookeeper
  • zookeeper是用来保证分布式一致性的一个软件，不是为了服务发现注册而设计。只不过他的特性也可以被二次开发服务发现注册中心罢了。

6、作为服务注册中心，Eureka 比Zookeeper 好在哪里？

• 著名的CAP理论指出，一个分布式系统不可能同时满足C (一致性) A（可用性） 和 P（分区容错性）,由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡，在此zookeeper 保证的是CP，而Eureka 保证是AP
• 
• zookeeper 保证 CP
  • 当向注册中心查询服务列表时， 我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务注解down掉不可用，也就是服务注册对可用性的要求高于一致性，但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举，问题在于，选举leader的时间太长，30~120s，且选举期间整个zk集群是不可用的，这就导致在选举期间注册服务瘫痪，在云部署的环境下，因为网络问题使得整个zk集群失去master节点是较大概率发生的事情，虽然服务能够最终恢复，但是漫长的选举时间导致了的注册长期不可用是不能容忍的。
• Eureka 保证AP
  • Eureka 看明白了这点，因此在设计时就先保证可用性，Eureka各个节点都是平等的，几个节点挂掉不会影响到正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向其中一个Eureka 注册或时如果发现连接失败，则会自动切换到其他节点，只有有一台Eureka还在，就能保证注册服务可用（保证可用性）只不过查到的信息可能不是最新的（不保证强一致性），那么除此之外，Eureka还是有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现网络故障，此时会出现以下几种情况：
    1. Eureka 不在从注册列表中移除因为长时间没有收到心跳而应该过期的服务。
    2. Eureka仍然能够接受服务的注册和查询请求，但不会被同步到其他节点上（即保证当前节点仍然可用）
    3. 网络稳定时，当前实例新的注册信息会被同步到其他节点中，
  • 因此，Eureka可以很好的应对网络故障导致部分接地那失去联系的情况，而不会像zookeeper那么使得整个真粗服务瘫痪
• 数据一致性
  • ZAB 是zookeeper的原子广播协议，基于Paxos 算法改的 。分布式一致性算法 Paxos
  • Raft 是工程上使用较为广泛的强一致性，去中心话，高可用的分布式协议 分布式一致性算法 Raft
• 技术对照表
  • 

7、consul、eureka、nacos 对比

• 配置中心

  • eureka 不支持
  • consul 支持 但用起来偏麻烦，不太符合Spring Boot框架的命名风格，支持动态刷新
  • nacos 支持，用起来简单，服务Spring Boot的命名风格，支持动态刷新

• 注册中心

  • eureka
    • 依赖：依赖Zookeeper
    • 应用内外：依赖于应用自身完成服务注册与发现
    • ACP原则：遵循AP（可用性+分区容忍）原则，有较强的可用性，服务注册块，但是牺牲了一定的一致性。
    • 版本迭代：目前已经不进行升级
    • 集成支持：只支持SpringCloud集成
    • 访问协议：HTTP
    • 雪崩保护：支持雪崩保护
    • 界面：英文界面，不符合国人习惯
    • 上手：容易
  • consul
    • 依赖：不依赖其他组件
    • 应用内外：属于外部应用，入侵性小
    • ACP原则：遵循CP原则（一致性和分区容忍）服务注册稍慢，由于其一致性导致在Leader挂掉时重新选举期间整个consul不可用
    • 版本迭代：目前仍然进行版本迭代
    • 集成支持：只支持SpringCloud K8S集成
    • 访问协议：HTTP/DNS
    • 雪崩保护：不支持雪崩保护
    • 界面：英文界面，不符合国人习惯
    • 上手：复杂一些
  • consul
    • 依赖：不依赖其他组件
    • 应用内外：属于外部应用，入侵性小
    • ACP原则：通知遵循CP原则（一致性+分区容忍）和 AP（可用性+分区容忍）原则
    • 版本迭代：目前仍然进行版本迭代
    • 集成支持：支持dubbo，springcloud ，k8s继承
    • 访问协议：HTTP/动态DNS/UDP
    • 雪崩保护：支持雪崩保护
    • 界面：中文界面
    • 上手：容易

• 

• Nacos 的CP模式切换

  • curl -X PUT `$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'
    

  • 一般来说，如果不需要存储服务级别的信息且服务实例是通过nacos-client 注册，并能保持心跳上报，那么就可以选择AP模式，当前主流的服务如Spring Cloud和Dubbo服务，都是适用于AP模式，AP模式为了服务的可能性而减弱了一致性，因此AP模式下只支持注册临时实例。

  • 如果需要在服务级别编辑或存储配置信息，那么CP是必须的，K8s服务和DNS服务则适用于CP模式，CP模式下支持注册持久化实例，此时则是以Raft协议为集群运行模式，该模式下注册实例之间必须先注册服务，如果服务不存在，则会返回错误。

8、Eureka 应用解决客户端容错问题 （hystrix）

• hystrix是一个实现了超时机制和断路器模式的工具类库，在正常情况下，断路器关闭，可正常请求依赖的服务，当一段时间内，请求失败率达到一定阈值，断路器就会打开，此时，不会再去请求依赖的服务，断路器打开一段时间后，会自动进入半开状态，此时断路器允许一个请求访问依赖的服务，如果请求能够调用成功，则关闭断路器，否则继续保持打开的状态。
• 通过上述机制保护应用，从而防止雪崩效应并提高应用的可用性
• 其实，在我们日志访问网站的过程中，每次请求都对应一个线程，如果响应太慢，这个线程就得不到释放，而如果线程得不到释放会越积越多，最后系统资源耗尽，导致服务不可用

10、Q&A

1. Eureka Server如何实现高可用？
   • 机制： 将自己做为注册中心向其他服务注册中心注册自己，这样就形式一组相互注册的服务的注册中心
   • 实现： Eureka 服务端，我们称为服务注册中心，他同其他服务注册中心一样，支持高可用配置、他依托于强一致性提供良好的服务实例可用性，可以应对多种不同的故障场景，如果Eurake以集群方式部署，当集群中有分区出现故障时，那么Eureka就转入自我保护机制，其他分片会把他们的状态再次同步过来，以及在AWS的实例为例，Netflix推荐每个可用的区域运行一个Eureka服务端，通过他形式集群，不同可用区域的服务注册中心通过异步模式相互复制各自的状态，这意味着在任意给定的时间点每个实例关于所有服务的状态是有细微的差别的。
   • Eureka客户端，主要处理服务的注册与发现，客户端服务通过注解和参与配置方式，嵌入在客户端应用程序的代码中，在应用程序运行时，Eureka客户端向注册中心注册自身提供的服务并周期性第发送心跳来更新他的服务租约，同时 他也能从服务端查询当前注册的服务信息并把它们缓存到本地并周期性地刷新服务的状态

11、Eureka 不足

• eureka consumer 本身有缓存， 服务状态更新滞后， 最常见的状态就是，服务下线了，但是服务消费者还是未及时感知，此时调用到已经下线服务导致请求失败，只能依靠consumer端的容错机制来保证

12、 参考引用

1. Eureka工作原理
2. Spring Cloud之Eureka服务注册与发现（概念原理篇
3. eureka原理分析
4. dubbo+zookeeper与 eureka的区别
5. [dubbo，zookeeper，eureka之间的关系与区别
6. consul、eureka、nacos对比
7. nacos与eureka注册中心的对比
8. Nacos与Eureka
9. nacos简介以及作为注册/配置中心与Eureka、apollo的选型比较