(4) Eureka原理分析

一 Eureka基础架构

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

1. 服务注册中心

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

2. 服务提供者

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

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

3. 服务消费者

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

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

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

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

二 服务治理机制

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

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

1. 服务提供者

--服务注册

从图中可以看到，服务提供者在启动的时候通过发送REST请求，

将自己注册到Eureka Server注册中心，注册信息包含一些元数据信息。

Eureka Server接收到请求后，将元数据存储在一个双层结构Map中，

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

--服务同步

图中提供了两个服务提供者，分别向两个注册中心注册，

因为服务注册中心为集群部署，注册中心互相注册，当服务提供者发送请求

到一个注册中心时，注册中心会将注册的信息转发给其它集群相连的注册中心，

完成注册中心之间的服务同步。通过注册中心之间的服务同步，集群注册中心服务

信息保持一致，这样就可以通过任意一台注册中心获取服务列表。

--服务续约

服务提供者注册完成后，会维护一个心跳，用来持续的告诉注册中心，

我还活着，避免Eureka Server 将服务提供者从注册中心剔除，

这种操作行为我们称为服务续约。

2. 服务消费者

--获取服务

服务消费者在启动的时候，向注册中心发送REST请求给服务注册中心，

从服务注册中心获取服务列表清单。Eureka Server维护一份只读的服务

清单返回给客户端，同时该缓存清单默认每隔30秒更新一次。

--服务调用

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

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

--服务下线

系统运行过程中总会有面临关闭或重启服务某个实例的情况，在服务关闭期间，

我们不希望客户端会继续调用关闭的服务实例。当服务实例进行正常关闭操作时，

它会触发一个服务下线的REST请求Eureka Server，注册中心收到请求时，

服务端将该服务状态置为下线(DOWN)，同时把该下线事件传播下去。

3. 服务注册中心

--失效剔除

服务有时候并不一定会正常下线，可能由于异常故障使服务运行不正常，

但是，服务注册中心并未收到"服务下线"请求。注册中心为了将这些无法

提供服务的实例剔除，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)那样如果有一半不可用的情况会导致整个集群不可用而变成瘫痪。