SpringCloud--Netflix Eureka 简介

一、Eureka简介

Eureka是Netflix开发的服务发现框架，本身是一个基于REST的服务，主要用于定位运行在AWS域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的.SpringCloud将它集成在其子项目spring-cloud-netflix中，以实现SpringCloud的服务发现功能。

1 Eureka组件

Eureka包含两个组件：Eureka Server和Eureka Client。

1.1 Eureka Server

Eureka Server提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册,这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
Eureka Server本身也是一个服务，默认情况下会自动注册到Eureka注册中心。如果搭建单机版的Eureka Server注册中心，则需要配置取消Eureka Server的自动注册逻辑。毕竟当前服务注册到当前服务代表的注册中心中是一个说不通的逻辑。
Eureka Server通过Register、Get、Renew等接口提供服务的注册、发现和心跳检测等服务。

1.2 Eureka Client

Eureka Client是一个java客户端，用于简化与Eureka Server的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳,默认周期为30秒，如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)。

Eureka Client分为两个角色，分别是：

Application Service(Service Provider)
Application Client(Service Consumer)

1.2.1 Application Service

服务提供方，是注册到Eureka Server中的服务。

1.2.2 Application Client

服务消费方，通过Eureka Server发现服务，并消费。

注意：在这里，Application Service和Application Client不是绝对上的定义，因为Provider在提供服务的同时，也可以消费其他Provider提供的服务；Consumer在消费服务的同时，也可以提供对外服务。

二、Eureka和Zookeeper对比

1 什么是CAP定理

CAP原则又称CAP定理,指的是在一个分布式系统中,Consistency(数据一致性)、Availability(服务可用性）、Partition tolerance(分区容错性)，三者不可兼得。CAP由Eric Brewer在2000年PODC会议上提出。该猜想在提出两年后被证明成立，成为我们熟知的CAP定理分布式系统CAP定理

分布式系统 CAP 定理

C数据一致性(Consistency)	也叫做数据原子性系统在执行某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读到最新的值，这样的系统被认为是具有强一致性的。等同于所有节点访问同一份最新的数据副本。优点：数据一致，没有数据错误可能缺点：相对效率降低。
A服务可用性(Availablity)	每一个操作总是能够在一定的时间内返回结果，这里需要注意的是"一定时间内"和"返回结果"。一定时间内指的是，在可以容忍的范围内返回结果，结果可以是成功或者是失败
P分区容错性(Partitiontorlerance)	在网络分区的情况下，被分隔的节点仍能正常对外提供服务(分布式集群，数据被分布存储在不同的服务器上，无论什么情况，服务器都能正常被访问)

定律：任何分布式系统只可同时满足二点，没法三者兼顾。

CA放弃 P	如果想避免分区容错性问题的发生.一种做法是将所有的数据(与事务相关的)/服务都放在一台机器上。虽然无法100%保证系统不会出错，但不会碰到由分区带来的负面效果。当然这个选择会严重的影响系统的扩展性。
CP放弃 A	相对于放弃"分区容错性"来说，其反面就是放弃可用性。一旦遇到分区容错故障，那么受到影响的服务需要等待一定时间，因此在等待时间内系统无法对外提供服务。
AP放弃 C	这里所说的放弃一致性，并不是完全放弃数据一致性，而是放弃数据的强一致性，而保留数据的最终一致性。以网络购物为例，对只剩下一件库存的商品，如果同时接受了两个订单，那么较晚的订单将被告知商品告罄。

对比项	Zookeeper	Eureka	描述
CAP	CP	AP	ZooKeeper 分布集群是使用主从模型实现的。在一个时间点上，只有一个 leader 真正的对外提供服务。其他的follower 都会实时备份leader 中的数据，当leader 宕机，则 follower 选举出新的 leader 对外提供服务。 Eureka 分布集群是平等模型（无主模型）所有的节点都是平等的，客户端访问任意节点都可以提供实时的服务响应。如果某节点发送宕机等故障，接收到的请求会转交给其他的节点。无主模型，每个节点的数据可能不实时
Dubbo 集成	已支持		Dubbo 开发的时候不需要考虑注册中心选择。 Spring Cloud 中推荐使用Eureka 作为注册中心，Eureka 是由Spring Cloud 子项目spring-cloud-netflix 集成的。是Spring Cloud 中的一个组件会有针对性的服务提供和发现组件。
Spring Cloud 集成	已支持	已支持	Dubbo 开发的时候不需要考虑注册中心选择。 Spring Cloud 中推荐使用Eureka 作为注册中心，Eureka 是由Spring Cloud 子项目spring-cloud-netflix 集成的。是Spring Cloud 中的一个组件会有针对性的服务提供和发现组件。
Dubbo 集成	已支持		Dubbo 开发的时候不需要考虑注册中心选择。 Spring Cloud 中推荐使用Eureka 作为注册中心，Eureka 是由Spring Cloud 子项目spring-cloud-netflix 集成的。是Spring Cloud 中的一个组件会有针对性的服务提供和发现组件。
kv 服务	已支持		Dubbo 开发的时候不需要考虑注册中心选择。 Spring Cloud 中推荐使用Eureka 作为注册中心，Eureka 是由Spring Cloud 子项目spring-cloud-netflix 集成的。是Spring Cloud 中的一个组件会有针对性的服务提供和发现组件。
Dubbo 集成	已支持		ZK 支持数据存储eureka 不支持
使用接口(多语言能力)	提供客户端	已支持	ZK 的跨语言支持比较弱
watch 支持	已支持	已支持	什么是 Watch 支持？就是客户端监听服务端的变化情况。zk 通过订阅监听来实现eureka 通过轮询的方式来实现
集群监控		metrics	metrics，运维者可以收集并报警这些度量信息达到监控目的