注册中心Eureka、Zookeeper、Consul的异同点
三种方式的异同
| 组件名 | 语言 | CAP | 服务监控检查 | 对外暴露接口 | Springcloud集成 |
|---|---|---|---|---|---|
| Eureka | Java | AP | 可配支持 | HTTP | 已集成 |
| Consul | Go | CP | 支持 | HTTP/DNS | 已集成 |
| Zookeeper | Java | CP | 支持 | 客户端 | 已集成 |
CAP理论
CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
-
C：Consistency （强一致性）：一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
-
A：Available （可用性）：可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
-
P：Partition tolerance （分区容错性）：分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足 。
因此在进行分布式架构设计时，必须做出取舍。当前一般是通过分布式缓存中各节点的最终一致性来提高系统的性能，通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。通常使用类似 memcached 之类的 NOSQL 作为实现手段。虽然 memcached 也可以是分布式集群环境的，但是对于一份数据来说，它总是存储在某一台 memcached 服务器上。如果发生网络故障或是服务器死机，则存储在这台服务器上的所有数据都将不可访问。由于数据是存储在内存中的，重启服务器，将导致数据全部丢失。当然也可以自己实现一套机制，用来在分布式 memcached 之间进行数据的同步和持久化，但是实现难度是非常大的 。 -
最多只能同时较好的满足两个
CAP理论关注粒度是数据，而不是整体系统设计的策略
我们根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三大类。
-
CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强
-
CP - 满足一致性，分区容错性的系统，通常性能不是特别高
-
AP - 满足可用性，分区容错性的系统，通常可能对一致性要求低一些
-
AP架构(Eureka)
Eureka 采用的是AP架构，只满足可用性和分区容错性。
且Eureka有自我保护机制，更强调的是AP，保证服务的高可用，微服务就是偶尔宕机掉线了，一时半会不会立刻删除。
当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。
结论：违背了一致性C的要求，可满足可用性和分区容错，即AP。
CP架构(Zookeeper/Consul)
Zookeeper 和 Consul采用的是CP架构，满足一致性和分区容错性
当网络分区出现后，为了保证一致性，就必须拒绝请求，否则无法保证一致性。
结论：违背了可用性A的要求，只满足一致性和分区容错，即CP。
Zookeeper、Consul注册的微服务是一个临时节点，只要微服务不可用，且发心跳测试收不到，就迅速剔除微服务；当微服务恢复过来以后，则会重新换一个serviceID，此时的微服务已经不是之前那一个了。