Eureka的使用原理

1、注册中心-Eureka

1.1、前言

SpringCloud 是一系列框架的有序集合。它利用Spring Boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务注册、配置中心、消息总线、负载均衡、断路器、数据监控等。都可以使用Spring Boot 的开发风格做到一键启动和部署。

1.2、简单介绍

Eureka 是 Netflix 的子模块，它是一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移。

服务注册和发现对于微服务架构而言，是非常重要的。有了服务发现和注册，只需要使用服务的标识符就可以访问到服务，而不需要修改服务调用的配置文件。该功能类似于 Dubbo 的注册中心，比如 Zookeeper。

Eureka 采用了 CS 的设计架构。Eureka Server 作为服务注册功能的服务端，它是服务注册中心。而系统中其他微服务则使用 Eureka 的客户端连接到 Eureka Server 并维持心跳连接。

其运行原理如下图：

Eureka 的运行原理和 Dubbo 大同小异，Eureka 包含两个组件：Eureka Server(服务注册中心) 和 Eureka Client(服务提供者)。

1.2.1、Eureka Server 注册中心服务端。

各个服务节点启动后会在 Eureka Server中注册服务,Eureka Server 中的服务注册表会存储所有可用的服务节点信息。

最新版的Eureka-Server与之前的版本的区别的在于：以前的版本没有将 server 和 client 区分开。
<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
        </dependency>

注册中心服务端主要对外提供了三个功能：

1.2.1.1、服务注册

服务提供者启动时，会通过 Eureka Client 向 Eureka Server 注册信息，Eureka Server 会存储该服务的信息，Eureka Server内部有二层缓存机制来维护整个注册表

1.2.1.2、提供注册表

服务消费者在调用服务时，如果 Eureka Client 没有缓存注册表的话，会从 Eureka Server 获取最新的注册表

1.2.1.3、同步状态

Eureka Client 通过注册、心跳机制和 Eureka Server 同步当前客户端的状态

1.2.2、Eureka Client

是一个 Java 客户端，用于简化 Eureka Server 交互,客户端同时也具备一个内置的、使用轮询负载算法的负载均衡。在应用启动后，向 Eureka Server 发送心跳(默认周期为 30 秒)。如果 Eureka Server 在多个心跳周期内没有接收到某个节点的心跳，Eureka Server 会从服务注册表中将该服务节点信息移除(默认为90秒)。

 <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>

1.2.2.1、Register 服务注册

服务的提供者，将自身注册进注册中心，服务提供者也是一个 Eureka Client。当Eureka Client向 Eureka Server注册时，它提供自身的元数据，比如 ip地址、端口、运行状况指示符 URL、主页等。

eureka:
	client: 
	#将自身注册进注册中心
		register-with-eureka: true

1.2.2.2、Renew 服务续约

Eureka Client会每隔 30秒发送一次心跳来与注册中心进行续约。通过续约来告知Eureka Server 该 Eureka Client运行正常，没有出现问题。默认情况下，如果 Eureka Server在90秒内没有接收到 Eureka Client发送过来的心跳续约，Server 端会将实例从注册表中进行剔除，该配置可以配置修改。

eureka:
	instance:
	 #Eureka 客户端向服务端发送心跳的时间间隔，默认为 ：30 秒
		lease-renewal-interval-in-seconds: 30
		#Eureka 服务端最后一次收到心跳后等待时间的上限，单位为秒，默认为：90 秒，超时则剔除服务
		lease-expiration-duration-in-seconds: 90

1.2.2.3、Evicition 剔除服务

当Eureka Server 没有接收到 Eureka Client 发送过来的续约时，Server端就会将该实例从注册表中删除，即剔除服务。

1.2.2.4、Cancel 服务下线

Eureka Client 在程序关闭时向 Eureka Server发送取消请求。发送请求后，该客户端实例信息将从 Eureka Server 的实例注册表中删除。该下线请求不会自动完成，他需要调用一下内容

DiscoveryManager.getInstance().shutdownComponent();

1.2.2.5、GetRegister 获取注册列表信息

Eureka Client 从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期 (每30秒钟)更新一次。每次返回注册列表信息可能与 Eureka Client 的缓存信息不同，Eureka Client 自动处理。

