一步一步学SpringCloud--服务治理机制

Love The Way You Lie 2022-05-14 16:38 335阅读 0赞

### 一步一步学SpringCloud--服务治理机制 ###

*  核心三要素
 *  服务治理机制
 *   *  服务提供者
     *   *  服务注册
         *  服务同步
         *  服务续约
     *  服务消费者
     *   *  获取服务
         *  服务调用
         *  服务下线
     *  服务注册中心
     *   *  失效剔除
         *  自我保护

# 核心三要素 #

注册中心：Eureka提供的服务器，提供服务注册于发现的功能，即eureka-server  
       服务提供者：提供服务的应用，可以是springboot应用，也可以是其他技术平台且遵循eureka通信机制的应用。它将自己提供的服务注册到eureka，以供其他应用发现。  
       服务消费者：消费者从服务注册中心获取服务列表，从而使消费者可以知道去何处调用其所需要的服务，在上一篇博客中使用了ribbon来实现消费服务，后续还会介绍使用feign消费服务

# 服务治理机制 #

![服务治理机制][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXppdGVuZzAyMjg_size_27_color_FFFFFF_t_70]

体验了spring cloud eureka通过简单的注解配置就能实现强大的服务治理功能之后，进一步了解一下eureka基础架构中各个元素的一些通信行为，以此来理解基于eureka实现的服务治理体系是如何运作起来的。以上图为例，其中有几个重要元素：  
       “服务注册中心-1”和“服务注册中心-2”，他们相互注册组成高可用集群。  
       “服务提供者”启动了两个实例，一个注册到“服务注册中心-1”，另外一个注册到“服务注册中心-2”上。  
       还有两个“服务消费者”，他们也都分别指向了一个注册中心。

## 服务提供者 ##

### 服务注册 ###

服务提供者在启动的时候会通过发送REST请求的方式将自己注册到Eureka Server上，同时带上了自身服务的一些元数据信息。Eureka Server接收到这个REST请求后，将元数据信息存储在一个双层结构Map中，其中第一层的key是服务名，第二层的key是具体服务的实例名。  
       在服务注册时，需要确认eureka.client.register-with-eureka=true参数是否正确，若为false，将不会启动注册操作

### 服务同步 ###

如图所示，这里的两个服务提供者分别注册到了两个不同的服务注册中心上，即他们的信息分别被两个注册中心维护。由于服务注册中心之间为互相注册，当服务提供者发送注册请求到一个服务注册中心时，它会将请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步。通过服务同步，两个服务提供者的服务信息就可以通过这两个服务注册中心中的任意一台获取到。

### 服务续约 ###

在注册完服务之后，服务提供者会维护一个心跳用来持续高武Eureka Server：“我还活着”，以防止Eureka Server的“剔除任务”将该服务实例从服务列表中排除出去，我们称该操作为服务续约

## 服务消费者 ##

### 获取服务 ###

到这里，在服务注册中心已经注册了一个服务，并且该服务有两个实例。当我们启动服务消费者是，它会发一个REST请求给注册中心，来获取上面注册的服务清单。为了性能考虑，Eureka Server会维护一份只读的服务清单来返回给客户端，同时该缓存清单会每隔30s更新一次  
       获取服务是消费者的基础，所以要确保eureka-client-fetch-registery=true参数有没有被修改成false，该值默认为true。若想修改缓存清单的更新时间，可以通过eureka-client。registry-fentch-interval-seconds=30参数来进行修改，该值默认为30s

### 服务调用 ###

服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该示例的元数据信息。因为有这些服务示例的详细信息，所以客户端可以根据自己的需要决定具体需要调用的实例，在Rinbbon中默认采用轮询的方式进行调用，从而实现客户端的负载均衡。

### 服务下线 ###

在系统运行过程中必然会面临关闭或重启服务的某个实例的情况，在服务关闭期间，我们自然不希望客户端会继续调用关闭了的实例。所以在客户端程序中，在服务实例进行正常的关闭操作时，它会触发一个服务下线的REST请求给Eureka Server，告诉服务注册中心：“我要下线了”。服务端在接收到请求后，将该服务状态设置为下线，并把该下线事件传播出去。

## 服务注册中心 ##

### 失效剔除 ###

当一些外部原因，如内存溢出、网络故障等导致服务实例非正常下线，而服务注册中心并未收到“服务下线”的请求。为了从服务列表中将这些无法提供服务的实例剔除，Eureka Server在启动的时候会创建一个定时任务，默认每隔一段时间（默认60s）将当前清单中超时（默认90s）没有续约的服务剔除出去

### 自我保护 ###

当我们在本地调试基于 Eureka 的程序时，基本上都会在服务注册中心的信息面板上出现类似下面的红色警告信息：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXppdGVuZzAyMjg_size_27_color_FFFFFF_t_70 1]  
       实际上，该警告是触发了Eureka Server的自我保护机制。之前介绍过，服务注册到Eureka Server之后，会维护一个心跳连接，告诉Eureka Server 自己还活着。Eureka Server 在运行期间，会统计心跳失败的比例在15分钟之内低于85%，如果出现低于的情况，Eureka Server 会将当前的实例信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。但是，在保护期间内实例若出现问题，那么客户端很容易拿到实际已经不存在的服务实例，会出现调用失败的情况，所以客户端必须要有容错机制，比如可以使用请求重试、断路器等机制。  
       由于在本地调试很容易触发注册中心的保护机制，使得注册中心维护的服务实例不那么准确。可以在本地进行开发时，使用eureka-server.enable-self-preservation=false 参数来关闭保护机制，确保注册中心将不可用的实例正确剔除。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXppdGVuZzAyMjg_size_27_color_FFFFFF_t_70]: /images/20220503/df16acb41dc849ab9b2db7b3ffcdf252.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXppdGVuZzAyMjg_size_27_color_FFFFFF_t_70 1]: /images/20220503/788b7cd4eaa14319ae4f04ddd96b8a11.png