SpringCloud源码分析（一）--Eureka服务基础知识

1、前言

上两节已经搭建了一个简单的Eureka的服务注册中心和服务提供者或者服务消费者，由于有时候服务消费者也是服务提供者，这二者划分没有那么清楚的界限。本节主要介绍一些跟Eureka相关的知识。了解它们到底有什么特色和功能。

2、Eureka基础知识

本节主要将Eureka分为基础架构和服务治理两个方向描述

2.一、基础架构

在基础架构中，Eureka主要分为服务注册中心，服务提供者和服务消费者。

2.二、服务治理机制

先来看一下很基础的服务治理机制的简单示意图：

根据每个的通讯行为作具体介绍：

2.2.一、服务提供者

根据上图，服务提供的基础功能分为：（1）服务注册；（2）服务续约；（3）服务下线

（1）服务注册

服务提供者在启动的时候会经过REST请求向服务注册中心，同时会携带上本身的一些元数据信息。服务注册中心接收到注册信息后，会将信息保存在一个双层的MAP中，第一层的key就是服务的名称，第二层的key是具体服务的实例。因此在服务提供者启动时，确保对应的参数eureka.client.register-with-eureka=true,或者这个参数不配置也行，由于其默认就是true。

（2）服务续约

注册完成之后，服务提供者会保持一个心跳给服务注册中心，告诉服务注册中心：”老子还活着，你不要抽风把我从服务实例给剔除了“，这个就叫作服务续约。
在服务续约中会有两个重要的参数：
　　<1>eureka.instance.lease-renewal-interval-in-seconds
这个是表示服务提供者向服务注册中心续约的时间间隔，默认是30秒
　　<2>eureka.instance.lease-expiration-duration-in-seconds
这个是服务过时的时间，默认是90秒
（3）服务下线

服务在运行过程当中不可避免的存在重启或者升级等问题，在服务关闭期间，不但愿服务注册中心将消费者的请求I分配到这个服务上，因此在服务正常关闭的时候，会发送一个REST的请求给注册中心，注册中心接受到请求之后，会把对应的服务的状态设置为DOWN，并把下线事件传播出去

 其中最主要的就是服务注册和续约功能。

2.2.二、服务消费者

根据上图，服务消费者的功能主要是：（1）获取服务；（2）服务的调用

（1）获取服务

服务消费者启动的时候，会向服务注册中心发送一个REST的请求，来获取服务注册中心上的服务实例清单。Eureka Service 为了性能的考虑，本身维护了一个只读属性的缓存服务清单返回给客户端，而且缓存服务清单默认是30秒刷新一次。
为了服务消费者可以获取到服务注册中心的服务实例清单，eureka.client.fetch-registry必须设置为true，或者在配置文件中不写，由于Eureka默认其为true。
若是但愿修改 缓存服务清单的刷新时间，能够经过修改参数eureka.client.registry-fetch-interval-seconds  

（2）服务的调用

服务消费者人获取服务实例清单之后，天然是须要调用对应 服务。他是经过服务名称来获取服务的实例和服务相关的元数据信息，服务消费者就能够自行决定要调用哪个服务实例。例如Ribbon就是一个典型的客户端的负载均衡的应用。

2.2.3 、服务注册中心

根据上图，服务注册中心主要特点是：（1）失效剔除；（2）自我保护机制

（1）失效剔除

有时候服务不必定是正常的下线，有不少因素致使服务不能正常工做，这个时候服务注册中心不能接收到服务的下线通知，可是一直保持维护一个无效的服务实例，会给服务消费者形成错觉，这个服务还在，可以影响请求。因此为了剔除没法提供服务的实例，Eureka Service启动的时候会启动一个定时任务，来将一段时间没有进行续约的服务剔除，默认是60秒会检查一边服务清单中超过90秒没有续约的服务，而后将其剔除。

（2）自我保护机制

在我本本地开发测试的时候，注册中心很容易出现一个EMERGENCY!的红色警告，这个是由于Eureka Service有一个自我保护的机制，Eureka Service在运行期间会统计心跳失败的比例，便是在15分钟内，是否低于85%，若是低于这个比例，Eureka Service会将当前的实例注册信息保护起来，让这些实例不过时，尽可能保护这些注册信息。可是很容易形成一个问题，就是在这段保护期内，客户端很容易再次拿到已经不能提供服务的实例，出现调用失败的状况，因此通常要求客户端最好有容错机制。
能够经过参数将其自我保护机制关闭：
eureka.server.enable-self-preservation为false