微服务实战学习笔记(2)-Eureka详解

Eureka详解

基础架构

Eureka服务治理基础架构的三个核心要素:

1. 服务注册中心: Eureka提供的服务端,提供服务的注册与发现功能
2. 服务提供者: 提供服务的应用,可以是Spring Boot应用,也可以是其他技术平台但遵循Eureka通信机制的应用,将自身注册到注册中心,以供其他应用发现
3. 服务消费者: 消费应用从注册中心获取服务列表,从而使消费者知道可以去哪里调用所需服务(Ribbon,Feign等方式)

服务治理机制

此图来自Spring Cloud微服务实战

服务提供者

服务注册

服务提供者在启动的时候会通过发REST请求的方式将自己注册到Eureka Server上,同时也带上了自身服务的一些元数据,Eureka Server接受到这个REST请求后,将元数据保存一个双层嵌套Map中,其中第一层的Key是服务名,第二层的Key是具体服务的实例名.

在服务注册时,需要确认eureka.client.register-with-eureka=true参数是否正确,该值默认为true,设置为false后将不会启动注册操作.

服务续约

在注册完服务之后,服务提供者会维护一个心跳来持续通知注册中心,以防注册中心的剔除任务将该服务实例从注册列表上剔除出去,我们称该操作为服务续约(Renew).服务续约有两个重要属性

• eureka.instance.lease-renewal-interval-in-seconds=30 用于定义续约任务的间隔时间
• eureka.instance.lease-expiration-duration-in-seconds=90 用于定义服务关闭的失效时间

服务消费者

获取服务

启动消费者的时候,它会向注册中心发送一个REST请求,获取到上面注册的服务清单.为了性能考虑,Eureka Server会维护一个只读的清单返回给客户端,同时该缓存清单会每30秒更新一次.

获取服务是消费者的基础,所以必须确保eureka.client.fetch-registry=true参数没有被设置成false,若希望修改缓存清单的更新时间,可以通过eureka.client.registry-fetch-interval-seconds=30参数进行修改.

服务调用

消费者在获取服务清单后,通过服务名可以获得具体服务实例的实例名及相关元数据信息.因为有这些服务的实例详细信息,所以客户端可以根据自己的需要决定具体调用哪个实例,在Ribbon中会默认采用轮询的方式进行调用,从而实现客户端的负载均衡.

对于访问实例的选择,Eureka中有region和zone的概念,一个region可以包含多个zone,每个服务客户端需要被注册到一个zone中,所以每个客户端对应一个region和zone,所以在进行服务调用的时候会优先访问同一个zone的服务提供方,若访问不到再访问其他的zone.

服务下线

当服务进行正常的关闭操作时,它会触发一个服务下线的REST请求给Eureka Server,告诉服务注册中心"我要下线了".服务在接受到请求之后,会将该服务状态置为下线(DOWN),并把下线事件传播出去.

服务注册中心

失效剔除

有些时候,服务实例并不一定会正常下线,而注册中心没有收到服务下线的请求,为了从服务列表中将这些失效的实例剔除,Eureka Server会创建一个定时任务,以一定时间间隔清除服务清单中的失效实例.

自我保护

Eureka Server会统计收到服务提供者的心跳信号的比例,如果低于一定的比例(85%),则说明出现了网络不稳定的情况等,Eureka Server会启动保护机制,将注册信息保护起来,让这些实例不会过期,尽可能保护这些信息.

同时,在保护启动的期间内,客户端有可能会拿到实际已经不存在的服务实例,出现调用失败的情况,所以客户端必须要有容错机制,比如可以使用请求重试,断路器等机制.

本地开发调试的时候很容易触发注册中心的保护机制,可以使用eureka.server.enable-self-preservation=false参数来关闭保护机制,以确保注册中心可以将不可用的实例正确剔除.

服务同步

如图所示,两个服务提供者分别注册到了两个不同的服务注册中心上,也就是说,它们的信息分别被两个服务注册中心所维护.服务注册中心之间相互注册为服务,当服务提供者向一个注册中心发送注册请求时,它(注册中心)会将该请求转发到集群中其他的注册中心上,从而实现注册中心之间的服务同步.