SpringCloud解析之Eureka

本文基于Spring Cloud Edgware.SR6版本,从功能和架构上解析Eureka,让大家对Eureka有一个较为清晰的认识(本文默认大家对分布式微服务有一个初步的概念和理解,本文不涉及或少量涉及源码)。

官方概念这里就不贴了,个人理解,Eureka是Spring Cloud分布式微服务架构的服务治理方案之一,提供服务注册,服务发现,服务维护和治理,注册中心集群等功能。

image

Eureka中维护一份服务列表,当客户端(服务提供者或服务消费者)注册服务实例到Eureka,Eureka会将其实例信息维护到列表中,这叫创建租约;租约的有效时间默认是30秒,客户端需要每隔一段时间发送一次心跳告知Eureka自己的服务正常有效,这叫续约。

Eureka是服务注册中心,但当注册中心集群时,Eureka也做为客户端,向其它注册中心注册自己,同时获取其它注册中心的维护的服务列表,当有新的客户端注册进来时,Eureka会通知其它的注册中心,异步更新服务列表,达到高可用的目的。Eureka默认会开启如下配置,如果作为单个注册中心或本地测试,可以关闭。

eureka:
  client:
#   不向Eureka注册自己
    registerWithEureka: false
#     不获取服务列表
    fetchRegistry: false

客户端正常下线时,会通知Eureka,Eureka就从服务列表中将其剔除。如果客户端非正常下线(比如宕机,系统崩溃)无法通知到Eureka,Eureka会定时检查自己的服务列表,发现有服务的租约超过有效时间,也会认为服务失效而剔除。

Eureka默认配置会开启一个保护机制,当一段时间内有超过15%的服务失效时,Eureka不会剔除这些服务,而是继续维护在服务列表,直到客户端重新发送心跳。Eureka有一个心跳次数阀值系数=0.85(可以通过配置修改),客户端默认心跳间隔=30秒,1分钟内总心跳数=客户端实例数*2,1分钟内心跳阀值=1分钟内总心跳数*0.85,当1分钟内有效客户端实例的心跳总数<心跳阀值,Eureka就会因为保护机制而继续维护在服务列表,因此客户端需要有重试和熔断机制。

Eureka和ZooKeeper

Eureka和ZooKeeper,虽然都是服务集群治理的实现方案,但是区别也是比较明显的。CAP理论中,C(consistency)数据一致性,A(availability)可用性,P(partition-tolerance)分区容错性,Eureka强调AP,通过缓存和异步同步达到最终一致性,ZooKeeper更兼顾CP,当节点失效就会剔除。

个人更倾向Eureka,不管是服务注册和发现,还是注册中心集群,只需要引入依赖包,添加配置和注解,就可以达到效果,同时不得不佩服Spring Boot和Spring Cloud的强大。但是,如果是ZooKeeper转使用Eureka,可能会因为其内部的缓存和保护机制感到别扭,此处贴上本人的配置,可以减少缓存时效,提高缓存刷新频率,强制关闭客户端的话,大概30秒Eureka就会剔除服务(Eureka默认情况下大概要4分钟才会剔除服务),供大家参考

Eureka注册中心配置(YML)

eureka:
  server:
#     检查失效服务剔除时间间隔
    evictionIntervalTimerInMs: 2000
#   关闭保护机制
    enableSelfPreservation: false

Eureka客户端(properties)

#服务实例租约有效时间
eureka.instance.lease-expiration-duration-in-seconds=15
#服务实例续约间隔时间(心跳间隔)
eureka.instance.lease-renewal-interval-in-seconds=5
#客户端更新服务列表间隔时间
eureka.client.registryFetchIntervalSeconds=5
posted @ 2019-06-04 11:08  wangl110  阅读(294)  评论(0编辑  收藏  举报