Spring Cloud Eureka 原理

Spring Cloud Eureka 原理

概述

所有的注册中心都需要两个核心功能：

• 1、地址统一维护
• 2、服务的上下线感知

注册中心核心原理：

• 推送发送：push / pull
• 存储：持久化
• 高可用机制：集群特性 -> 选举特性、 一致性问题
• cap特性：cp 、ap
• api的提供形式：http协议、 netty通信

一、Eureka的整体架构

Eureka Netflix 服务注册与发现的中间件Spring Cloud 2020版本中唯一留下的组件，整体架构如下。

• Application Service： 作为Eureka Client，扮演了服务的提供者，提供业务服务，向Eureka Server注册和更新自己的信息，同时能从Eureka Server的注册表中获取到其他服务的信息。

  • 服务注册， Eureka Client 发送REST请求向Eureka Server注册自己的服务，提供自身的元数据，比如ip:port，url，Eureka Server接收请求后存储在一个双层的Map中。
  • 服务续约-Renew，默认每隔30s发送一次心跳到Server维持和更新注册表中的服务实例元数据的有效性。当在一定时长内Server没有收到Client的心跳信息，将默认服务下线，将服务实例的信息从注册表中删除。

• Application Client： 作为Eureka Client，扮演了服务消费者，通过Eureka Server获取到注册到上面的其他服务的信息，从而根据信息找到所需的服务发起远程调用。

  • 服务发现，Eureka Client在启动时， 发送REST请求向Eureka Server取到注册到上面的其他服务的信息，并缓存在本地，默认30s轮询一次。
  • 服务调用，进行远程调用，一个Region可以包含多个Zone，优先调用同一个Zone的服务

• Eureka Server： 扮演服务注册中心的角色，提供服务注册和发现的功能，每个Eureka Client向Eureka Server注册自己的信息，也可以通过Eureka Server获取到其他服务的信息达到发现和调用其他服务的目的。

  • Replicate：服务同步，Eureka Server直接相互注册构建集群，注册表信息的同步拷贝，保持不同的Eureka Server集群中的注册表中的服务实例信息的一致性。提供了数据的最终一致性。

  • Cancel： 服务下线，Client在关闭时主动向Server注销服务实例元数据，这时Client的的服务实例数据将从Server的注册表中删除。

  • 服务剔除，Client由于网络原因，没有发送请求给Server来进行服务下线，Eureka Server会每60秒遍历一次注册表中的信息，把超过90秒还没有续约的服务剔除。

二、服务注册发现的流程

注册：

• 1、读取eureka server的地址信息和自己的配置信息，
• 2、然后将自己的信息封装在InstanceInfo实例中，
• 3、先把eureka server中的注册拉取到本地缓存起来
• 4、将封装的InstanceInfo实例发送到eureka server进行注册，然后初始化心跳检测以及缓存刷新
• 5、再次拉取注册表更新本地注册表信息

发现：

Eureka Client在启动时， 发送REST请求向Eureka Server取到注册到上面的其他服务的信息，并缓存在本地，默认30s轮询一次。

三、如何判断一个服务不可用(心跳)

在每一个Eureka Client启动的时候，都会有一个HeartbeatThread的心跳线程，保证默认每隔30秒的时候向Eureka Server发送一个心跳，告诉Eureka Server当前的Eureka Client还存活着。eureka.instance.lease-renewal-interval-in-seconds，这个参数可以来配置对应的心跳间隔时间。

Eureka Server在接收到请求之后，先去自己的注册表中去，找到请求的对应的服务信息，在这个服务信息里面有个Lease的对象，更新Lease对象里面的LastUpdateTimestamp时间戳，每一次接收到都会更新这个时间戳的（Renew 续约）

Eureka Server会每60秒遍历一次注册表中的信息，然后查看注册表中的信息是否有过期的，如果90秒还没有更新对应的LastUpdateTimestamp就表示这个服务过期（从注册表中删除注册信息）。

//可以配置心跳检测的时间间隔
eureka.server.evictionIntervalTimerInMs
//90秒过期的配置
eureka.instance.lease-expiration-duration-in-seconds 

整体原理：

四、Eurka的自我保护机制

Eureka Server在运行期间会去统计心跳失败的比例在15分钟之内是否低于85% 如果发现85%以上的服务都没有心跳，Eureka Server会认为当前实例的客户端与自己的心跳连接出现了网络故障，那么Eureka Server会把这些实例保护起来，让这些实例不会过期导致实例剔除。

这样做的目的是为了减少网络不稳定或者网络分区的情况下，Eureka Server将健康服务剔除下线的问题。 使用自我保护机制可以使得Eureka 集群更加健壮和稳定的运行。

进入自我保护状态后，会出现以下几种情况

• Eureka Server不再从注册列表中移除因为长时间没有收到心跳而应该剔除的过期服务
• Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上，保证当前节点依然可用。

protected volatile int numberOfRenewsPerMinThreshold; //每分钟最小续约数量
protected volatile int expectedNumberOfClientsSendingRenews; //预期每分钟收到续约的
客户端数量，取决于注册到eureka server上的服务数量

Eureka的自我保护机制，都是围绕上面这两个变量来实现的。

五、Eurka信息存储原理多级缓存设计

六、zk和eureka的区别

zk：是CP模型设计，目的是一个分布式协调系统，用于进行资源的统一管理，当节点挂了之后，需要进行leader选举（zab协议），在这个期间服务不可用。
eureka：是AP模型设计，目的服务注册发现系统，用于进行服务的注册发现，eureka各个节点是平等的，几个节点挂了不影响正常节点工作，当eureka客户端发现连接失败后会自动切换到其他正常节点，只要一台eureka节点还在，就能保证服务注册发现可用，只不过查到的信息可能不是最新的，不保证强一致性。

Eureka Server在运行期间会去统计心跳失败的比例在15分钟之内是否低于85% 如果发现85%以上的服务都没有心跳，Eureka Server会认为当前实例的客户端与自己的心跳连接出现了网络故障，那么Eureka Server会把这些实例保护起来，让这些实例不会过期导致实例剔除。