什么是注册中心

随着软件开发技术的迭代升级，后端服务体系架构由最初的单体架构，逐步演进为分布式SOA（Service-Oriented Architecture）架构，最终演进为具备云原生特征的微服务体系架构。在微服务体系架构中，不同的功能模块，甚至业务模块均以细粒度被拆分到不同的机器上部署，每个机器上所部署的微服务只具有单一且不可拆分的职能，不同微服务之间通过RPC（远程过程调用）进行相互通信。同时，公共的功能组件（如配置中心、注册中心、日志中心等）被独立出来部署和管理，并与应用业务解耦合。注册中心作为微服务架构中的关键组件之一，负责服务注册与发现、负载均衡和故障转移，在微服务应用的整体运转中扮演极其核心的角色。注册中心的工作模式如下图所示：

目前，业界较常用的开源注册中心包括但不限于Nacos、Zookeeper、Eureka和Consul，不同注册中心均能在一定程度上实现上述所说的功能，但生产环境中的技术选型，需要将实际情况结合注册引擎自身的技术特点来进行。

Nacos

Nacos是Dynamic Naming and Configuration Service的首字母简称，是由阿里开源的一个注册配置中心，由Java实现。是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

Nacos最大的特点就是将注册中心和配置中心结合为一个整体服务，但在代码内部，这两个模块又具有较强的隔离性，其实现方式有着较大的差异。例如，Nacos配置中心使用CP模式，而注册中心使用AP模式等。在进行server部署时，也可以选用只开启某个模块。同时，Nacos也支持很多高级功能，例如Namesapce隔离、鉴权、灰度发布、配置监听等等，这就使得Nacos源码十分繁琐，隐藏bug的几率也会随着提高。

早期1.0版本的Nacos存在很多bug，2.0版本的Nacos虽然在稳定性方面有较大提升，但仍具有一定的宕机风险。其中，最为臭名昭著的一个bug就是，在Nacos的内置数据库derby模式下使用集群部署，底层的jraft协议和derby没有较好的兼容，其稳定性就会大大下降。

Zookeeper

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，由Java实现，是Google的Chubby一个开源的实现。Zookeeper的本职并不是注册中心，而是一个分布式非关系型文件存储服务。但由于它优秀而稳定的表现，加以改造就可以将其作为注册中心在生产环境中使用。

Zookeeper作为最早诞生的注册中心选型，使用paxos作为分布式共识协议。经过长期的演进和大量的生产实践，Zookeeper已经具备较好的稳定性，可放心使用。但是由于Zookeeper在设计之初本身只是一个存储服务，导致Zookeeper在用作注册中心时缺乏一些高级功能，只能实现基本的服务注册、发现。

Eureka

Eureka是Netflix开发的服务发现框架，由Java实现，SpringCloud将它集成在自己的子项目spring-cloud-netflix中。Eureka最大的特点就是轻量而稳定，其部署流程十分容易掌握，server之间会使用简单的共识协议进行数据同步备份。

Eureka是一个十分轻量的注册中心，由于只在内存中记录服务数据，导致其没有持久化需求，在部署时因磁盘IO的波动而产生的影响被降低到零。Eureka只支持基本的服务注册、发现和若干高级功能，例如差分获取、服务上下线、雪崩保护等。但总体来说，主要得益于其简单独特的AP共识协议，Eureka的稳定性是最高的，各种故障情况都可以顺利应付。

Consul

Consul是HashiCorp公司推出的开源注册中心，用于实现分布式系统的服务发现与配置，由Golang实现。 Consul是分布式的、高可用的、可横向扩展的。

对比分析

注册中心都可以看作是一个高级的DNS服务器，都被Spring cloud支持为组件。但是，不同的注册引擎在不同方面有细微的差别，例如：与客户端交互使用的协议不同（http、dns、tcp），探活使用的协议或者说方式不同（http、tcp、icmp，实例主动上报 vs 注册中心主动探测），在高可用方面遵循的设计原则（AP vs CP），是否支持一些高级的能力，如雪崩保护、健康保护阈值，是否被dubbo支持（只有nacos和zk被dubbo支持）等。不同注册引擎在不同方面的差异性细节详见下表：

总体而言，如果只想使用基本的服务注册和发现功能，直接选用Eureka即可获得较好的稳定性；如果想使用更多的高级功能，以及融入配置中心的相关能力，可以考虑使用Zookeeper和Nacos，但是会牺牲稳定性；如果微服务技术栈大多为Golang，可以选用Consul以获取最好的兼容性。