如果由于某种原因导致注册列表信息不能即使匹配，Eureka Client 则会重新获取整个注册表信息。Eureka Server 缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka Client 和 Eureka Server 可以使用 JSON/XML 格式进行通讯。在默认情况下 Eureka Client 使用压缩 JSON 格式来获取注册列表的信息。

eureka: 
	client: 
	#启用服务消费者从注册中心拉取服务列表的功能
		fetch-registry: true
		#设置服务消费者从注册中心拉取列表的间隔
		registry-fetch-interval-seconds: 30

1.2.2.6、Remote Call 远程调用

当 Eureka Client 从注册中心获取到服务提供者信息后，就可以通过 Http请求调用对应的服务；服务提供者有多个时，Eureka Client 客户端会通过 Ribbon 自动进行负载均衡。

1.3、自我保护机制

默认情况下，如果Eureka Server 在一定的 90s 内没有接收到某个微服务实例的心跳，会注销该实例。但是在微服务架构下服务之间通常都是跨进程通信，网络通信往往会面临着各种问题，比如微服务状态正常，网络分区故障，导致此实例被注销。

固定时间内大量的实例被注销，可能会严重威胁整个微服务架构的可用性。为了解决这个问题，Eureka 开发了自我保护机制，那么什么是自我保护机制呢？

Eureka Server 在运行期间回去统计心跳失败比例在 15 分钟之内是否低于 85%，如果低于85%，Eureka Server即会进入自我保护机制。

Eureka Server 开启自我保护机制后，页面会出现提示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8VKeMvbJ-1598079420890)(C:\Users\20296\AppData\Roaming\Typora\typora-user-images\1594100857727.png)]

Eureka Server 进入自我保护机制，会出现以下几种情况：

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

Eureka 自我保护机制是为防止误杀服务而提供的一个机制。当个别客户端出现心跳失联时，则认为是客户端的问题，剔除掉客户端；当Eureka 捕获到大量的心跳失败时，则认为可能是网络问题，进入自我保护机制；当客户端心跳恢复时，Eureka 会自动退出自我保护机制。

如果在保护期内刚好这个服务提供者非正常下线了，此时服务消费者就会拿到一个无效的服务实例，即会调用失败，针对这个问题需要消费者端要有一些容错机制。如重试、断路器等。

1.4、Eureka 集群原理

因为在正常的生产环节时，单一的 Eureka Server 或者是 Eureka Client 出现问题进行宕机，那么就会影响整个程序。但是将单一的Eureka Server 或者 Eureka Client多加几台PC端，这就是集群。

从图中可以看出Eureka Server 集群相互之间通过 Replicate 来同步数据，相互之间不区分主节点和从节点，所有的节点都是平等的。在这种架构中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。

如果某台 Eureka Server 出现宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点。当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会进行节点间复制，将请求服务到其它 Eureka Server 当前所知的所有节点中。

另外 Eureka Server 的同步遵循着一个非常简单的原则：只要有一条边将节点连接，就可以进行信息传播与同步。所以，如果存在多个节点，只需要将节点之间两两连接起来形成通路,那么其他注册中心都可以共享信息。每个 Eureka Server 同时也是 Eureka Client，多个 Eureka Sever 之间通过 P2P 的方式完成服务注册表的同步。

eureka: 
	client: 
	#本身就是注册中心，所以不需要将自己注册进去
		register-with-eureka: false
		service-url: 
			defaultZone: htttp://eureka7001.com:7001/eureka

Eureka Server 集群之间的状态是采用异步方式同步的，所以不保证节点间的状态一定是一致的，不过基本能保证最终状态是一致的。

1.4.1、Eureka 分区

Eureka 提供了 Region 和 Zone 两个概念来进行分区，这个概念均来自于亚马逊的 AWS：

1.4.1.1、region

可以理解为地理上的不同区域，比如亚洲地区，中国区或者深圳。没有具体大小的限制。根据项目具体的情况，可以自行合理划分 region。

1.4.1.2、zone

可以简单理解为 region 内具体的机房，比如说 region 划分为深圳，然后深圳有两个机房，就可以在此 region 之下划分出 zone1、zone2两个zone。

博主本人也在学SpringCloud。