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 的基本架构图
其中主要包括以下 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 远程调度来消费服务提供者的服务。
Eureka工作原理
Eureka : 就是服务注册中心(可以是一个集群),对外暴露自己地址;
提供者 : 启动后向Eureka注册自己信息(地址,提供什么服务)
消费者 : 向Eureka 订阅服务,Eureka会将对应服务的服务列表发送给消费者,并且定期更新
心跳(续约): 提供者定期通过http方式向Eureka刷新自己的状态
什么是服务注册
服务提供者在启动时,会向EurekaServer发起一次请求,将自己注册到Eureka注册中心中去
什么是服务续约
在注册服务完成以后,服务提供者会维持一个心跳(每30s定时向EurekaServer 分发起请求)告诉EurekaServer “我还活着”
什么是失效剔除
有时候,我们的服务提供方并不一定是正常下线,可能是内存溢出,网络故障等原因导致服务无法正常工作.EurekaServer会将这些失效的服务剔除服务列表.因此它会开启一个定时任务.每隔60秒会对失效的服务进行一次剔除
什么是自我保护
当服务未按时进行心跳续约时,在生产环境下,因为网络原因,此时就把服务从服务列表中剔除并不妥当发,因为服务也有可能未宕机.Eureka就会把当前实例的注册信息保护起来,不允剔除.这种方式在生产环境下很有效,保证了大多数服务依然可用
简述什么是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更加“专业”，因为注册服务更重要的是可用性，我们可以接受短期内达不到一致性的状况。