eureka、consul、nacos三大产品对比

配置中心

• 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
  • 雪崩保护：支持雪崩保护
  • 界面：中文界面，符合国人习惯
  • 上手：极易，中文文档，案例，社区活跃

 

主流注册中心产品 

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闭源了，所以就不做过多解释。

 

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微服务中大多使用它来作为注册服务

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

　　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架构师大多都采用它，它的确好用