为什么Eureka是AP，zookeeper是CP

为什么Eureka是AP，zookeeper是CP

随着微服务的盛行，spring cloud微服务架构被很多人引荐和使用，所以再次回顾下eureka于zk的区别并且从理论层面去更深层次的理解eureka如何保证AP的。

首先再回顾下eureka高可用架构图

在大致理解下这张图的含义

服务提供者（applicatonService）向eurekaServer发起注册（register），心跳续约（renew），服务下线（cancel），客户端服务获取（get）。

宕机情况：

在zookeeper集群环境下如果有zk发生了宕机，那么zk会发起选举，对比令牌等一系列选举 *** 作，此时的zk是不可用的，所以zk会保证强一致性。选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

eurekaServer之间也是相互进行注册（replicate），那么当有3台eurekaServer中的其中一台宕机客户端请求会自动切换 到新的Eureka节点（与rocketMQ大致一个思想，这就是为什么rocketMQ不使用ZK从而使用nameServer来保证高可用）当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中；而对于它来说，所有要做的无非是同步一些新的服务 注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。

并且在网络分隔发生故障时每个eureka节点依然可以堆外提供服务，接收新 的服务注册同时将它们提供给下游的服务发现请求。新发布的服务仍然可以被发现与访问。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。

自我保护模式：

eureka的自我保护模式简而言之就是15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，eureka不会再注册列表中移除长时间没有收到心跳的过期服务。但是这个自我保护模式慎用，需要具体情况具体分析，例如你在生产发布新版本应用，不希望在部署服务时还被用户访问到，此时就需要关闭自我保护模式，不然eureka不会对正在发布的节点进行剔除，用户依然可以访问到该节点从而导致无数据返回。

自我保护模式失效：

eurekaServer端默认30s频率来向服务提供者发送心跳，如果是2个eurekaServer则希望收到最少的心跳为 实例数 x 2 x 85% = 最少心跳数。

2台实例的话希望收到的心跳是 2 x 2 x 82% = 3.4，3个心跳

但是如果更改了心跳时间15s发送一次，一分钟会有4个心跳，而运行一段时间后2个eurekaServer挂掉一个，对应公式则为 1 x 2 x 82% = 3.4，还是3个心跳，如果使用自我保护模式 不建议降低心跳时间。

REGION 与 ZONE：

region与zone的概念来源于亚马逊的AWS，因为对于大公司而言为了保证服务机房的高可用性一般会进行多城市机房部署（异地灾备），例如我之前所参与某APP中一些业务的高可用方案。

在北京A地区，北京B地区，武汉地区，都有该业务机房部署。北京B作为backUp机房。

而对于每个地区的机房又划分成2个区域，分别为电信区域，联通区域。比如一个用户系统部署在4台机器，2台在电信机器，2台在联通的区域。其区别就算对应机器的网络运营商不一样。eureka的region 就相当于北京A，北京B，武汉地区。zone就相当于电信机器，联通机器。以前为了避免运营商网络故障导致访问不可用的情况我们把应用部署在电信和联通区分的机器，比如当联通运营商有问题，我们在nginx上把联通的流量切换到电信上，但是跨运营商访问延迟会比较高，电信运营商应用请求联通运营商应用肯定不如电信运营商应用访问电信运营商的要更快，所以这时候zone的概念就体现出来了，虽然在不同region但是zone会优先请求相同zone的实例。可以看下图。

 后面源码对eureka进行分析讲解，先恰饭。