优先了解CAP 定理：
CAP 原则又称 CAP 定理，1998年，加州大学的计算机科学家 Eric Brewer 提出的，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得（我们常说的鱼和熊掌不可兼得）。如下图
1、一致性（Consistency，C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）。
2、可用性（Availability，A）：在一个分布式系统的集群中一部分节点故障后，该集群是否还能够正常响应客户端的读写请求。（对数据更新具备高可用性）。
3、分区容错性（Partition tolerance，P）：大多数的分布式系统都分布在多个子网络中，而每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如阿里巴巴的服务器（不知道各位有没有发现，不管你到那个城市去，你访问的服务器总是该城市的，其中使用 了算法，由于篇幅有限就不再这儿一一讲解了），一台服务器放在上海，另一台服务器放在北京，这就是两个区，它们之间可能存在无法通信的情况。在一个分布式系统中一般分区容错是无法避免的，因此可以认为 CAP 中的 P 总是成立的。CAP 理论告诉我们，在 C 和 A 之间是无法同时做到。
Eureka
Eureka是spring cloud中的一个负责服务注册与发现的组件。遵循着CAP理论中的A(可用性)P(分区容错性)。
一个Eureka中分为eureka server和eureka client。其中eureka server是作为服务的注册与发现中心。eureka client既可以作为服务的生产者，又可以作为服务的消费者。具体结构如下图：
我理解为，Eureka就是服务注册中心，springcloud所有的服务都需要注册到上面，相当于一个集成，把分散的个个服务进行汇总，方便进行发现与调用。注册到eureka，可以动态扩容，迁移，不需要修改业务服务。如果不注册到eureka，就需要在业务服务中写死spring cloud config的地址，如果以后spring cloud config服务迁移到其他服务器就需要所有的业务服务修改。
当spring cloud config注册到eureka之后，其他注册到eureka的服务就可以通过spring cloud config的注册名称来获取到具体的访问地址了。
不注册之前，eureka下的其他服务要获取spring cloud config中保存的配置时候，需要配置具体的ip地址。而注册之后，只需要通过服务名称就可以获取了，天然的还附带了高可用部署时候的负载均衡。
Zookeeper
它是一个分布式服务框架，是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
简单来说zookeeper=文件系统+监听通知机制。
1、 文件系统
Zookeeper维护一个类似文件系统的数据结构：
每个子目录项如 NameService 都被称作为 znode(目录节点)，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。
2、 监听通知机制
客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。
简单理解：zookeeper也可以做为服务注册中心，或者作为一个监听节点的方式
作为服务中心的区别：
ZooKeeper 基于 CP，不能保证高可用，Eureka 基于AP，能保证高可用。作为注册中心而言，配置是不经常变动的，只有当新版本发布或者服务器出故障时会变动。CP 不合适于配置经常变动的，而 AP 在遇到问题时可以牺牲其一致性来保证系统服务的高可用性，既返回旧数据。
目前公司产品采用俩者结合方式，部署在客户机器上，zookeeper用于部署报表引擎，操作员中心等不怎么需要修改配置的服务，eureka是用于部署公司产品的具体的一些springcloud服务，这些具体的微服务构成了真正的一个项目。
参考了许多博客才做出这么简单的东西，感谢曾经的前行者。
Eureka 与 zookeeper 的区别、原理及各自优缺点
踏实一些，不要着急，你想要的，岁月都会给你！小吴加油
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
