Eureka（注册发现）学习笔记

一、SpringCloud介绍

1、SpringCloud简介

SpringCloud是基于SpringBoot的一整套实现微服务的框架。它提供了微服务开发所需的管理、服务发现、断路器、智能路由、微代理、控制总线、全局所、决策精选、分布式会话、集群状态管理等组件。
官方：https://spring.io/projects/spring-cloud
中文：https://www.springcloud.cc/

2、Spring Cloud Netflix简介

该项目是Spring Cloud的核心子项目，是对Netflix公司一些列开源产品的封装。它为Spring Boot应用提供了自配置的整合，只需要通过简单的注解，就可以快速地在Spring Cloud的应用中使用起来。

主要提供的模块包括：服务发现注册（Eureka）、客户端负载均衡（Ribbon）、断路器（Hystrix）、智能路由（Zuul）、声明性REST客户端（Feign）、外部配置（Archaius）等。

二、Eureka简介

1、Eureka是什么

Eureka是Spring Cloud Netflix的一个子模块，也是核心模块之一。Eureka是一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移。

服务注册于发现对于微服务架构来说非常重要，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了。功能类似于dubbo的注册中心，比如zookeeper。

2、Eureka两个组件

Eureka包含两个组件：Eureka Server和Eureka Client

1、Eureka Server：提供服务注册功能，各节点启动后，会在Eureka Server中进行注册，这样Eureka Server中的服务注册表将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。

2、Eureka Client：是一个Java客户端，用于简化与Eureka Server的交互，客户端同时也具备一个内置的、使用轮询（round-robin）负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳（默认周期为30秒）。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除（默认90秒）。

3、Eureka Server之间将会通过复制的方式，完成数据的同步。Eureka还提供了客户端缓存的机制，即使所有的Eureka Server都挂掉了，客户端依然可以利用缓存中的信息，消费其他服务的API。Eureka通过心跳检测、健康检查、客户端缓存等机制，确保了系统的高可用性，灵活性和可伸缩性。

3、Eureka高层架构

Eureka Server：提供服务注册和发现
Eureka Provider：服务提供方，将自身服务注册到Eureka，从而是服务消费方能够找到。
Service Consumer：服务消费方，从Eureka获取注册服务列表，从而能够访问服务。

4、Eureka高层架构2

进一步展示了三个角色之间的交互：
1、Service Provider会向Eureka Server做Register（服务注册）、Renew（服务续约）、Cancel（服务下线）等操作。
2、Eureka Server之间会做服务注册的同步，从而保证状态一致。
3、Service Consumer会从Eureka Server获取注册服务列表，并调用服务。

三、Eureka基本概念

1、Register：服务注册

服务提供者向Eureka Server注册，注册发生在第一次心跳，它提供关于自己的元数据（例如主机、端口、健康指标URL等）给Eureka Server。

2、Renew：服务续约

Eureka客户端会每隔30秒向Eureka Server发送一次心跳来续约，通过续约来告知Eureka Server该Eureka客户端仍然活着。通常Eureka Server如果在90秒仍没有收到来自某Eureka客户端的续约，则会将该客户端从注册列表删除。建议不要修改续约间隔。

注册信息和续约会被复制到Eureka Server集群中的所有节点，来自任何区域的Eureka Client都可查阅注册表信息（每30秒一次）。根据注册列表中的信息，Application Client可调用Application Service来消费服务。

3、Fetch Registries：获取注册列表信息

Eureka Client从Eureka Server获取注册表信息，并将其缓存在本地。Eureka Client会使用该注册表信息对远程服务进行调用。该注册列表信息每30秒更新一次，若查到的信息与本地不一致，则更新本地注册表信息。

如果由于某种原因导致本地注册表信息不能及时获取，则Eureka Client会及时调用Eureka Server来获取整个注册表信息。Eureka Server缓存注册表信息，默认Eureka Client使用压缩JSON格式来获取注册列表信息。

4、Cancel：服务下线

Eureka Client在服务关闭时，向Eureka Server发送取消请求。Eureka Server收到cancel请求后，会把该Eureka Client从注册信息表中删除。

5、Eviction：服务剔除

Eviction用来定期（默认每60秒）在Eureka Server检测失效的服务，查询在指定时间内没有renew的服务，默认失效时间为90秒，若90秒都没有心跳，则把该Eureka Client从Eureka Server注册信息表中删除。

四、为什么注册服务这么慢

1、注册延迟

Eureka Client一启动，不是马上向Eureka Server注册，它有一个延迟向Eureka Server注册的时间，也就是定期向Eureka Server发送心跳，默认是30秒。

2、Eureka Server的响应缓存

Eureka Server维护了一个每30秒更新一次的响应缓存。可通过更改配置 eureka.server.responseCacheUpdateIntervalMs来修改。所以，当某个Eureka Client刚刚注册，如果未更新到缓存，那么他不会出现在返回给客户端的注册信息列表中。

3、Eureka Server刷新缓存

Eureka Client保留了Eureka Server注册表信息到缓存，然后每30秒调用一次Eureka Server更新一次缓存。

4、在极端情况下可能需要3次心跳，Eureka Client才能发现服务

5、不要修改心跳时间间隔

可以使用eureka.instance.leaseRenewalIntervalInSeconds更改期限，这将加快客户端连接到其他服务的过程。在生产中，最好坚持使用默认值，因为服务器内部有一些计算可以 对租赁更新期进行假设。

