前言
本篇博客主要是针对微服务中注册中心，到底用哪个进行比较，其实还是看公司的业务场景，各有优缺点，只能找适合自己的，每个产品都是时代的产物，不同年代，不同场景下诞生的。
| 组件名 | 语言 | CAP | 服务健康检查 | 对外暴露接口 | springCloud集成 |
|---|---|---|---|---|---|
| Eureka | Java | AP | 可配支持 | HTTP | 已集成 |
| Consul | Go | CP | 支持 | HTTP/ DNS | 已集成 |
| ZooKeeper | Java | CP | 支持 | 客户端 | 已集成 |
题外话：CAP
CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
-
聊一聊
-
一致性（C）：
在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本） -
可用性（A）：
在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性） -
分区容忍性（P）：
以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。
如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件，因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足，因此在进行分布式架构设计时，必须做出取舍。当前一般是通过分布式缓存中各节点的最终一致性来提高系统的性能，通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。
通常使用类似memcached 之类的 NOSQL 作为实现手段。虽然 memcached也可以是分布式集群环境的，但是对于一份数据来说，它总是存储在某一台 memcached服务器上。
如果发生网络故障或是服务器死机，则存储在这台服务器上的所有数据都将不可访问。由于数据是存储在内存中的，重启服务器，将导致数据全部丢失。当然也可以自己实现一套机制，用来在分布式memcached 之间进行数据的同步和持久化，但是实现难度是非常大的 。
