本文讲述的是 Eureka server, 服务提供者、消费者的一些概念和配置说明。
Eureka Server 服务注册中心
Eureka的高可用设计
- Eureka侧重点是AP,高可用;Eureka Server在设计的时候就考虑了高可用,在Eureka的服务治理设计中,所有节点既是服务提供方,又是服务的消费方。
Eureka Server的高可用就是将自己的作为服务向其他服务注册中心注册自己,这样就形成一组互相注册的服务注册中心中心,以实现服务与服务之间的互相同步,达到高可用的效果(通俗一点就是:注册中心集群)
失效剔除
有时候,服务实例不一定会正常下线,而注册中心没有收到服务下线的请求,为了从列表中将这些无法提供服务的实例剔除,Eureka Server在启动的时候回创建一个定时任务,默认每隔一段时间(默认60s)将的当前服务中超时(默认90s)没续约得服务剔除出去。
自我保护
服务注册到Eureka Server后,会维护一个心跳连接,告诉Eureka Server 自己还活着。Eureka Server在运行期间会统计心跳失败的比例在15min以内是否低于85%;如果低于这种情况,Eureka Server会将当前注册的服务实例保护起来,让这些服务不会过期。这样做会使客户端容易拿到实际已经不存在的服务实例,会出现时而调用成功,时而失败的情况。
自我保护的相关属性配置
eureka.server.enableSelfPreservation=true # 可以设置改参数值为false,以确保注册中心将不可用的实例删除
安全验证
- 添加spring security依赖
<dependency> <groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
- 在 serviceurl添加安全校验信息
eureka.client.serviceUrl.defaultZone=http://<username>:<password>@${eureka.instance.hostname}:${server.port}/eureka/
服务提供者
服务注册
服务提供者在服务启动的时候会以rest的方式将自己注册到Eureka Server上,同时带上自身服务的一些元数据信息。Eureka Server接收到这个rest请求后,将元数据存储到一个双层结构的Map中,其中,第一层的key是服务名,第二层的key是具体的服务实例名。
在服务注册时,需要确认一下eureka.client.register-with-eureka=true
是否正确,该配置默认是true,如果设置成false
,则不会向注册中心注册该服务;
服务同步
从eureka服务治理体系架构图中可以看到,不同的服务提供者可以注册到不同非注册中心上,他们的信息呗不同的服务注册中心中心维护。
服务同步也就是不同的服务注册中心的数据相互同步。
服务续约
在服务注册之后,服务提供者会维护一个心跳来持续通知
Eureka server。否则eureka server的剔除任务会将该服务实例从服务列表中排除出去。
下面是服务续约的两个重要属性
eureka.instance.lease-expiration-duration-in-seconds
# leaseExpirationDurationInSeconds 表示Eureka server至少上一次收到client的心跳后,等待下一次心跳的超时时间,在这个时间如果没有收到下一次心跳,则将移除该服务实例。
# 默认时间是90s,
# 如果该值设置的过大,很可能会将请求转发过去的时候,该服务实例已经挂了
# 如果该值设置的过小,则这个服务实例可能会因为临时的网络波动而被剔除。
# 该值至少应该大于leaseRenewalIntervalInSeconds
eureka.instance.lease-renewal-interval-in-seconds
leaseRenewalIntervalInSeconds
表示eureka client 发送心跳给server的频率(默认30s),如果在leaseExpirationDurationInSeconds
后,server端没有收到client端的心跳,则将剔除这个服务实例,除此之外,如果这个示例实现了HealthCheckCallback
,并决定由自让自己unavaliable,这个示例也将不会收到请求
服务消费者
获取服务
消费者启动的时候,会发送rest请求从Eureka server 中获取到上面注册的服务列表。为了性能考虑,Eureka server会维护一份只读的服务注册清单返回给客户端,同时该缓存清单默认会每隔30s更新一次。
下面是获取服务的两个重要属性:
#是否需要去检索寻找服务,默认是true
eureka.client.fetch-registry
# 表示Eureka client间隔多久去拉一次服务注册信息,默认是30s。
eureka.client.registry-fetch-interval-seconds
服务调用
消费者在获取到服务清单后,通过服务名可以获取到具体的实例名和该实例的元数据信息,有了这些服务实例的详细信息,客户端可以根据自己的实际需要巨鼎调用哪个实例。Ribbon,feign实现服务调用的负载均衡。
服务下线
在系统的运行过程中,会出现关闭或重启某个示例的情况,在服务关闭操作时,会触发一个服务下线的rest请求给Eureka server,告诉server‘我要下线’。Eureka server 在接到该请求后,将服务状态下线。并同步到注册中心的其他节点
配置详解
服务实例类配置
端点配置
元数据
元数据是Eureka客户端向注册中心发送注册请求时,用来描述自身服务信息的对象,其中包含了一些标准化的元数据,比如服务名称、实例名称、实例ip、示例端口等用来服务治理的重要信息,以及一些用于负载均衡策略或是其他特殊用途的自定义元数据信息。
我们可以通过eureka.instance.<properties>=<value>的格式来对标准化元数据进行配置
,其中 properties
就是EurekaInstanceConfigBean
对象中的成员变量。而对于自定义元数据,可以通过eureka.instance.metadataMap.<key>=<value>
的格式来配置比如:eureka.instance.metadataMap.zone=tianjin
健康检测
默认情况下,Eureka中的各个服务实例的健康检测并不是通过spring-boot-acturator
模块的/health端点来实现的,二十依靠客户端心跳的方式来保持服务实例的存活。在Eureka的服务续约与剔除机制下,客户端的健康状态从注册到注册中心开始都会处于up状态,除非心跳中指一段时间之后,服务注册中心将其剔除。默认的心跳实现方式可以有效检查客户端进程是否正常运作,但却无法保证客户端应用能够正常提供服务。
在spring cloud Eureka 中,可以把eureka客户端的健康检测交给spring-boot-actuator
。可以实现更加全面的健康状态维护,设置方式如下
(1)在pom.xml中引入spring-boot-starter-actuator模块的依赖
(2)在application.properties中增加参数配置eureka.client.healthcheck.enabled=true
通讯协议
默认情况下,Eureka使用Jersey和XStream配合JSON作为Server与Client之间的通讯协议。也可以选择实现自己的协议来代替。