Spring Cloud--Eureka实现原理

前言

Github：https://github.com/yihonglei/SpringCloud-Study

一 Eureka基础架构

Eureka服务治理基础架构包括三个核心要素。

1、服务注册中心

Eureka分为客户端和服务端，Eureka服务端提供服务注册与发现的功能。

2、服务提供者

提供服务的应用，Spring Boot应用或者遵循Eureka通信机制的应用。

将应用自己注册到Eureka注册中心，以供其它应用的发现。

3、服务消费者

消费者从服务注册中心获取服务列表，通过客户端负载均衡某种算法轮询服务列表，

然后调用其所需要的服务，也即调用对应的服务提供者。

 

注意，在某些情况下，服务既是提供者也是消费者，

比如服务A调用B，B调用C，这个时候B既是提供者，也是消费者。

二 服务治理机制

Eureka各个元素间的运作原理如下图：

这里假设启动了两个服务提供者，两个集群Eureka Server，两个服务消费者。

1、服务提供者

--服务注册（register）

    从图中可以看到，服务提供者在启动的时候通过发送REST请求，将自己注册到Eureka Server注册中心，

注册信息包含一些元数据信息。Eureka Server接收到请求后，将元数据存储在一个双层结构Map中，

第一层的key是服务名，第二层的key是具体服务的实例名。

--服务同步（replicate）

    图中提供了两个服务提供者，分别向两个注册中心注册，因为服务注册中心为集群部署，注册中心互相注册，

当服务提供者发送请求到一个注册中心时，注册中心会将注册的信息转发给其它集群相连的注册中心，

完成注册中心之间的服务同步。通过注册中心之间的服务同步，集群注册中心服务信息保持一致，

这样就可以通过任意一台注册中心获取服务列表。

--服务续约（renew）

    服务提供者注册完成后，会维护一个心跳，用来持续的告诉注册中心，我还活着，避免Eureka Server 将服务提供者

从注册中心剔除，这种操作行为我们称为服务续约。

2、服务消费者

--获取服务（get registry）

服务消费者在启动的时候，向注册中心发送REST请求给服务注册中心，从服务注册中心获取服务列表清单。

Eureka Server维护一份只读的服务清单返回给客户端，同时该缓存清单默认每隔30秒更新一次。

--服务调用（invoke server）

服务消费者在获取服务清单后，通过服务名可以获得提供服务的实例名和该实例的元数据信息。

如果使用Ribbon客户端负载均衡，可以采用某种算法轮询进行调用。

--服务下线（cancel）

系统运行过程中总会有面临关闭或重启服务某个实例的情况，在服务关闭期间，我们不希望客户端会

继续调用关闭的服务实例。当服务实例进行正常关闭操作时，它会触发一个服务下线的REST请求Eureka Server，

注册中心收到请求时，服务端将该服务状态置为下线(DOWN)，同时把该下线事件传播下去。

3、服务注册中心

--失效剔除（evict）

服务有时候并不一定会正常下线，可能由于异常故障使服务运行不正常，但是，服务注册中心并未收到"服务下线"请求。

注册中心为了将这些无法提供服务的实例剔除，Eureka Server在启动的时候会创建一个定时任务，

默认每隔一段时间(默认为60秒)将当前清单中超时(默认为90秒)没有续约的服务从注册中心剔除。

--自我保护

默认情况下，如果Eureka Server在一定时间内（默认90秒）没有接收到某个微服务实例的心跳，

Eureka Server将会移除该实例。但是当网络分区故障发生时，微服务与Eureka Server之间无法正常通信，

而微服务本身是正常运行的，此时不应该移除这个微服务，所以引入了自我保护机制。

自我保护机制的工作机制是如果在15分钟内超过85%的客户端节点都没有正常的心跳，

那么Eureka就认为客户端与注册中心出现了网络故障，Eureka Server自动进入自我保护机制，

此时会出现以下几种情况：

1）Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。

2）Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，

保证当前节点依然可用。

3）当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。

因此Eureka Server可以很好的应对因网络故障导致部分节点失联的情况，

而不会像ZK(zookeeper)那样如果有一半不可用的情况会导致整个集群不可用而变成瘫痪。