问题：同为注册中心，Eureka要比Zookeeper好在哪，或者说为什么Cloud为什么不集成Zookeeper，在CAP理论中说道，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。我们从需求出发考虑，当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，对于服务注册功能对可用性的要求要高于一致性。
Eureka不会出现这种问题，Zookeeper则会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。
而在此Zookeeper保证的是CP, 而Eureka则是AP，显然Eureka更加合适。
但在默认配置中，Eureka Server在默认90s没有得到客户端的心跳，则注销该实例，但是往往因为微服务跨进程调用，网络通信往往会面临着各种问题，比如微服务状态正常，但是因为网络分区故障时，Eureka Server注销服务实例则会让大部分微服务不可用，这很危险，因为服务明明没有问题。为了解决这个问题，Eureka 有自我保护机制，通过在Eureka Server配置参数，可启动保护机制它的工作原理是：当Eureka Server节点在短时间内丢失过多的客户端时（可能发送了网络故障），那么这个节点将进入自我保护模式，不再注销任何微服务，当网络故障回复后，该节点会自动退出自我保护模式。
实战：
Eureka服务端开发（非常简单的3步完成）
1.从官网下载脚手架项目https://start.spring.io/
2.修改一下配置文件
3.启动，本质上也是一个SpringBoot项目
把下载好的Demo导入编译器，打开application.properties或 .yml配置文件
#配置端口
server:
port: 8761 #服务端口
#配置服务名称
spring:
application:
name: service-name
#是否将自己注册到Eureka服务中，本身就是服务端，所以无需注册
#是否从Eureka中获取注册信息
#客户端和服务端交互地址
eureka:
client:
registerWithEureka: false
fetchRegistry: false
serviceUrl:
defaultZone: http://127.0.0.1:${server.port}/eureka/