springcloud入门——eureka/zookeeper/consul异同点

Eureka、Zookeeper、Consul作为三个不同的服务注册中心，拥有相同的功能（都能完成服务注册功能，都能进行集群等等），也具有不同的特性（自我保护机制不一样等等）。下面，对三方的异同点进行一定的分析：

首先Eureka和Consul都具有自己的前端页面，而zookeeper没有。编程者可以在网页上查看、管理在服务中心入驻的微服务，而zookeeper需要通过指令进行管理。

再者，我们需要先认识一下CAP理论：

CAP：

• C：Consistency (强一致性)

• A：Availability (可用性)

• P：Partition tolerance （分区容错性)

 

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求。

因此，根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三大类:

    CA - 单点集群，满足—致性，可用性的系统，通常在可扩展性上不太强大。
    CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。
    AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

作为分布式服务架构，必须满足P要求，所以服务注册中心就在AP与CP之间选择。 

Eureka是符合AP架构下的服务注册中心：

当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。

结论：违背了一致性C的要求，只满足可用性和分区容错，即AP

简单举个例子：每年双十一，京东淘宝都需要保证自己服务器的可行性，所以他们一般会选择AP架构，否则由于一些数据的传输失败导致服务器返回错误参数无法可用，那么损失就很大了。所以，他们会选择牺牲一部分数据的正确性，比如：点赞数、评论内容等等不影响订单购买的数据，来确保服务器的可用。

同时Eureka的自我保护机制就是出于对AP的践行：

在自我保护模式中（当网络故障等原因，导致大量注册微服务被注销），Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。

自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留）也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮、稳定（即确保可用性A）。

ZooKeeper/Consul则是属于CP架构的服务注册中心

当网络分区出现后，为了保证一致性，就必须拒接请求，否则无法保证一致性。

结论：违背了可用性A的要求，只满足一致性和分区容错，即CP。