五、Eureka和Zookeeper比较

1、CAP理论回顾

1.1、一致性（C）

在分布式系统中，执行完更新操作后，所有用户都能读取到最新的值，这样的系统被叫做强一致性。

1.2、可用性（A）

每个请求都会收到响应，无论这个响应是成功或失败。

1.3、分区容错性（P）

系统在存在网络分区的情况下，仍可接受请求并处理。网络分区是指网络被分成若干区域，区域之间互不相同。

1.4、CAP总结

分区容错性是分布式系统中必须要保证的。所以在C和A之间进行取舍。

2、Zookeeper和Eureka区别

zk保证的是CP。
eureka保证的是AP。

2.1、Zookeeper保证CP

在任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分区具备容错性。

但是它不能保证每次服务请求的可用性，也就是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果，比如重新选举leader的时间太长，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。

2.2、Eureka保证AP

实际应用中，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用，也就是说，服务注册功能对可用性的要求要高于一致性。 Eureka服务节点在短时间里丢失了大量的心跳连接，那么这个 Eureka节点会进入“自我保护模式”，同时保留那些“心跳死亡”的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册务，对于“死亡”的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个 Eureka节点会退出“自我保护模式”。Eureka的哲学是，同时保留“好数据”与“坏数据”总比丢掉任何数据要更好。

六、自我保护模式

1、概述

保护模式主要用于一组Eureka Client和Eureka Server之间，存在网络分区场景下的保护。一旦进去保护模式，Eureka将尝试保护其服务注册表中的信息：即不会删除任何服务注册表中的数据，也就是不会注销任何微服务。

如果在Eureka Server的首页看到以下这段提示，则说明Eureka进入了保护模式:

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT.
RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE

2、何时进入保护模式

当一个新的Eureka Server出现时，它尝试从相邻节点获取所有实例注册表信息。如果从Peer节点获取信息时出现问题，Eureka Server会尝试其他的Peer节点。如果服务器能够成功获取所有实例，则根据该信息设置应该接收的更新阈值。

如果有任何时间，Eureka Server接收到的续约低于为该值配置的百分比(默认为15分钟内低于85%)，则服务器开启自我保护模式，即不再剔除注册列表的信息。

这样做的好处就是，如果是Eureka Server自身的网络问题，导致Eureka Client的续约不上，Eureka Client的注册列表信息不再被删除，也就是Eureka Client还可以被其 他服务消费。

七、Eureka集群

1、构建Eureka Server集群

1、启动多个Eureka Server，其中每个Eureka Server配置的defaultZone为其它的Eureka Server。

2、客户端连接的时候， defaultZone的值可以写多个，用逗号区分。

3、深入理解：
1）实际应用中，因负载等原因，往往可能需要在生产环境构建多于两个的EurekaServer节点。那么对于如何配置serviceUrl来让集群中的服务进行同步，需要我们更深入的理解节点间的同步机制来做出决策。
2）Eureka Server的同步遵循着一个非常简单的原则: 只要有一条边将节点连接，就可以进行信息传播与同步。

2、Eureka Server之间的通信

1、Eureka Client首先会连接同一区域中的Eureka Server，若连接不上，或不在同一个区域，则Eureka Client将故障转移到其他可用区的Eureka Server。

2、一旦Eureka Server开始接收流量，在该Eureka Server上接收到的所有操作都将被复制到该Eureka Server所知道的所有服务器节点。如果复制操作由于某种原因而失败，则将在下一次服务器之间复制的心跳信号中进行核对。

3、当Eureka Server启动时，它会尝试从邻居节点获取其所有的注册表信息，如果获取信息出现问题，该Eureka Server在放弃前，会尝试从所有的对等节点中获取。如果该Eureka server能够成功获取所有注册表实例，则会根据这些信息来设置更新阈值。如果任何时候，续订低于该值设定的百分比（15分钟内低于85%），则服务器将进入自我保护模式。
在这种情况下，如果Eureka Server无法从邻居节点获取到注册表信息，则等待5分钟，以便客户端可以注册其信息。此时注册信息可能发生在孤立的服务器上，有些客户端可能会反映新的注册，而有些客户端可能不会。在网络恢复稳定后，信息会自动更正：当对等方能正常通信时，注册信息会自动同步。

4、Peer之间的状态同步：
Service Provider只需要通知到任何一个Eureka Server后，就能保证其信息在所有的Eureka Server中得到更新。
具体实现方式其实很简单，就是接收到Service Provider请求的Eureka Server，把请求再次转发到其它的Eureka Server，调用同样的接口，传入同样的参数，除了会在 header中标记isReplication=true，从而避免重复的replicate。
Peer之间的状态是采用异步的方式同步的，所以不保证节点间的状态一定是一致的 ，不过基本能保证最终状态是一致的。

5、Eureka Server是怎么知道有多少Peer的呢?
Eureka Server在启动后会调用EurekaClientConfig.getEurekaServerServiceUrls来获取所有的Peer节点，并且会定期更新。定期更新频率可以通过 eureka.server.peerEurekaNodesUpdateIntervalMs配置。
这个方法的默认实现是从配置文件读取，所以如果Eureka Server节点相对固定的话 ，可以通过在配置文件中配置来实现。
如果希望能更灵活的控制Eureka Server节点，比如动态扩容/缩容，那么可以覆盖 getEurekaServerServiceUrls方法，提供自己的实现，比如通过数据库读取Eureka Server 列表