1、说在前面

微服务在云原生体系中占据着浓墨重彩的一笔，注册中心则是微服务中的灵魂。通过注册中心，服务之间的访问不再需要手动更新配置，在服务实例弹性需求日益凸显的时代，重要性也就变得不言而喻了。

2、横向对比

目前对于注册中心，目前开源的主流的方案可以分成服务端模式和客户端模式两种大的类型。服务端模式主要包括：DNS, K8s（CoreDNS）；而客户端模式主要包括：Zookeeper, Etcd, Consul, Eureka, Nacos，SofaRegistry。

这里指的服务端模式是服务端通过提供可访问服务地址，而客户端模式指的是由客户端进行选择可访问的服务地址。

下面我们就从不同维度对于不同注册中心的选择进行对比：

3、逐个击破

3.1）K8s （CoreDNS）

服务注册过程大致如下：

1、CoreDNS 通过实现的控制器完成对于 Service 资源的监听，一旦发现有新建的 Service 对象，就创建一个从 Service 名称映射到 ClusterIP 的域名记录 2. kube-proxy 拉取 Service 配置，并存储在 Node 上面的 iptables 中

服务发现的过程大致如下：

1、Pod 通过 CoreDNS 完成域名到对应服务的 ClusterIP（VIP）的过程 2、请求将指向对应的 Service，之后转到对应的 Pod 的实例上面

官方链接：https://coredns.io

3.2）Zookeeper

Zookeeper 是一种分布式协调服务，主要通过 zab 协议保证数据的一致性（zab 协议本身是个较复杂的协议，这里就不拓展，感兴趣可以参考 《从 Paxos 到 Zookeeper 分布式一致性原理与实践》）。在服务注册与发现的场景下，主要应用的是 Zookeeper 的 Znode 数据模型和 Watcher 机制。

服务注册：服务提供者（Provider）启动时，会向 Zookeeper 服务端注册服务信息，即会在 Zookeeper 服务器上创建一个服务节点，并在节点上存储服务的相关数据（如服务提供者的 ip 地址、端口等）

服务发现：服务消费者（Consumer）启动时，会根据本身依赖的服务信息，向 Zookeeper 服务端获取注册的服务信息并设置 Watch，获取到注册的服务信息之后将服务提供者信息缓存在本地，调用服务时直接根据从 Zookeeper 注册中心获取到的服务注册信息调用服务。

服务通知：当服务提供者因为某种原因宕机或不提供服务之后，Zookeeper 服务注册中心的对应服务节点会被删除，因为服务消费者在获取服务信息的时候在对应节点上设置了 Watch，因此节点删除之后会触发对应的 Watcher，Zookeeper 注册中心会异步向服务所关联的所有服务消费者发出节点删除的通知，服务消费者根据收到的通知更新缓存的服务列表。官方链接：https://zookeeper.apache.org/

3.3）Consul

Conzul 天生是以数据中心维度做的服务注册与发现，所以可以很好支持对于生产环境大规模部署。在整体的设计中，Consul 结合的 AP 与 CP 模型，对于 agent 节点发现以及跨数据中心的数据同步采用了 gossip 协议，通过最终一致性的方式，提供了一个高可用的服务注册中心；而在各数据中心内部，采用了 raft 协议保证了数据的一致性。

官方链接：https://www.consul.io/docs/architecture

3.4）Eureka

Eureka 作为 Spring-Cloud 体系中御用的服务注册中心，也极其具有代表性。Eureka 的特点主要体现在该注册中心以 AP 模型为主，采用 Peer to Peer 对等通信。这是一种去中心化的架构，无 master/slave 之分，每一个 Peer 都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。

由于 Eureka 的 AP 模型设计，在应对类似于因网络故障导致部分节点失去联系等情况，Eureka 只要有节点存活依然可以提供服务。

官方链接：https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance

3.5）Nacos

Nacos 是阿里开源的，Nacos 支持基于 DNS 和基于 RPC 的服务发现，提供动态服务发现、服务配置、服务元数据及流量管理的服务。

Nacos 对非持久化服务(即需要客户端上报心跳进行服务实例续约) 采用最终一致性算法，来保障服务的可用性；而服务发现注册中的持久化服务，因为所有的数据都是直接使用调用 Nacos 服务端直接创建，因此需要由 Nacos 保障数据在各个节点之间的强一致性，故而针对此类型的服务 数据，选择了强一致性共识算法来保障数据的一致性。

官方链接：https://nacos.io/zh-cn/docs/what-is-nacos.html

3.6）SofaRegistry

SofaRegister 作为蚂蚁的服务注册中心，整体架构拆分为四个角色，客户端（Client）、会话服务器（SessionServer）、数据服务器（DataServer）、元数据服务器（MetaServer），每个角色司职不同能力组合后共同提供对外服务能力。

整体的设计优势主要体现在将连接层与存储层分开，通过 SessionServer 提供可海量拓展的连接层；同时，存储层通过分片方式做到可以横向拓展以支持大规模集群的服务注册与发现。

Client 提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。

SessionServer 会话服务器，提供客户端接入能力，接受客户端的服务发布及服务订阅请求，并作为一个中间层将发布数据转发 DataServer 存储。SessionServer 可无限扩展以支持海量客户端连接。

DataServer 数据服务器，负责存储客户端发布数据，数据存储按照数据 ID 进行一致性 hash 分片存储，支持多副本备份，保证数据高可用。DataServer 可无限扩展以支持海量数据量。

MetaServer 元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，在节点变更时及时通知集群内其他节点。MetaServer 通过 SOFAJRaft 保证高可用和一致性。官方链接：https://www.sofastack.tech/projects/sofa-registry/overview/

4、回顾小结

从各个开源的注册中心的架构以及原理上看，主流的趋势还是倾向于采用 AP 模型，通过最终一致性保障在极端情况下的服务可用性，而数据不一致导致的服务访问失效或者缺失，由服务本身的柔性来保障服务的健壮性，例如服务框架（RPC 框架或者 ServiceMesh）提供的失败快速重试策略和探活能力保障服务的稳健。