Eureka 注册中心

一，简介

Eureka 是 Netflix 开源的注册中心组件，分成 Eureka Client 和 Eureka Server 两个角色。整体架构如下图所示：

Eureka-Server ：通过 REST 协议暴露服务，提供应用服务的注册和发现的功能。
Application Server ：应用服务提供者，内嵌 Eureka-Client ，通过它向 Eureka-Server 注册自身服务。
Application Client ：应用服务消费者，内嵌 Eureka-Client ，通过它从 Eureka-Server 获取服务列表。

Eureka Server 之间通过复制的方式完成数据的同步，Eureka 还提供了客户端缓存机制，即使所有的 Eureka Server 都挂掉，客户端依然可以利用缓存中的信息消费其他服务的 API。综上，Eureka 通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。

二，服务和 Eureka 之间的交互行为

1.1，服务注册(register)：

Eureka Client 会通过发送 REST 请求的方式向 Eureka Server 注册自己的服务，提供自身的元数据，比如 ip 地址、端口、运行状况指标的 url、主页地址等信息。Eureka Server 接收到注册请求后，就会把这些元数据信息存储在一个注册表中。

1.2，服务续约(renew)：

服务提供方使用 Eureka-Client 每 30 秒向 Eureka-Server 发起一次心跳，告诉 Eureka-Server 当前服务实例还存活。
如果 Eureka-Server 90 秒没有收到 Eureka-Client 的心跳，会认为它已经下线，将该服务实例从注册表移除。

为什么需要心跳？Eureka 采用 REST 短连接，而非 TCP 长连接，所以需要通过心跳机制来确认是否存活。

1.3，服务下线(cancel)：

服务提供者准备下线时，使用 Eureka-Client 向 Eureka-Server 发起取消注册请求，从而从注册表中移除，避免后续服务消费者请求当前实例。一般来说，我们把这种方式称为正常下线。

与之相对的，就是心跳超时导致的异常下线，服务实例可能会因为网络故障等原因导致不能提供服务，而此时该实例也没有发送请求给 Eureka Server 来进行服务下线，所以，还需要有服务剔除的机制。Eureka Server在启动的时候会创建一个定时任务，每60秒检查一次，从当前服务清单中把超时没有续约的服务剔除（默认90s）。

1.4，获取服务(get registry)：

服务消费者使用 Eureka-Client 从 Eureka-Server 获取全量注册表，并缓存在本地内存。之后，服务消费者要远程调用服务提供者时，只需要从本地缓存的注册表查找对应的服务即可。

考虑到 Eureka-Server 的注册表是不断变化的，服务消费者每 30 秒使用 Eureka-Client 从 Eureka-Server 获取增量变化的部分，合并更新到本地缓存的注册表。
同时，为了性能虑，Eureka Server 也会维护一份只读的服务清单缓存，该缓存每隔30秒更新一次。

面试题：1：如果注册中心挂了，是否影响远程调用？可阅读《应用实例注册发现（六）之全量获取》
2：如何实现增量更新？可阅读《应用实例注册发现（七）之增量获取》

服务消费者在获取到服务清单后，就可以根据清单中的服务列表信息，查找到其他服务的地址，从而进行远程调用。Eureka 有 Region 和 Zone 的概念，一个 Region 可以包含多个 Zone，在进行服务调用时，优先访问处于同一个 Zone 中的服务提供者。

三，Eureka-Server 之间的交互行为

Eureka-Server 在 CAP 定理中，选择了 AP 来实现：

一致性（Consistency）：等同于所有节点访问同一份最新的数据副本。
可用性（Availability）：每次请求都能获取到非错的响应，但是不保证获取的数据为最新数据。

Eureka-Server 集群如下图：

Eureka-Server 集群不区分主从节点或者 Primary & Secondary 节点，所有节点不区分角色，完全对等。
Eureka-Client 可以向任意 Eureka-Server 发起任意读写操作，Eureka-Server 将操作复制到另外的 Eureka-Server 以达到最终一致性。

面试题： Zookeeper 和 Eureka 作为注册中心有什么差别？可以看看《对于注册中心，ZooKeeper、Eureka 哪个更合适？》

2.1，服务同步(replicate)

Eureka Server 之间不区分主从节点，会互相进行注册进行服务同步，用来保证服务信息的一致性。

2.2，自我保护

既然Eureka Server会定时剔除超时没有续约的服务，那就有可能出现一种场景，网络一段时间内发生了异常，所有的服务都没能够进行续约，Eureka Server 就把所有的服务都剔除了，这样显然不太合理。所以，就有了自我保护机制，当短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下，Eureka Server 不会剔除任何的微服务，等到正常后，再退出自我保护机制。
自我保护开关(eureka.server.enable-self-preservation: false)

四，注册中心原理

在使用注册中心时，一共有三种角色：服务提供者（Service Provider）、服务消费者（Service Consumer）、注册中心（Registry）。

Provider 和 Consumer 是角色上的定义，一个服务同时即可以是 Provider 也可以作为 Consumer。例如说，优惠劵服务可以给订单服务提供接口，同时又调用用户服务提供的接口。

在一些文章中，服务提供者被称为 Server，服务消费者被称为 Client。胖友们知道即可。
三个角色交互如下图所示：

① Provider：

启动时，向 Registry 注册自己为一个服务（Service）的实例（Instance）。
同时，定期向 Registry 发送心跳，告诉自己还存活。
关闭时，向 Registry 取消注册。

② Consumer：

启动时，向 Registry 订阅使用到的服务，并缓存服务的实例列表在内存中。
后续，Consumer 向对应服务的 Provider 发起调用时，从内存中的该服务的实例列表选择一个，进行远程调用。
关闭时，向 Registry 取消订阅。

③ Registry：

Provider 超过一定时间未心跳时，从服务的实例列表移除。
服务的实例列表发生变化（新增或者移除）时，通知订阅该服务的 Consumer，从而让 Consumer 能够刷新本地缓存。

当然，不同的注册中心可能在实现原理上会略有差异。例如说，Eureka 注册中心并不提供通知功能，而是 Eureka Client 自己定期轮询，实现本地缓存的更新。

文章参考

芋道 Spring Cloud Netflix 注册中心 Eureka 入门
 微服务注册中心Eureka架构深入解读-InfoQ
Spring Cloud Eureka服务架构 - 白庆国 - 博客园

目录CONTENT