1、什么是 Eureka

Consul、Zookeeper 类似，Eureka 是一个用于服务注册和发现的组件，最开始主要应用
于亚马逊公司旗下的云计算服务平台 AWS。Eureka 分为 Eureka Server 和 Eureka Client，Eureka
Server 为 Eureka 服务注册中心，Eureka Client 为 Eureka 客户端。

2、为什么选择 Eureka

在 Spring Cloud 中，可选择 Consul、Zookeeper 和 Eureka 作为服务注册和发现的组件，那
为什么要选择 Eureka 呢？

首先 Eureka 完全开源，是 Netflix 公司的开源产品，经历了 Netflix 公司的生产环境的考验，
以及 3 年时间的不断迭代，在功能和性能上都非常稳定，可以放心使用。
其次，Eureka 是 Spring Cloud 首选推荐的服务注册与发现组件，与 Spring Cloud 其他组件
可以无缝对接。

最后，Eureka 和其他组件，比如负载均衡组件 Ribbon、熔断器组件 Hystrix、熔断器监控组
件 Hystrix Dashboard 组件、熔断器聚合监控 Turbine 组件，以及网关 Zuul 组件相互配合，能够
很容易实现服务注册、负载均衡、熔断和智能路由等功能。

这些组件都是由 Netflix 公司开源的，一起被称为 Netflix OSS 组件。Netflix OSS 组件由 Spring Cloud 整合为 Spring Cloud Netflix 组件，它是 Spring Cloud 构架微服务的核心组件，也是基础组件。

3、Eureka 的基本架构图

springcloud gateway eureka 开源服务 springcloud的eureka_eureka


其中主要包括以下 3 种角色。

1、Register Service：服务注册中心，它是一个 Eureka Server，提供服务注册和发现的功能。
2、Provider Service：服务提供者，它是一个 Eureka Client，提供服务。
3、Consumer Service：服务消费者，它是一个 Eureka Cient，消费服务。

服务消费的基本过程如下：

首先需要一个服务注册中心 Eureka Server。

服务提供者 Eureka Client 向服务注册中心 Eureka Server 注册，将自己的信息（比如服务名和服务的 IP 地址等）通过 REST API 的形式提交给服务注册中心 Eureka Server。

服务消费者 Eureka Client 也向服务注册中心 Eureka Server 注册，同时服务消费者获取一份服务注册列表的信息，该列表包含了所有向服务注册中心 Eureka Server 注册的服务信息。获取服务注册列表信息之后，服务消费者就知道服务提供者的 IP 地址，可以通过 Http 远程调度来消费服务提供者的服务。

4、Eureka工作原理

Eureka : 就是服务注册中心(可以是一个集群),对外暴露自己地址;

提供者 : 启动后向Eureka注册自己信息(地址,提供什么服务)

消费者 : 向Eureka 订阅服务,Eureka会将对应服务的服务列表发送给消费者,并且定期更新

心跳(续约): 提供者定期通过http方式向Eureka刷新自己的状态

5、什么是服务注册

Eureka Client启动的时候，会向Eureka Server 发起一次请求，将自身的元数据，比如 IP 地址、
端口、运行状况指标的 Url、主页地址等信息 注册到Eureka注册中心。

6、什么是服务续约

Eureka Client默认情况下（每隔30s发送一次心跳）进行服务续约，旨在通知Eureka Server 该 Eureka Client正常运行。

如果 Eureka Server 90s内都没有收到改Eureka Client 心跳，Eureka Server 会将 Eureka Client 实例从注册列表中删除。

ps：默认服务续约间隔时间，一般情况下不建议更改。

7、什么是服务下线

当服务进行正常关闭操作时,它会触发一个服务下线的REST请求给EurekaServer,告诉服务注册中心:“我要下线了”.服务中心接收到请求之后,将该服务置为下线状态.

当Eureka Client 需要进行服务正常关闭的时候，需要向Eureka Server 发送下线REST请求。

Eureka Server 接收到请求后，将该Eureka Client实例从服务注册列表中删除，该服务设置未下线状态。

Eureka Client 下线，需要在程序执行

DiscoveryManager.getInstance().shutdownComponent()；

8、 什么是失效剔除

Eureka Client 服务提供方不一定是正常下线，可能由于网络故障、内存溢出等原因导致服务无法正常工作。 Eureka Server 既没有收到下线请求，又没有及时进行服务续约。

服务注册中心在启动时会创建一个定时任务，默认每隔一段时间(默认60秒)将当前清单中超时(默认为90秒)没有续约的服务剔除，即失效剔除。

# 单位：毫秒，设置定时时间，默认60s
eureka.server.eviction.interval-time-in-ms

