共计 2722 个字符，预计需要花费 7 分钟才能阅读完成。
起源：https://www.cnblogs.com/jieqi…
作者：jieqing
刚开始看到 Eureka 这个单词的时候真心不会念，查了后发现他有一个好听的名字，来，大家一起念 [jʊ’rikə]
简介
Eureka 自身是 Netflix 开源的一款提供服务注册和发现的产品，并且提供了相应的 Java 封装。在它的实现中，节点之间互相平等，局部注册核心的节点挂掉也不会对集群造成影响，即便集群只剩一个节点存活，也能够失常提供发现服务。哪怕是所有的服务注册节点都挂了，Eureka
Clients（客户端）上也会缓存服务调用的信息。这就保障了咱们微服务之间的相互调用足够强壮。
Zookeeper 次要为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。已经是 Hadoop 我的项目中的一个子项目，用来管制集群中的数据，目前已降级为独立的顶级我的项目。很多场景下也用它作为 Service 发现服务解决方案。
比照
在分布式系统中有个驰名的 CAP 定理（C- 数据一致性；A- 服务可用性；P- 服务对网络分区故障的容错性，这三个个性在任何分布式系统中不能同时满足，最多同时满足两个）；
Zookeeper
Zookeeper 是基于 CP 来设计的，即任何时刻对 Zookeeper 的拜访申请能失去统一的数据后果，同时系统对网络宰割具备容错性，然而它不能保障每次服务申请的可用性。从理论状况来剖析，在应用 Zookeeper 获取服务列表时，如果 zookeeper 正在选主，或者 Zookeeper 集群中半数以上机器不可用，那么将无奈取得数据。所以说，Zookeeper 不能保障服务可用性。
诚然，在大多数分布式环境中，尤其是波及到数据存储的场景，数据一致性应该是首先被保障的，这也是 zookeeper 设计成 CP 的起因。然而对于服务发现场景来说，状况就不太一样了：针对同一个服务，即便注册核心的不同节点保留的服务提供者信息不尽相同，也并不会造成灾难性的结果。
因为对于服务消费者来说，能生产才是最重要的——拿到可能不正确的服务实例信息后尝试生产一下，也好过因为无奈获取实例信息而不去生产。
（尝试一下能够疾速失败，之后能够更新配置并重试）所以，对于服务发现而言，可用性比数据一致性更加重要——AP 胜过 CP。
Eureka
而 Spring Cloud Netflix 在设计 Eureka 时恪守的就是 AP 准则。EurekaServer 也能够运行多个实例来构建集群，解决单点问题，但不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采纳的是 Peer to Peer 对等通信。这是一种去中心化的架构，无 master/slave 辨别，每一个 Peer 都是对等的。在这种架构中，节点通过彼此相互注册来进步可用性，每个节点须要增加一个或多个无效的 serviceUrl 指向其余节点。每个节点都可被视为其余节点的正本。
如果某台 Eureka Server 宕机，Eureka Client 的申请会主动切换到新的 EurekaServer 节点，当宕机的服务器从新复原后，Eureka 会再次将其纳入到服务器集群治理之中。当节点开始承受客户端申请时，所有的操作都会进行 replicateToPeer（节点间复制）操作，将申请复制到其余 EurekaServer 以后所知的所有节点中。
一个新的 Eureka Server 节点启动后，会首先尝试从邻近节点获取所有实例注册表信息，实现初始化。EurekaServer 通过 getEurekaServiceUrls()办法获取所有的节点，并且会通过心跳续约的形式定期更新。默认配置下，如果 Eureka
Server 在肯定工夫内没有接管到某个服务实例的心跳，EurekaServer 将会登记该实例（默认为 90 秒，通过 eureka.instance.lease-expiration-duration-in-seconds 配置）。当 Eureka Server 节点在短时间内失落过多的心跳时（比方产生了网络分区故障），那么这个节点就会进入自我保护模式。
什么是自我保护模式？
默认配置下，如果 Eureka Server 每分钟收到心跳续约的数量低于一个阈值（instance 的数量 _(60/ 每个 instance 的心跳距离秒数)_ 自我爱护系数），并且继续 15 分钟，就会触发自我爱护。在自我保护模式中，EurekaServer 会爱护服务注册表中的信息，不再登记任何服务实例。当它收到的心跳数从新复原到阈值以上时，该 EurekaServer 节点就会主动退出自我保护模式。它的设计哲学后面提到过，那就是宁肯保留谬误的服务注册信息，也不自觉登记任何可能衰弱的服务实例。该模式能够通过 eureka.server.enable-self-preservation = false 来禁用，同时 eureka.instance.lease-renewal-interval-in-seconds 能够用来更改心跳距离，eureka.server.renewal-percent-threshold能够用来批改自我爱护系数（默认 0.85）。
总结
ZooKeeper 基于 CP，不保障高可用，如果 zookeeper 正在选主，或者 Zookeeper 集群中半数以上机器不可用，那么将无奈取得数据。Eureka 基于 AP，能保障高可用，即便所有机器都挂了，也能拿到本地缓存的数据。作为注册核心，其实配置是不常常变动的，只有发版和机器出故障时会变。对于不常常变动的配置来说，CP 是不适合的，而 AP 在遇到问题时能够用就义一致性来保障可用性，既返回旧数据，缓存数据。
所以实践上 Eureka 是更适宜作注册核心。而事实环境中大部分我的项目可能会应用 ZooKeeper，那是因为集群不够大，并且根本不会遇到用做注册核心的机器一半以上都挂了的状况。所以实际上也没什么大问题。
举荐
- Netflix 微服务架构设计解析
- 为什么阿里规定须要在事务注解 @Transactional 中指定 rollbackFor？
- 下一代构建工具 Gradle，比 Maven 强在哪里！
- 如何让你的 Nginx 晋升 10 倍性能？
- 面试必须要明确的 Redis 分布式锁实现原理！
学习材料分享
12 套 微服务、Spring Boot、Spring Cloud 核心技术材料，这是局部材料目录：
- Spring Security 认证与受权
- Spring Boot 我的项目实战（中小型互联网公司后盾服务架构与运维架构）
- Spring Boot 我的项目实战（企业权限治理我的项目））
- Spring Cloud 微服务架构我的项目实战（分布式事务解决方案）
- …
公众号后盾回复
arch028获取材料：：