初学SpringCloud：简单的比较一下Eureka，ZooKeeper，Consul

1、背景介绍

我本人简单的学习了Eureka作为服务注册中心，ZooKeeper作为服务注册中心，Consul作为服务注册中心。目前我本人的这个学习过程已经结束了，现在我想非常简单的做一个对比总结。本来我本人就是学习的非常的浅薄

其实CSDN上面有很多记录它们之间的区别的博客，很多都是大佬，不过我还是想写一下博客，毕竟这是我自己的学习的知识，尽管会有以下肤浅甚至是人云亦云。

2、简单的对比

首先就是有一个CAP理论，是需要首先了解的。 CAP分别指的就是   数据一致性，高可用，分区容错。

我觉得这篇链接里面的博客分析的挺好的，推荐一下（我本人也是看完了，加上我自己的语言，才写了下面的我自己的理解）：CAP原理详解_u013332124的专栏-CSDN博客_cap原理

C  数据一致性：简单的理解就是指  无论从集群的那一个结点访问到的数据都是一样的。这个就牵扯到负载均衡的算法，比如轮询，随机等。数据一致性还必须是强一致性的，也就是必须要保持完完全全的一致性。

A  可用性：可以简单的理解为集群的每一个结点，即使与其他的结点之间由于网络问题断了联系，但是依旧要为所有的访问给予合理的返回结果。

P  分区容错：其实我个人感觉，AC都是很容易理解的，唯独P分区容错是最不容易理解的。我能够记住的一点是，分布式微服务的系统都是必须要满足P分区容错的。简单的理解吧，P分区容错就是允许物理上通过网络相连的集群之间出现数据信息不一致的情况。想一下，如果两个集群在物理上不是在同一个地方，那就需要通过网络相连。网络是不可靠的，这样的话两个集群之间的通信肯定就会出现错误。所以，就需要允许它们之间有信息不一致的错误，也就是  分区容错。如果不想满足分区容错， 不想有信息不一致的错误， 那就需要把两个集群放在同一个机房里面。哈哈哈，这只是我饿简单的理解。

所以说，只要是分布式的体系架构，都是要满足P的。但是呢，还有一个问题，A和C是不能同时满足的，或者说是不能都100%满足的。所以摆在我们面前的就是有两种选择了， 要么是AP，要么是CP。

但是，又转折了，虽然AC两者不能都100%的满足，我们可以优化系统的布局结构，以此来作出尽量少的牺牲，使得两条腿的长短差距不是那么的大。

回到正题上来：

Eureka服务注册中心满足   AP，它使用的是JAVA语言开发的； ZooKeeper服务注册中心满足CP，它使用的是JAVA语言开发的；Consul服务注册中心满足CP，它使用的是Go语言开发的

还有一个  健康检查 名词：

什么是健康检查呢？可以简单的从字面上去理解。每一个微服务模块就像是人一样，它也是会出现问题的，可能是因为网络，可能是因为人为的破坏等。反正就是出现问题了，不能正常的提供服务了。当我们的系统很庞大的时候，我们有时候很难排查出究竟是那一个微服务模块出现了问题，这个时候呢，如果服务注册中心能够帮助我们去自动监测就好了，直接可视化的展现出来那一个微服务不可用了。这就是  健康检查机制。 服务注册中心和每一个注册进去的微服务模块之间都是有定期的联系的，比如说10秒吧。每10秒微服务模块要向服务注册中心发送一个心跳包，以此来确认这个微服务模块是健康的。这个时间间隔也是可以在微服务模块的application文件中进行设置的。如果服务注册中心连续多次没有收到一个微服务模块的心跳包，就会认定这个微服务模块出现了故障，不能够正常的提供服务了，就会把这个微服务模块从服务注册中心的注册列表中剔除出去。

Eureka，ZooKeeper，Consul都是支持健康检查的。

其次就是可视化界面的问题：

我这里说的可视化界面就是服务注册中心启动以后，有没有Web前端的界面，可以让我们直接直观的看到注册的情况等。Eureka和Consul都是有自带的Web前端界面的。ZooKeeper没有默认自带的Web前端界面。但是我们可以自己配置ZooKeeper的可视化Web前端界面。

最后就是SpringCloud集成的情况：

Eureka，ZooKeeper，Consul都被SpringCloud集成了。

它们三个的对比我就非常浅显的记录到这里了，因为我本人也是学的非常的浅显，只是看了网课，查了少许的博客而已， 今后我有长进的话，还会进一步补充的！

欢迎屏幕前的大佬前来指正交流！！！