spring cloud之 eureka原理及其配置

最新推荐文章于 2022-04-28 20:17:09 发布

尤尤尤奴斯

最新推荐文章于 2022-04-28 20:17:09 发布

阅读量321

点赞数 1

springcloud 系列专栏收录该内容

4 篇文章 0 订阅

订阅专栏

Spring Cloud针对服务注册与发现，进行了一层抽象，并提供了三种实现： Eureka(支持得最好)、Consul、Zookeeper。

由于项目中使用到了Eureka,所以对Eureka有了一个深入的了解.

1.Eureka概述

Eureka 是 Netflix 开源的服务注册发现组件，服务端通过 REST 协议暴露服务，提供应用服务的注册和发现的功能。
我们将所有的Eureka服务称为实例（instance）, Eureka服务又分为两类：Eureka Server(服务端)和Eureka Client (客户端);
Eureka-Client 又分为Application Provider 和Application Consumer,
Application Provider ：服务提供者，内嵌 Eureka-Client ，它向 Eureka-Server 注册自身服务、续约、下线等操作 .
Application Consumer ：服务消费者，内嵌 Eureka-Client ，它从 Eureka-Server 获取服务列表，分为全量获取和增量。

这里需要理解的是服务提供者和服务消费者只是代表了一个角色,一个Eureka-Client既可以当作服务提供者向外提供服务,又可以当作服务消费者去消费其他的服务.

在springcloud中Eureka的配置主要分为三种类型:

eureka.instance.*: Eureka实例注册配置项，这些是无论Eureka作为Server，Client都需要的公共配置项。对应的配置类为org.springframework.cloud.netflix.eureka.EurekaInstanceConfigBean。
eureka.server.*: Eureka做为Eureka Server才需要配置的选项，即使用eureka做注册中心时需要配置的选项。对应的配置类为org.springframework.cloud.netflix.eureka.EurekaClientConfigBean。
eureka.client.*: Eureka做为Eureka Client才需要配置的选项，即服务需要向注册中心注册或使用注册中心中的服务时需要配置的选项。对应的配置类为org.springframework.cloud.netflix.eureka.server.EurekaServerConfigBean

2.Eureka的架构

2.1 服务首次注册

服务提供者在启动时会向Eureka Server注册自身信息（包括服务名(Eureka Service Id)、ip地址、port、心跳周期等），EurekaServer获取注册请求，将服务实例信息存入到读写缓存中.
服务消费者根据Eureka 的service id从 Eureka Server获取要访问服务的注册信息，第一次请求时会一次性拉取对应Eureka server中全部服务的实例信息.
Eureka Server收到请求后，首先会在只读缓存查找服务信息，如果找到则直接返回，否则去查找读写缓存,如果找到将其存入到只读缓存中，然后返回查找结果.这一点有点类似于redis作缓存服务器时的用法.
服务消费者拉取注册信息后，将服务实例信息缓存到本地，在使用时根据负载均衡算法从N个服务集群中选取一个服务并向这个服务发起请求

client客户端常用配置信息:

#服务service-id
spring:
  application:
    name: ek-provider
#服务端口
server:
  port: 8100
#实例配置
eureka:
  instance:
    #服务续约任务（心跳）的调用间隔，单位：秒,默认30s
    leaseRenewalIntervalInSeconds: 5
    #定义服务失效的时间，单位：秒,默认90s
    leaseExpirationDurationInSeconds: 10
  client:
    serviceUrl:
      #注册中心地址
      defaultZone: http://localhost:8000/eureka/
    
#日志
logging:
  level:
    com.netflix: DEBUG

除此之外,还有以下常用配置可选:

续约/心跳/下线：

服务提供者会定时向Eureka Server发送心跳，默认30s
Eureka Server收到心跳后，会更新对应的服务实例信息，如果服务的状态有变化则将实例的变化加入到”最近租约变更记录队列”中
Eureka Server有个实例过期清理定时器，如果在指定时间内没有收到心跳(默认90s)，则认为服务已经下线，会从读写缓存中移除此实例，将并此变化更新“最近租约变更记录队列”。通常建议将存活的最长时间设置为3个心跳
服务消费者也有个定时任务会定时去更新服务实例信息（默认30s），第一次全量拉取服务实例，会读取所有的实例信息; 之后使用增量拉取服务实例信息，Eureka Server根据”最近租约变更记录队列”，告诉请求方哪些服务实例有变化，只返回变化的实例信息。客户端根据返回的增量信息更新本地缓存。我们也可以禁用增量获取服务实例实例，这样每次会全量获取服务实例信息

服务实例下线，分为两种:

主动下线，在服务实例结束前，主动通知Eureka Server，在默认配置下，此时服务消费者最长在30s左右知道服务提供者已经下线.
被动下线，服务进度崩溃/网络异常，此时服务消费者最长在(3次心跳+一次刷新频率30s)（120s左右）内知道服务提供者已经下线

# EurekaClientConfig，重在 Eureka-Client，例如， 连接的 Eureka-Server 的地址、获取服务提供者列表的频率、注册自身为服务提供者的频率等等 
## 服务发现相关的配置
# 是否从 Eureka-Server 拉取服务实例注册信息，默认值为true
eureka.client.fetch-registry: true
# 从 Eureka-Server 拉取注册服务实例信息频率，默认：30 秒
eureka.client.registry-fetch-interval-seconds: 30 

