【Java面试-分布式】Consul和Eurka区别

【2019 Java面试】Consul和Eureka区别

1. 前言

Consul 和 Eureka 在微服务架构中都是作为 服务注册和服务发现 组件。

在微服务应用中，服务的实例数量和网络地址都是动态变化的，这对运维提出来了巨大的挑战，因此动态的服务注册和服务发现尤为重要

2. 解决问题

在一个分布式系统中，服务注册与发现组件主要解决两个问题：服务注册和服务发现。

• 服务注册：服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port，以及暴露服务自身状态以及访问协议等信息。

• 服务发现：服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。

除此之外，服务注册与发现需要关注监控服务实例运行状态、负载均衡等问题。

• 监控：微服务应用中，服务处于动态变化的情况，需要一定机制处理无效的服务实例。一般来讲，服务实例与注册中心在注册后通过心跳的方式维系联系，一旦心跳缺少，对应的服务实例会被注册中心剔除。
• 负载均衡：同一服务可能同时存在多个实例，需要正确处理对该服务的负载均衡。

3. 分布式系统的CAP原理

CAP原则，指的是在一个分布式系统中，Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性)，不能同时成立。

• 一致性：它要求在同一时刻点，分布式系统中的所有数据备份都处于同一状态。
• 可用性：在系统集群的一部分节点宕机后，系统依然能够响应用户的请求。
• 分区容错性：在网络区间通信出现失败，系统能够容忍。

一般来讲，基于网络的不稳定性，分布容错是不可避免的，所以我们默认CAP中的P总是成立的。

一致性的强制数据统一要求，必然会导致在更新数据时部分节点处于被锁定状态，此时不可对外提供服务，影响了服务的可用性，反之亦然。因此一致性和可用性不能同时满足。

我们接下来介绍的服务注册和发现组件中，Eureka满足了其中的 AP(可用性和分区容错性)，Consul和Zookeeper满足了其中的CP(一致性和分区容错性)。

4. Eureka和Consul的区别

最大的区别是：
Eureka保证AP，Consul保证CP。

Consul强一致性©:
1. 服务注册相对Eureka会稍慢一些。因为Consul的raft协议要求必须过半的节点写入数据成功才认为注册成功。
2. Leader 挂掉之后，重新选举期间，整个Consul不可用，Consul保证一致性的前提下牺牲了可用性。

Eureka保证高可用性和最终一致性：
1. 服务注册相对较快，因为不需要等注册信息 replicate 到其他节点，也不保证注册信息能否 replicate 成功。
2. 当数据出现不一致的时候，虽然A，B上的注册信息不一致，但每个 Eureka节点依然能够正常提供服务，这会出现查询服务时，如果A查不到，但请求B可以查到。如此保证了可用性但是牺牲了一致性

组件名	语言	CAP	一致性算法	服务健康检查	对外暴露接口	Spring Cloud集成
Eureka	Java		AP	无	可配支持
Consul	Go	CP	Raft	支持	HTTP/DNS	已集成
Zookeeper	Java	CP	Paxos	支持	客户端	已集成

参考：

服务发现的基本原理与比较：Eureka vs Consul vs Zookeeper

Spring Cloud Eureka Consul使用和对比