服务注册中心--Eureka

一.Eureka概述

Eureka是一个基于REST的服务，主要用于AWS(Amazon Web Services 亚马逊云计算服务)云中的定位服务，以实现中间层服务器的负载平衡和故障转移在 Spring Cloud 微服务架构中通常用作注册中心, 我们称这个服务为 Eureka Server，还有一个与之交互的客户端称之为 Eureka Client .

二.Eureka架构图

在这里插入图片描述

如上图所示，其中

Eureka Server 表示服务注册中心 (Eureka服务端)

Application Service表示服务提供方 (Eureka客户端,需要在Eureka服务端注册)

Application Client 表示服务消费方 (Eureka客户端,需要在Eureka服务端注册)

Make Remote Call 表示远程调用

服务在Eureka上注册，然后每隔30秒发送心跳来更新它们的租约。如果客户端不能多次续订租约，那么它将在大约90秒内从服务器注册表中剔除。客户端的注册信息会被被复制到集群中的所有eureka节点。来自任何区域的客户端都可以查找注册表信息（每30秒发生一次）来定位它们的服务（可能在任何区域）并进行远程调用。Eureka Client需要每30秒给Eureka Server发一次心跳，同时更新Server上最新的注册信息到本地，如果Server多次没有收到来自客户端的心跳，那么在90秒内会被Server上剔除.

在这里插入图片描述

三.Eureka客户端与服务端(注册中心)之间的通信

1.register（注册）: Eureka客户端将关于运行实例的信息注册到Eureka服务器。注册发生在第一次心跳。

2.renew（更新 / 续借）:Eureka客户端需要更新最新注册信息（续借），通过每30秒发送一次心跳。更新通知是为了告诉Eureka服务器实例仍然存活。如果服务器在90秒内没有看到更新，它会将实例从注册表中删除。建议不要更改更新间隔，因为服务器使用该信息来确定客户机与服务器之间的通信是否存在广泛传播的问题。

3.Fetch Registry（抓取注册信息）:Eureka客户端从服务器(注册中心)获取注册表信息并在本地缓存。之后，客户端使用这些信息来查找其他服务。通过在上一个获取周期和当前获取周期之间获取增量更新，这些信息会定期更新(每30秒更新一次)。获取的时候可能返回相同的实例。Eureka客户端自动处理重复信息。

4.Cancel（取消）:Eureka客户端在关机时向Eureka注册中心发送一个取消请求。这将从服务器的实例注册表中删除实例，从而有效地将实例从流量中取出.

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

四.Eureka自我保护机制

如果 Eureka 服务器检测到超过预期数量的注册客户端终止了连接，并且同时正在等待被驱逐，那么它们将进入自我保护模式。这样做是为了确保灾难性网络事件不会擦除eureka注册表数据，并将其向下传播到所有客户端。

任何客户端，如果连续3次心跳更新失败，那么它将被视为非正常终止，病句将被剔除。当超过当前注册实例15%的客户端都处于这种状态，那么自我保护将被开启。

举例:比如你有10个user-service节点注册到eureka-server中，这个时候挂了两台。那么正常比例就是：(10-2)/10 = 80% 。只有80%的节点正常，20%的节点不正常（超过15%的异常率）。这个时候就会引发自我保护机制。

当自我保护开启以后，eureka服务器将停止剔除所有实例，直到：

它看到的心跳续借的数量回到了预期的阈值之上，或者
自我保护被禁用

默认情况下，自我保护是启用的，并且，默认的阈值是要大于当前注册数量的15%

五.Eureka集群原理

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

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

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

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

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

1.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 中获取信息。

2.Eurka 保证 AP

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

六.Eureka配置解析

1.EurekaServer配置解析

server:port: 7001
spring:application:name: service-eureka# 引入spring security,配置权限认证的用户名和密码security:user: #登录注册中心的用户名和密码name: adminpassword: admin
eureka:instance:# eureka服务端的实例名称# 单机 hostname: localhosthostname: 127.0.0.1instance-id: ${eureka.instance.hostname}:${server.port}prefer-ip-address: true# Eureka客户端向服务端发送心跳的时间间隔,单位为秒(默认是30秒)lease-renewal-interval-in-seconds: 30# Eureka服务端在收到最后一次心跳后等待时间上限 ,单位为秒(默认是90秒),超时剔除服务lease-expiration-duration-in-seconds: 90server:# 禁用自我保护,保证不可用服务被及时删除，默认启用为trueenable-self-preservation: false# Server 清理无效节点的时间间隔，默认60000毫秒，即60秒。eviction-interval-timer-in-ms: 60000# 自我保护续约百分比，默认是0.85renewal-percent-threshold: 0.85client:# false表示不向注册中心注册自己register-with-eureka: false# false表示自己端就是注册中心,我的职责就是维护服务实例,并不需要检索服务fetch-registry: falseservice-url:# 设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址# 单机 defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/defaultZone: http://${spring.security.user.name}:${spring.security.user.password}@${eureka.instance.hostname}:${server.port}/eureka/# 相互注册# defaultZone: http://eureka7002.com:7002/eureka/

2.EurekaClient配置解析

server:port: 8001
spring:application:name: service-providereureka:client:register-with-eureka: truefetch-registry: trueservice-url:defaultZone: http://localhost:7001/eureka# 集群版#defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka# 是否注册到注册中心enabled: trueinstance:hostname: 127.0.0.1port: 7001user: adminpassword: admininstance-id: ${eureka.instance.hostname}:${server.port}# 访问路径可以显示ip地址prefer-ip-address: true

七.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与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分钟内超过15%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

1.Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务

2.Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)

3.当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。