Eureka 实现原理

Eureka 是 Netflix 出品的用于实现服务注册和发现的工具。 Spring Cloud 集成了 Eureka，并提供了开箱即用的支持。其中， Eureka 又可细分为 Eureka Server 和 Eureka Client。

上图是来自eureka的官方架构图，这是基于集群配置的eureka；
- 处于不同节点的eureka通过Replicate进行数据同步
- Application Service为服务提供者
- Application Client为服务消费者
- Make Remote Call完成一次服务调用

服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。

当服务注册中心Eureka Server检测到服务提供者因为宕机、网络原因不可用时，则在服务注册中心将服务置为DOWN状态，并把当前服务提供者状态向订阅者发布，订阅过的服务消费者更新本地缓存。

服务提供者在启动后，周期性（默认30秒）向Eureka Server发送心跳，以证明当前服务是可用状态。Eureka Server在一定的时间（默认90秒）未收到客户端的心跳，则认为服务宕机，注销该实例。

1、Eureka基础框架：

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

1、服务注册中心

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

2、服务提供者

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

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

3、服务消费者

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

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

服务消费者

--获取服务

服务消费者在启动的时候，向注册中心发送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)那样如果有一半不可用的情况会导致整个集群不可用而变成瘫痪。