推荐:微服务汇总
Eureka工作原理
上节内容为大家介绍了,注册中心Eureka的使用,以及如何利用Eureka搭建单台和集群的注册中心。这节课我们来继续学习Eureka,了解它的相关概念、工作流程机制等。
Eureka作为Spring Cloud体系中最核心、默认的注册中心组件,研究它的运行机制,有助于我们在工作中更好地使用它。
Eureka 核心概念
回到上节的服务注册调用示意图,服务提供者和服务消费者,本质上也是Eureka Client 角色。整体上可以分为两个主体:Eureka Server和Eureka Client。
Eureka Server - 注册中心服务端
注册中心服务端主要对外提供了三个功能:
- 服务注册:服务提供者启动时,会通过Eureka Client向 Eureka Server注册信息,Eureka Server会存储该服务的信息,Eureka Server内部有二层缓存机制来维护整个注册表。
- 提供注册表:服务消费者在调用服务时,如果Eureka Client没有缓存注册表的话,会从Eureka Server获取最新的注册表。
- 同步状态:Eureka Client通过注册、心跳机制和Eureka Server同步当前客户端的状态。
Eureka Clien - 注册中心客户端
Eureka Client是一个Java客户端,用于简化与Eureka Server的交互。Eureka Client会拉取、更新和缓存Eureka Server中的信息。因此当所有的Eureka Server节点都宕掉,服务消费者依然可以使用缓存中的信息找到服务提供者,但是当服务有更改的时候会出现信息不一致。
- Register(服务注册):服务提供者,将自身注册到注册中心,服务提供者也是一个Eureka Client。当Eureka Client向Eureka Server注册时,它提供自身的元数据,比如 IP 地址、端口,运行状况指示符 URL,主页等。
- Renew(服务续约):Eureka Client会每隔
30
秒发送一次心跳来续约。 通过续约来告知Eureka Server该Eureka Client运行正常,没有出现问题。 默认情况下,如果Eureka Server在90
秒内没有收到Eureka Client的续约,Eureka Server会将实例从其注册表中删除,此时间可配置,一般情况不建议更改。
服务续约的两个重要属性
Eviction 服务剔除
当Eureka Client和Eureka Server不再有心跳时,Eureka Server会将该服务实例从服务注册列表中删除,即服务剔除。
Cancel 服务下线
Eureka Client在程序关闭时向Eureka Server发送取消请求。 发送请求后,该客户端实例信息将从 Eureka Server的实例注册表中删除。该下线请求不会自动完成,它需要调用以下内容:
GetRegisty 获取注册列表信息
Eureka Client从服务器获取注册表信息,并将其缓存在本地。客户端会使用该信息查找其他服务,从而进行远程调用。该注册列表信息定期(每30秒钟)更新一次。每次返回注册列表信息可能与 Eureka Client的缓存信息不同,Eureka Client自动处理。
如果由于某种原因导致注册列表信息不能及时匹配,Eureka Client则会重新获取整个注册表信息。 Eureka Server缓存注册列表信息,整个注册表以及每个应用程序的信息进行了压缩,压缩内容和没有压缩的内容完全相同。Eureka Client和Eureka Server可以使用 JSON/XML 格式进行通讯。在默认情况下Eureka Client使用压缩JSON格式来获取注册列表的信息。
获取服务是服务消费者的基础,所以必有两个重要参数需要注意:
Remote Call 远程调用
当Eureka Client从注册中心获取到服务提供者信息后,就可以通过HTTP请求调用对应的服务;服务提供者有多个时,Eureka Client会通过Ribbon自动进行负载均衡。
自我保护机制
默认情况下,如果Eureka Server在90
秒内没有接收到某个服务实例的心跳,会注销该实例。但是在微服务架构下服务之间通常都是跨进程调用,网络通信往往会面临着各种问题,比如微服务状态正常,却因为网络分区故障,导致此实例被注销。
固定时间内大量实例被注销,可能会严重威胁整个微服务架构的可用性。为了解决这个问题,Eureka 开发了自我保护机制,那么什么是自我保护机制呢?
Eureka Server在运行期间会去统计心跳失败比例,在15
分钟之内是否高于85%
,如果高于85%
,Eureka Server即会进入自我保护机制。
Eureka Server触发自我保护机制后,页面会出现提示:
Eureka Server进入自我保护机制,会出现以下几种情况:
- Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
- Eureka Server仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)。
- 当网络稳定时,当前实例新的注册信息会被同步到其它节点中。
Eureka Server自我保护机制是为了防止误杀服务而提供的一个机制。当个别客户端出现心跳失联时,则认为是客户端的问题,剔除掉客户端;当Eureka Server捕获到大量的心跳失败时,则认为可能是网络问题,进入自我保护机制;当客户端心跳恢复时,Eureka Server会自动退出自我保护机制。
如果在自我保护期内刚好这个服务提供者非正常下线了,此时服务消费者就会拿到一个无效的服务实例,即会调用失败。对于这个问题需要服务消费者端要有一些容错机制,如重试,断路器等。
通过在Eureka Server配置如下参数,开启或者关闭保护机制,生产环境建议打开:
Eureka 集群原理
再来看看Eureka集群的工作原理。我们假设有三台Eureka Server组成的集群,第一台Eureka Server 在北京机房,另外两台Eureka Server在深圳和西安机房。这样三台Eureka Server就组建成了一个跨区域的高可用集群,只要三个地方的任意一个机房不出现问题,都不会影响整个架构的稳定性。
从图中可以看出Eureka Server集群相互之间通过Replicate来同步数据,相互之间不区分主节点和从节点,所有的节点都是平等的。在这种架构中,节点通过彼此互相注册来提高可用性,每个节点需要添加一个或多个有效的serviceUrl
指向其他节点。
如果某台Eureka Server宕机,Eureka Client的请求会自动切换到新的Eureka Server节点。当宕机的Eureka Server重新恢复后,Eureka会再次将其纳入到Eureka Server集群管理之中。当节点开始接受客户端请求时,所有的操作都会进行节点间复制,将请求复制到其它Eureka Server中(当前所知的所有节点)。
另外,Eureka Server的同步遵循着一个非常简单的原则:只要有一条边将节点连接,就可以进行信息传播与同步。所以,如果存在多个节点,只需要将节点之间两两连接起来形成通路,那么其它注册中心都可以共享信息。每个Eureka Server同时也是Eureka Client,多个Eureka Server之间通过P2P的方式完成服务注册表的同步。
Eureka Server集群之间的状态是采用异步方式同步的,所以不保证节点间的状态一定是一致的,不过基本能保证最终状态是一致的。
Eureka 分区
Eureka提供了Region
和Zone
两个概念来进行分区,这两个概念均来自于亚马逊的 AWS:
-
region
:可以理解为地理上的不同区域,比如亚洲、中国或者深圳等。没有具体大小的限制。根据项目具体的情况,可以自行合理划分region
。 -
zone
:可以简单理解为region
内的具体机房,比如说region
划分为深圳,然后深圳有两个机房,就可以在此region
之下划分出zone1
、zone2
两个zone
。
上图中的us-east-1c
、us-east-1d
、us-east-1e
就代表了不同的Zone
。Zone
内的Eureka Client优先和Zone
内的Eureka Server进行心跳同步,同样调用端优先在Zone
内的Eureka Server获取服务列表,当Zone
内的Eureka Server挂掉之后,才会从别的Zone
中获取信息。
Eurka 保证AP
Eureka Server各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka Client在向某个Eureka Server注册时,如果发现连接失败,则会自动切换至其它节点。只要有一台Eureka Server还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。
Eurka 工作流程
了解完Eureka核心概念,自我保护机制,以及集群内的工作原理后,我们来整体梳理一下Eureka的工作流程:
- Eureka Server启动成功,等待客户端注册。在启动过程中如果配置了集群,集群之间定时通过 Replicate同步服务注册表,每个Eureka Server都存在独立完整的服务注册表信息。
- Eureka Client启动时根据配置的Eureka Server地址去注册中心注册服务。
- Eureka Client会每
30
秒向Eureka Server发送一次心跳请求,证明客户端服务正常。 - 当Eureka Server有
90
秒没有收到Eureka Client的心跳,注册中心则认为该节点失效,会注销该实例。 - 单位时间内Eureka Server统计到有大量的Eureka Client没有发送心跳,则认为可能存在网络异常,进入自我保护机制,不再剔除没有发送心跳的客户端。
- 当Eureka Client心跳请求恢复正常之后,Eureka Server自动退出自我保护模式。
- Eureka Client定时全量或者增量从注册中心获取服务注册表,并且将获取到的信息缓存到本地。
- 服务调用时,Eureka Client会先从本地缓存中寻找需要调用的服务。如果获取不到,先从注册中心刷新注册表,再同步到本地缓存。
- Eureka Client获取到目标服务信息后,发起服务调用。
- Eureka Client程序关闭时向Eureka Server发送取消请求,Eureka Server将实例从注册表中删除。
这就是Eurka基本工作流程。
总结
讲了Eureka核心概念、Eureka自我保护机制和Eureka集群原理。通过分析Eureka工作原理,我可以明显地感觉到Eureka的设计之巧妙,通过一系列的机制,完美地解决了注册中心的稳定性和高可用性。
Eureka为了保障注册中心的高可用性,容忍了数据的非强一致性,服务节点间的数据可能不一致, Eureka Client和Eureka Server间的数据可能不一致。比较适合跨越多机房、对注册中心服务可用性要求较高的使用场景。