# 是否禁用增量获取服务实例注册信息
eureka.disableDelta: false
# EurekaInstanceConfig，重在服务实例，例如，等等。此处应用指的是，Application Consumer 和 Application Provider。
# 服务实例配置
# 心跳，租约续约频率，单位：秒
eureka.instance.lease-renewal-interval-in-seconds: 30
#  eureka server多久没有收到心跳，则表示对应的实例过期，单位：秒。
eureka.instance.lease-expiration-duration-in-seconds: : 90s
# Eureka Server端服务实例租约过期定时任务执行频率
eureka.server.eviction-interval-timer-in-ms: 60s

关于缓存

Eureka Server有两个缓存，一个只读缓存，一个是读写缓存。

读写缓存：每次有服务实例状态变化（如注册服务、下线等）只会更新读写缓存
只读缓存永不过期，但是可能存在过期数据。此时为了保证只读数据的准确性，会有个定时器定时同步两个缓存，然后将状态变化的服务实例添加到”最近租约变更记录队列”。执行频率默认30s

所以 ,为了提高实时性，可以考虑关闭只读缓存。

"最近租约变更记录队列" 里的数据也有有效期，默认为180s。

当有注册、状态变更、下线时，会将创建最近租约变更记录加入此队列中
用于注册信息增量获取
后台任务定时顺序扫描队列，当数据最后更新时间超过一定时长后进行移除

Eureka Server – 自我保护机制

我们知道,当一个服务在定义的服务失效的时间内失去心跳时,服务端会将其从服务列表中移除.但有一种情况下它不会移除服务,当Eureka-Server启动自我保护时.

Renews threshold: Eureka Server 期望每分钟最少收到服务实例心跳的总数
Renews threshold = 当前注册的服务实例数 x 2 * 自我保护系数( eureka.renewalPercentThreshold )

之所以 x 2，是因为Eureka 硬编码(默认)认为每个实例每 30 秒 1 个心跳，即1分钟2个心跳
Renews (last min): Eureka Server 最近 1 分钟收到服务实例心跳的总数

当启动自我保护时，如果Eureka Server最近1分钟收到服务实心跳的次数小于阈值（即预期的最小值），则会触发自我保护模式，此时Eureka Server此时会认为这是网络问题，它不会注销任何过期的实例。等到最近收到心跳的次数大于阈值后，则Eureka Server退出自我保护模式

执行清理过期租约的逻辑

首先计算最大允许清理租约的数量，后计算允许清理租约的数量
最大允许清理租约数量 = (1-renewalPercentThreshold)*当前注册的应用实例数,若默认为0.85,则最大允许清理15%*注册实例数.
实际清理租约数量 = Math.min(所有过期注册信息个数，最大允许清理租约数量)
若Math.min为最大允许清理租约数,则说明当前过期的注册信息数大于最大允许清理租约数,则会随机清理过期的租约
如果同时过期大量注册信息，则需要好久才能将注册信息清理完毕.

是否开启自我保护的差别，在于是否执行清理过期租约逻辑。如果想关闭分批逐步过期，设置 renewalPercentThreshold = 0 。

3.Eureka集群

为了提高高可用，Eureka是提供集群功能。不仅Eureka Client端可以集群，做为注册中心的Eureka Server也可以集群。

多个Eureka Client进程向注册中心注册的Eureka Service Id相同，则被认为是一个集群。
多个Eureka Server相互注册，组成一个集群

每个Eureka Server注册的消息发生变化时，会各个服务之间定时同步，中间过程每个服务的数据可能不一致，但是最终会变得一致 . Eureka Server集群之间的状态是采用异步方式同步的，所以不保证节点间的状态一定是一致的，不过基本能保证最终状态是一致的。

集群重要的类com.netflix.eureka.registry.PeerAwareInstanceRegistryImpl

为了保证集群里所有Eureka Server节点的状态同步，所有以下操作都会同步到集群的所有服务上：服务注册（Registers）、服务更新（Renewals）、服务取消（Cancels）,服务超时（Expirations）和服务状态变更（Status Changes）。

Server端发生的操作:

syncUp：在Eureka Server重启或新的Eureka Server节点加进来的，会执行初始化，从而能够正常提供服务。当Eureka server启动时，他会从其它节点获取所有的注册信息。如果获取同步失败，它在一定时间（此值由决定）内拒绝服务。
replicateToPeers：复制所有的eureka操作到集群中其他节点，请求再次转发到其它的Eureka Server，调用同样的接口，传入同样的参数，除了会在header中标记isReplication=true，从而避免重复的replicate
register: 注册登录的实例，并且复印此实例的信息到所有的eureka server的节点。如果其它Eureka server调用此节点，只在本节点更新实例信息，避免通知其他节点执行更新

当有新的节点加入到集群中，会对现在Eureka Server和Eureka Client有什么影响以及他们如何发现新增的Eureka Server节点：

新增的Eureka Server：在Eureka Server重启或新的Eureka Server节点加进来的，它会从集群里其它节点获取所有的实例注册信息。如果获取同步失败，它会在一定时间（此值由决定决定）内拒绝服务。
已有Eureka Server如何发现新的Eureka Server:

已有的Eureka Server：在运行过程中，Eureka Server之间会定时同步实例的注册信息。这样即使新的Application Service只向集群中一台注册服务，则经过一段时间集群中所有的Eureka Server都会有这个实例的信息。那么Eureka Server节点之间如何相互发现，各个节点之间定时（时间由eureka.server.peer-eureka-nodes-update-interval-ms决定）更新节点信息，进行相互发现。
Service Consumer：Service Consumer刚启动时，它会从配置文件读取Eureka Server的地址信息。当集群中新增一个Eureka Server中时，那么Service Consumer如何发现这个Eureka Server？Service Consumer会定时（此值由eureka.client.eureka-service-url-poll-interval-seconds决定）调用Eureka Server集群接口，获取所有的Eureka Server信息的并更新本地配置。