ZooKeeper、Eureka、Consul、Nacos 微服务注册中心对比

ZooKeeper、Eureka、Consul、Nacos 微服务注册中心对比

​ 服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务，原则上都应存在或者支持多个提供者，这是由微服务的分布式属性决定的。更进一步，为了支持弹性扩缩容特性，一个微服务的提供者的数量和分布往往是动态变化的，也是无法预先确定的。因此，原本在单体应用阶段常用的静态LB机制就不再适用了，需要引入额外的组件来管理微服务提供者的注册与发现，而这个组件就是服务注册中心。

CAP理论

CAP理论是分布式架构中重要理论：

• 一致性（Consistency），所有节点在同一时间具有相同的数据
• 可用性（Availability），保证每个请求不管成功或者失败都有响应
• 分隔容忍（Partition tolerance），系统中任意信息的丢失或失败不会影响系统的继续运作

关于P的理解，我觉得是在整个系统中某个部分，挂掉了，或者宕机了，并不影响整个系统的运作或者说使用，而可用性是，某个系统的某个节点挂了，但是并不影响系统的接受或者发出请求，CAP不可能都取，只能取其中2个。

原因是如果C是第一需求的话，那么会影响A的性能，因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间，期间可用性就会降低。

如果A是第一需求，那么只要有一个服务在，就能正常接受请求，但是对与返回结果变不能保证，原因是，在分布式部署的时候，数据一致的过程不可能想切线路那么快。

再如果，同时满足一致性和可用性，那么分区容错就很难保证了，也就是单点，也是分布式的基本核心，好了，明白这些理论，就可以在相应的场景选取服务注册与发现了。

服务注册中心解决方案

设计或者选型一个服务注册中心，首先要考虑的就是服务注册与发现机制。纵观当下各种主流的服务注册中心解决方案，大致可归为三类：

• 应用内：直接集成到应用中，依赖于应用自身完成服务的注册与发现，最典型的是Netflix提供的Eureka
• 应用外：把应用当成黑盒，通过应用外的某种机制将服务注册到注册中心，最小化对应用的侵入性，比如Airbnb的SmartStack，HashiCorp的Consul
• DNS：将服务注册为DNS的SRV记录，严格来说，是一种特殊的应用外注册方式，SkyDNS是其中的代表

注1：对于第一类注册方式，除了Eureka这种一站式解决方案，还可以基于ZooKeeper或者etcd自行实现一套服务注册机制，这在大公司比较常见，但对于小公司而言显然性价比太低。

注2：由于DNS固有的缓存缺陷，本文不对第三类注册方式作深入探讨。

除了基本的服务注册与发现机制，