为什么Eureka是AP，zookeeper是CP

为什么Eureka是AP，zookeeper是CP 这个问题大多数人的回答是因为ZK如果leader挂了，那么会进行投票选举，而选举的时候ZK是无法提供服务的。对没错，所以我们来详细分析下为什么ZK保证的是CP而eureka保证的是AP。

本文试图搞清楚以下问题：

        1.eureka 如何保证AP。

        2.ZK为什么不能保证AP。

        3.什么是自我保护模式。

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

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

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

服务提供者（applicatonService）向eurekaServer发起注册（register），心跳续约（renew），服务下线（cancel），客户端服务获取（get）。eureka server 之间也是相互注册。

zookeeper 架构图:

       

 Zookeeper是以节点的形式去管理客户端，节点分为很多种 临时节点、持久节点等。客户端对zk进行注册后，zk的watch机制会去监听节点数据发生的变化。zk的核心是原子广播（zab协议）来保证各个server之前的同步，为了不跑题这里不做过多赘述。

宕机情况：

在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的实例。可以看下图。

 总结：

         1.eureka 如何保证AP。

                eureka在设计时的分区容错保证了eureka各个节点都是平等的，只要不是所有节点都挂掉eureka就可以正常注册与使用，不会像zk出现选举而短暂不可用的情况。

        2.ZK为什么不能保证AP。

                当leader节点因为网络故障或者其他原因导致与其他节点失去联系，剩余节点则会发起选举，选举期间导致短暂不可用的情况，所以保证了强一致性而无法保证高可用性。

        3.什么是eureka server自我保护模式。

                eureka server自我保护模式指的是如服务长时间没有收到心跳导致未能及时续约会等待修复，而不是服务剔除，是一种针对网络异常波动的安全措施，能够保证服务的高可用。自我保护模式情况下如果该服务长时间未能收到心跳而导致服务过期，eureka server仍然能够接收新的服务注册和查询，但不会同步到其他节点上，当前节点依然可用，网络稳定后新注册的信息会被同步到其他节点中。而zk在网络环境不够稳定的情况下则会进行选举，导致短暂不可用情况。

后面源码对eureka进行分析讲解。

关注我的公众号 LearnMoreDoMore 可以及时看到更多技术分享文章（不会该死的卖课广告）。