1. Spring Cloud Netflix
Spring Cloud Netflix 是Spring Cloud 的核心子项目，是对Netflix公司一系列开源产品的封装。它为Spring Boot应用提供了自动配置的整合，只需要通过一些简单的注解，就可以快速的在Spring Cloud应用中使用。
它主要提供以下模块：
服务发现和注册（Eureka）
客户端负载均衡（Ribbon)
断路由（Hystrix)
只能路由（Zuul)
2. 服务注册和发现（Eureka）
调用关系图：
服务注册和发现的具体实现：
新建一个服务端（注册中心）工程，引入依赖。
pom文件：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
在工程启动类上加上@EnableEurekaServer注解，配置application.properties文件
# server (eureka 默认端口为：8761)
server.port=8761
# spring
spring.application.name=spring-cloud-server
# eureka
# 是否注册到eureka
eureka.client.register-with-eureka=false
# 是否从eureka获取注册信息
eureka.client.fetch-registry=false
# eureka服务器的地址（注意：地址最后面的 /eureka/ 这个是固定值）
eureka.client.serviceUrl.defaultZone=http://localhost:${server.port}/eureka/
访问http://localhost:8761/如下
注册到本注册中心的服务可能由于刚启动，需要校验一下服务，所以会出现保护模式。
接下来注册一个服务提供者，其实它是一个Eureka客户端，实现方式如下：
先新建一个服务，引入如下pom文件
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
在该服务的启动类中添加注解@EnableEurekaClient，配置端口及服务名称信息等
server.port=8762
spring.application.name=spring-cloud-provider
# 要注册到的注册中心地址
eureka.client.serviceUrl.defaultZoon=http://localhost:8761/eureka/
启动该工程，访问http://localhost:8761/，会发现在Instances currently registered with Eureka中存在该服务的信息，表示该服务提供者已经被注册成功了。
再创建一个工程，同样引入客户端以来和添加@EnableEurekaClient，修改配置文件的服务名称和端口，注册中心地址与提供者保持一致，如下：
server.port=8888
spring.application.name=spring-cloud-consumer
# 要注册到的注册中心地址
eureka.client.server-url.defaultZoon=http://localhost:8761/eureka/
启动该工程，访问http://localhost:8761/，会发现在Instances currently registered with Eureka中存在该服务的信息，表示该服务消费者已经被注册成功了。
注意：由于spring-cloud-starter-netflix-eureka-client没有依赖tomcat，所以在创建客户端的时候，需要加入以下依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
否则会报无法创建bean的错误。
3. Eureka和zookeeper的对比
3.1 分布式系统的CAP理论
一致性（C）:所有节点上的数据时刻保持同步。
可用性（A）:每个请求都能接收到一个响应，无论响应失败还是成功。
分区容错性（P）: 系统应该能持续提供服务，即使系统内部有消息丢失。
由于分区容错性在分布式系统中必须要保证，所以我们只能在A和C之间进行权衡，Zookeeper保证的是CP,而Eureka保证的是AP
3.2 Zookeeper保证CP
Zookeeper是个cp的，即任何时刻对Zookeeper的请求访问都能得到一致的数据结果，同时系统对网络分割具有容错性，但是它不能保证每次服务请求都可用，也就是说zookeeper可能会在极端情况下丢弃一些请求。
3.3 Eureka保证AP
Eureka在设计时就优先保证了可用性，我们可以容忍注册中心返回的是几分钟以前的注册信息，但是不能够接受服务直接down掉 不可用，也就是说，服务注册功能对可用性的要求高于一致性。
如果Eureka服务节点在短时间内失去了大量的心跳连接，那么这个节点将进入”自我保护模式“，同时保留那些”心跳死亡”的服务注册信息不过期，此时，这个Eureka节点对于新的服务还能提供注册服务，对于死亡的仍然保留，以防还有客户端向其发送请求，当故障恢复后，这个节点会推出自我保护模式，Eureka的哲学是，同时保存好数据和坏数据，总比丢失数据要更好。
至于运用中使用什么为注册中心更具业务和需求来定，没有最好的架构，只有最合适的架构。