Eureka详解
一个服务既可以做为消费者也可以作为服务者
服务消费者模式
获取服务
消费者启动的时候,使用服务别名,会发送一个rest请求到服务注册中心获取对应的服务信息,让后会缓存到本地jvm客户端中,同时客户端每隔30秒从服务器上更新一次。
可以通过registry-fetch-interval-seconds=30参数进行修改。
服务下线
在系统运行过程中必然会面临关闭或重启服务的某个实例的情况,在服务关闭期有我们自然不希望客户端会继续调用关闭了的实例。所以在客户端程序中,当服务实例过正常的关闭操作时,它会触发一个服务下线的REST请求给Eureka Server, 告诉服务日中心:“我要下线了”。服务端在接收到请求之后,将该服务状态置为下线(DOWN),井该下线事件传播出去。
如果服务提供者真的宕机了,消费者调用应该重试机制,保证接口网络延迟幂等性、服务降级功能。
服务注册模式
失效剔除
有些时候,我们的服务实例并不一定会正常下线,可能由于内存溢出、网络故障气因使得服务不能正常工作,而服务注册中心并未收到“服务下线”的请求。为了从服务表中将这些无法提供服务的实例剔除,Eureka Server 在启动的时候会创建一个定时任多默认每隔一一段时间(eviction-interval-timer-in-ms,默认为60秒)将当前清单中超时(lease-expiration-duration-in-seconds 默认为90秒)没有续约的服务除出去
自我保护
默认情况下,EurekaClient会定时向EurekaServer端发送心跳,如果EurekaServer在一定时间内没有收到EurekaClient发送的心跳,便会把该实例从注册服务列表中剔除(默认是90秒),但是在短时间内丢失大量的实例心跳,这时候EurekaServer会开启自我保护机制,Eureka不会踢出该服务。
为什么这么设计?为了防止EurekaClient是可以正常访问。但是只是Eureka client与Eureka server网络之间访问不通。防止误剔除。
为什么开发阶段产生自我保护的原因:
在开发测试时,需要频繁地重启微服务实例,但是我们很少会把eureka server一起重启(因为在开发过程中不会修改eureka注册中心),当一分钟内收到的心跳数大量减少时,会触发该保护机制。可以在eureka管理界面看到Renews threshold和Renews(last min),当后者(最后一分钟收到的心跳数)小于前者(心跳阈值)的时候,触发保护机制,会出现红色的警告:
EMERGENCY!EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT.RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEGING EXPIRED JUST TO BE SAFE.
关闭服务保护
Eureka服务器端配置
###服务端口号
server:
port: 8100
##定义服务名称
spring:
application:
name: app-itmayiedu-eureka
eureka:
instance:
###注册中心ip地址
hostname: 127.0.0.1
client:
serviceUrl:
##注册地址
defaultZone: http://${eureka.instance.hostname}:8100/eureka/
####因为自己是注册中心,是否需要将自己注册给自己的注册中心(集群的时候是需要是为true)
register-with-eureka: false
###因为自己是注册中心, 不需要去检索服务信息
fetch-registry: false
server:
# 测试时关闭自我保护机制,保证不可用服务及时踢出
enable-self-preservation: false
##剔除失效服务间隔
eviction-interval-timer-in-ms: 2000
核心配置
server:
# 测试时关闭自我保护机制,保证不可用服务及时踢出
enable-self-preservation: false
##剔除失效服务间隔,默认60000毫秒,即60秒
eviction-interval-timer-in-ms: 2000
我理解:
enable-self-preservation
如果开启了自我保护机制,出现大量检测不到心跳时,Eureka就不会踢出该服务。
导致不能剔除那些失效的服务了。
eviction-interval-timer-in-ms
eureka server清理无效节点的时间间隔,默认60000毫秒,即60秒
Eureka客户端配置
###订单服务的端口号
server:
port: 8001
###服务别名----服务注册到注册中心名称
spring:
application:
name: app-itmayiedu-order
eureka:
client:
service-url:
##### 当前会员服务注册到eureka服务地址
# defaultZone: http://localhost:8100/eureka,http://localhost:9100/eureka
defaultZone: http://localhost:8100/eureka
### 需要将我的服务注册到eureka上
register-with-eureka: true
####需要检索服务
fetch-registry: true
# 表示eureka client间隔多久去拉取服务注册信息,默认为30秒,对于api-gateway,如果要迅速获取服务注册状态,可以缩小该值,比如5秒
registry-fetch-interval-seconds: 30
# 心跳检测检测与续约时间
# 测试时将值设置设置小些,保证服务关闭后注册中心能及时踢出服务
instance:
###Eureka客户端向服务端发送心跳的时间间隔,单位为秒(客户端告诉服务端自己会按照该规则)
lease-renewal-interval-in-seconds: 1
####Eureka服务端在收到最后一次心跳之后等待的时间上限,单位为秒,超过则剔除(客户端告诉服务端按照此规则等待自己)
lease-expiration-duration-in-seconds: 2
核心配置
# 心跳检测检测与续约时间
# 测试时将值设置设置小些,保证服务关闭后注册中心能及时踢出服务
instance:
###Eureka客户端向服务端发送心跳的时间间隔,单位为秒(客户端告诉服务端自己会按照该规则)
lease-renewal-interval-in-seconds: 1
####Eureka服务端在收到最后一次心跳之后等待的时间上限,单位为秒,超过则剔除(客户端告诉服务端按照此规则等待自己)
lease-expiration-duration-in-seconds: 2
lease-renewal-interval-in-seconds:
leaseRenewalIntervalInSeconds,表示eureka client发送心跳给server端的频率。如果在leaseExpirationDurationInSeconds后,server端没有收到client的心跳,则将摘除该instance。除此之外,如果该instance实现了HealthCheckCallback,并决定让自己unavailable的话,则该instance也不会接收到流量。
默认30秒
lease-expiration-duration-in-seconds:
leaseExpirationDurationInSeconds,表示eureka server至上一次收到client的心跳之后,等待下一次心跳的超时时间,在这个时间内若没收到下一次心跳,则将移除该instance。
默认为90秒
如果该值太大,则很可能将流量转发过去的时候,该instance已经不存活了。
如果该值设置太小了,则instance则很可能因为临时的网络抖动而被摘除掉。
该值至少应该大于leaseRenewalIntervalInSeconds
最后理解:
1.registry-fetch-interval-seconds, eureka client客户端默认30s去服务端拉服务注册信息(应该是eureka client服务消费者)
2.服务提供者eureka client客户端,lease-renewal-interval-in-seconds 默认30s向eureka server服务端发送心跳检测(eureka client服务提供者)
Eureka server服务端默认60s,eviction-interval-timer-in-ms 去扫描剔除那些无效提供服务的Eureka client,当一个服务90s,lease-expiration-duration-in-seconds (ureka client服务提供者设置)还没有收到心跳检测,则证明服务提供client不可用,剔除这个服务提供者client。
使用Eureka闭源了怎么办?
Eureka闭源了,可以使用其他的注册代替:Consul、Zookeeper
资料
Last updated
Was this helpful?