9、什么是自我保护

启动Eureka Server服务面板，有些时候会发现出现一串红色文字。

因为触发了Eureka的自我保护机制，当服务未按时进行心跳续约时，Eureka Server会统计服务实例最近15分钟心跳续约的比例是否低于85%。

当心跳失败实例的比例超出了15%，Eureka Server 认为从服务列表中剔除并不妥当发，因为服务很有可能依然可用（网络故障等因素导致），服务未宕机。Eureka就会把当前实例的注册信息保护起来，不允许剔除。

在生产环境下可以有效保障服务正常允许，当然也有可能获取到失败的服务实例，需要调用者做好服务的失败容错。

#关停自我保护，默认是打开
eureka.server.enable-self-preservation: false

10、 简述什么是CAP,并说明Eureka包含CAP中的哪些?

CAP理论

一个分布式系统不可能同时满足C (一致性),A(可用性),P(分区容错性).由于分区容错性P在分布式系统中是必须要保证的,因此我们只能从A和C中进行权衡.

Eureka 遵守 AP

Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务.

而Eureka的客户端在向某个Eureka 注册或查询是如果发现连接失败,则会自动切换至其他节点

只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查的信息可能不最新的不保证强一致性).

Spring Cloud中的Eureka和Zookeeper的区别在哪？

eureka保证ap
zookeeper保证cp

CAP理论

在总结两者的区别之前，我们先来看一个 CAP 理论。什么叫 CAP 理论呢？CAP 理论是由 Eric Brewer 教授提出，是分布式系统中的一个重要的概念。具体如下：

C（Consistency）：数据一致性。大家都知道，分布式系统中，数据会有副本。由于网络或者机器故障等因素，可能有些副本数据写入正确，有些却写入错误或者失败，这样就导致了数据的不一致了。而满足数据一致性规则，就是保证所有数据都要同步。

A（Availability）：可用性。我们需要获取什么数据时，都能够正常的获取到想要的数据（当然，允许可接受范围内的网络延迟），也就是说，要保证任何时候请求数据都能够正常响应。

P（Partition Tolerance）：分区容错性。当网络通信发生故障时，集群仍然可用，不会因为某个节点挂了或者存在问题，而影响整个系统的正常运作。对于分布式系统来说，出现网络分区是不可避免的，因此分区容错性是必须要具备的，也就是说，CAP三者，P是必须的，是个客观存在的事实，不可避免，也无法绕过。

Eureka的AP原则

大规模网络部署时，失败是在所难免的，因此我们无法回避这个问题。当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接 down 掉不可用。

Eureka 在被设计的时候，就考虑到了这一点，因此在设计时优先保证可用性，这就是 AP 原则。Eureka 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而 Eureka 的客户端在向某个 Eureka 注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台 Eureka 还在，就能保证注册服务可用（即保证A原则），只不过查到的信息可能不是最新的（不保证B原则）。

正因为应用实例的注册信息在集群的所有节点间并不是强一致的，所以需要客户端能够支持负载均衡以及失败重试。在 Netflix 的生态中，ribbon 可以提供这个功能。

因此， Eureka 可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像 zookeeper 那样使整个注册服务瘫痪。

作为服务注册中心，最重要的是要保证可用性，可以接收段时间内数据不一致的情况。个人觉得 Eureka 作为单纯的服务注册中心来说要比 zookeeper 更加“专业”一点。

zookeeper的CP原则

zookeeper 是保证数据的一致性的，但是这里还需要注意一点是，zookeeper 它不是强一致的，什么意思呢？打个比方，现在客户端 A 提交一个写操作，zookeeper 在过半数节点操作成功之后就可以返回，但此时，客户端 B 的读操作请求的是 A 写操作尚未同步到的节点，那么读取的就不是 A 最新提交的数据了。

那如何保证强一致性呢？我们可以在读取数据的时候先执行一下sync 操作，即与 leader 节点先同步一下数据，再去取，这样才能保证数据的强一致性。

但是 zookeeper 也有个缺陷，刚刚提到了 leader 节点，当 master 节点因为网络故障与其他节点失去联系时，剩余节点会重新进行 leader 选举。问题在于，选举 leader 的时间太长，30 ~ 120s, 且选举期间整个 zookeeper 集群都是不可用的，这就导致在选举期间注册服务瘫痪。

在云部署的环境下，因网络问题使得 zookeeper 集群失去 master 节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。比如双十一当天，那就是灾难性的。

eureka和zookeeper的区别总结

Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。Eureka作为单纯的服务注册中心来说要比zookeeper更加“专业”，因为注册服务更重要的是可用性，我们可以接受短期内达不到一致性的状况。