1.2 Eureka的替换方案#

1.2.1 Zookeeper#

• Zookeeper是一个分布式的，开放源代码的分布式应用程序协调服务，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

1.2.2 Consul#

• Consul是近几年比较流行的服务发现工具。
• Consul的三个主要应用场景：服务发现、服务隔离、服务配置。

1.2.3 Nacos#

• Nacos是阿里巴巴推出来的一个新开源项目，这是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。Nacos致力于帮助您发现、配置和管理微服务。Nacos提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据以及流量管理。Nacos帮助您更敏捷和容易的构建、交付和管理微服务平台。Nacos是构建以“服务”为中心的现代应用架构（例如微服务范式、云原生范式）的服务基础设施。

2 Consul简介#

2.1 概述#

• Consul是HashiCorp公司推出的开源工具，用于实现分布式系统的服务发现和配置。和其他分布式服务注册和发现的方案，Consul的方案更“一站式”，内置了服务注册和发现框架、分布式一致性协议实现、健康检查、key/value存储、多数据中心方案，不再需要依赖其他工具（比如Zookeeper等）。使用起来也比较简单。Consul使用Go语言编写，因此具有天然移植性（支持Linux、Windows和Mac OS X），安装包仅包含一个可执行的文件，方便部署，和Docker等轻量级容器可以无缝配合。

2.2 Consul的优势#

• 采用Raft算法来保证一致性，比服务的Paxos算法更直接。Zookeeper采用的是Paxos算法，而Consul以及etcd采用的是Raft算法。
• 支持多数据中心，内外网的服务采用不同的端口进行监听。多数据中心集群可以避免单数据中心的单点故障，而其部署则需要考虑网络延迟、分片等情况。Zookeeper和etcd均不提供多数据中心功能的支持。
• 支持健康检查。etcd不提供此功能。
• 支持http和dns协议接口。Zookeeper的集成较为复杂，etcd只支持http协议。
• 官方提供web管理界面。etcd无此功能。

2.3 Consul的特性#

• 服务发现。
• 健康检查。
• key/value存储。
• 多数据中心。

2.3 Consul和Eureka的区别#

2.3.1 一致性#

• Consul：强一致性（CP）：

• 1️⃣服务注册相比Eureka会稍慢一些。因为Consul的Raft协议要求必须过半的节点都写入成功才认为注册成功。

• 2️⃣Leader挂掉后，重新选举期间整个Consul不可用。保证了强一致性，但牺牲了可用性。

• Eureka：高可用性和最终一致性（AP）：

• 1️⃣服务注册相对要快，因为不需要等注册信息复制到其他节点，也不保证注册信息是否复制成功。

• 2️⃣当数据出现不一致的时候，虽然A,B上的注册信息不完全相同，但是每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如果保证了可用性但牺牲了一致性。

2.3.2 开发语言和使用#

• Eureka是Servlet程序，跑在Servlet容器中。
• Consul是Go语言编写而言的，安装启动即可。

关于consul与eureka区别

CAP定理：指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可同时获得。

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（所有节点在同一时间的数据完全一致，越多节点，数据同步越耗时）

可用性（A）：负载过大后，集群整体是否还能响应客户端的读写请求。（服务一直可用，而且是正常响应时间）

分区容错性（P）：分区容忍性，就是高可用性，一个节点崩了，并不影响其它的节点（100个节点，挂了几个，不影响服务，越多机器越好）

CAP理论：

就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡

C A 满足的情况下，P不能满足的原因：

数据同步(C)需要时间，也要正常的时间内响应(A)，那么机器数量就要少，所以P就不满足

CP 满足的情况下，A不能满足的原因：

数据同步(C)需要时间, 机器数量也多(P)，但是同步数据需要时间，所以不能再正常时间内响应，所以A就不满足

AP 满足的情况下，C不能满足的原因：

机器数量也多(P)，正常的时间内响应(A)，那么数据就不能及时同步到其他节点，所以C不满足

Zookeeper和Consul ：

CP设计，保证了一致性，集群搭建的时候，某个节点失效，则会进行选举行的leader，或者半数以上节点不可用，则无法提供服务，因此可用性没法满足

Eureka：

AP原则，无主从节点，一个节点挂了，自动切换其他节点可以使用，去中心化

结论：分布式系统中P,肯定要满足，所以只能在CA中二选一
没有最好的选择，最好的选择是根据业务场景来进行架构设计
如果要求一致性，则选择zookeeper、Consul，如金融行业
如果要求可用性，则Eureka，如电商系统

参考链接：

https://www.jianshu.com/p/8494698d08b2