eureka、consul、nacos三大产品对比

墨蓝 2022-11-27 00:55 246阅读 0赞

配置中心

*  eureka 不支持
 *  consul 支持 但用起来偏麻烦，不太符合springBoot框架的命名风格，支持动态刷新
 *  nacos 支持 用起来简单，符合springBoot的命名风格，支持动态刷新

### 注册中心 ###

*  [eureka][]
    
     *  应用内/外：直接集成到应用中，依赖于应用自身完成服务的注册与发现，
     *  ACP原则：遵循AP（可用性+分离容忍）原则，有较强的可用性，服务注册快，但牺牲了一定的一致性。
     *  版本迭代：目前已经不进行升级
     *  集成支持：只支持SpringCloud集成
     *  访问协议：HTTP
     *  雪崩保护：支持雪崩保护
     *  界面：英文界面，不符合国人习惯
     *  上手：容易
 *  [consul][]
    
     *  应用内/外：属于外部应用，侵入性小
     *  ACP原则：遵循CP原则（一致性+分离容忍） 服务注册稍慢，由于其一致性导致了在Leader挂掉时重新选举期间真个consul不可用。
     *  版本迭代：目前仍然进行版本迭代
     *  集成支持：支持SpringCloud K8S集成
     *  访问协议：HTTP/DNS
     *  雪崩保护：不支持雪崩保护
     *  界面：英文界面，不符合国人习惯
     *  上手：复杂一点
 *  [nacos][]
    
     *  应用内/外：属于外部应用，侵入性小
     *  ACP原则：通知遵循CP原则（一致性+分离容忍） 和AP原则（可用性+分离容忍）
     *  版本迭代：目前仍然进行版本迭代
     *  集成支持：支持Dubbo 、SpringCloud、K8S集成
     *  访问协议：HTTP/动态DNS/UDP
     *  雪崩保护：支持雪崩保护
     *  界面：中文界面，符合国人习惯
     *  上手：极易，中文文档，案例，社区活跃

**主流注册中心产品** ![format_png][]

**Apache Zookeeper -> CP**

与 Eureka 有所不同，Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。从 Zookeeper 的实际应用情况来看，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了 ，节点二也检测到节点三挂了，那这个节点才算是真的挂了），那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。

就我接触到的项目基本都不会用zookeeper来做为服务发现

**Spring Cloud Eureka  -> AP**

Spring Cloud Netflix 在设计 Eureka 时就紧遵AP原则（尽管现在2.0发布了，但是由于其闭源的原因 ，但是目前 Ereka 1.x 任然是比较活跃的）。

不知道spring抽什么风居然将Eureka闭源了，所以就不做过多解释。

**![format_png 1][]**

**Consul：**

Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。Consul 使用 Go 语言编写，因此具有天然可移植性（支持Linux、windows和Mac OS X）。

Consul 内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其他工具（比如 ZooKeeper 等），使用起来也较为简单。

Consul 遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 ；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。

目前在.net微服务中大多使用它来作为注册服务

![format_png 2][]

Consul本质上属于应用外的注册方式，但可以通过SDK简化注册流程。而服务发现恰好相反，默认依赖于SDK，但可以通过Consul Template（下文会提到）去除SDK依赖。

![format_png 3][]

Consul Template

Consul，默认服务调用者需要依赖Consul SDK来发现服务，这就无法保证对应用的零侵入性。

所幸通过Consul Template，可以定时从Consul集群获取最新的服务提供者列表并刷新LB配置（比如nginx的upstream），这样对于服务调用者而言，只需要配置一个统一的服务调用地址即可。

Consul强一致性(C)带来的是：

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

Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。

*　　Eureka保证高可用(A)和最终一致性：*

服务注册相对要快，因为不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功

当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性。  
　　　　　　其他方面，eureka就是个servlet程序，跑在servlet容器中; Consul则是go编写而成。

**Nacos：**  
　　Nacos是阿里开源的，Nacos 支持基于 DNS 和基于 RPC 的服务发现。在Spring Cloud中使用Nacos，只需要先下载 Nacos 并启动 Nacos server，Nacos只需要简单的配置就可以完成服务的注册发现。

Nacos除了服务的注册发现之外，还支持动态配置服务。动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。

一句话概括就是Nacos = Spring Cloud注册中心 + Spring Cloud配置中心。* *

*　　java架构师大多都采用它，它的确好用*

[eureka]: https://spring.io/projects/spring-cloud-netflix
[consul]: https://www.consul.io/
[nacos]: https://nacos.io/
[format_png]: /images/20221124/1dcd04d3b2d04dd38e7e30f2a2c917eb.png
[format_png 1]: /images/20221124/ed18b043c1794ff891ee5553fedf185d.png
[format_png 2]: /images/20221124/46ceb0628d584394ba4f6f8caa527143.png
[format_png 3]: /images/20221124/00517380e72c4498ad6e511603cdebc6.png