本文源码：GitHub·点这里 || GitEE·点这里

一、注册中心简介

1、基础概念

在分布式架构的系统中注册中心这个概念就已经被提出了，最经典的就是 Zookeeper 中间件。

微服务架构中，注册中心是最核心的基础服务之一，注册中心可以看做是微服务架构中的通信中心，当一个服务去请求另一个服务时，通过注册中心可以获取该服务的状态，地址等核心信息。

服务注册主要关系到三大角色：服务提供者、服务消费者、注册中心。

2、流程和原理

基础流程

• 服务启动时，将自身的网络地址等信息注册到注册中心，注册中心记录服务注册数据。
• 服务消费者从注册中心获取服务提供者的地址，并通过地址和基于特定的方式调用服务提供者的接口。
• 各个服务与注册中心使用一定机制通信。如果注册中心与服务长时间无法通信，就会注销该实例，这也称为服务下线，当服务重新连接之后，会基于一定的策略在线上线。
• 服务地址相关信息发生变化时，会重新注册到注册中心。这样，服务消费者就无需手工维护提供者的相关配置。

核心功能

通过上面的基本流程，不难发现一个注册中心需要具备哪些核心功能：

• 服务发现

服务发现是指服务在启动后，注册到注册中心，服务方提供自身的元数据，比如 IP 地址、端口、运行状况指标的 Uri、主页地址等信息。

• 服务记录

记录注册中心的服务的信息，例如服务名称、IP 地址、端口等。服务消费方基于查询获取可用的服务实例列表。

• 动态管理服务

注册中心基于特定的机制定时测试已注册的服务，例如：默认的情况下会每隔 30 秒发送一次心跳来进行服务续约。通过服务续约来告知 Server 该 Client 仍然可用。正常情况下，如果 Server 在 90 秒内没有收到 Client 的心跳，Server 会将 Client 实例从注册列表中删除。

二、基础组件对比

1、Zookeeper 组件

1.1 基础描述

ZooKeeper 是非常经典的服务注册中心中间件，在国内环境下，由于受到 Dubbo 框架的影响，大部分情况下认为 Zookeeper 是 RPC 服务框架下注册中心最好选择，随着 Dubbo 框架的不断开发优化，和各种注册中心组件的诞生，即使是 RPC 框架，现在的注册中心也逐步放弃了 ZooKeeper。在常用的开发集群环境中，ZooKeeper 依然起到十分重要的作用，Java 体系中，大部分的集群环境都是依赖 ZooKeeper 管理服务的各个节点。

1.2 组件特点

从 Zookeeper 的数据结构特点看，并不是基于服务注册而设计的，ZooKeeper 提供的命名空间与文件系统的名称空间非常相似，在数据结构上高度抽象为 K - V 格式，十分通用，说到这里不得不提一下 Redis，也可以作为注册中心使用，只是用的不多。

ZooKeeper 组件支持节点短暂存在，只要创建 znode 的会话处于活动状态，这些 znode 就会存在，会话结束时，将删除 znode。Dubbo 框架正是基于这个特点，服务启动往 Zookeeper 注册的就是临时节点，需要定时发心跳到 Zookeeper 来续约节点，并允许服务下线时，将 Zookeeper 上相应的节点删除，同时 Zookeeper 使用 ZAB 协议虽然保证了数据的强一致性。

2、Eureka 组件

2.1 基础描述

SpringCloud 框架生态中最原生的深度结合组件，Eureka 是 Netflix 开发的服务发现框架，基于 REST 的服务，主要用于服务注册，管理，负载均衡和服务故障转移。但是官方声明在 Eureka2.0 版本停止维护，不建议使用。

2.2 组件特点

Eureka 包含两个组件：EurekaServer 和 EurekaClient。

EurekaServer 提供服务注册服务，各个节点启动后，会在 EurekaServer 中进行注册，这样 EurekaServer 中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。Eureka 允许在注册服务的时候，自定义实现检查自身状态的是否健康的方法，这在服务实例能够保持心跳上报的场景下，是一种比较好的体验。

EurekaClient 是一个 java 客户端，用于简化与 EurekaServer 的交互，客户端同时也就是一个内置的、使用轮询 (round-robin) 负载算法的负载均衡器。

3、Consul 组件

3.1 基础描述

Consul 是用于服务发现和配置的工具。Consul 是分布式的，高度可用的，并且具有极高的可伸缩性，而且开发使用都很简便。它提供了一个功能齐全的控制面板，主要特点是：服务发现、健康检查、键值存储、安全服务通信、多数据中心、ServiceMesh。Consul 在设计上把很多分布式服务治理上要用到的功能都包含在内了。

3.2 组件特点

Consul 提供多个数据中心的支持，基于 Fabio 做负载均衡，每个数据中心内，都有客户端和服务端的混合构成。预计有三到五台服务端。可以在失败和性能的可用性之间取得良好的平衡。数据中心中的所有节点都参与八卦协议。这意味着有一个八卦池，其中包含给定数据中心的所有节点。这有几个目的：首先，不需要为客户端配置服务器的地址; 发现是自动完成的。其次，检测节点故障的工作不是放在服务器上，而是分布式的。这使得故障检测比天真的心跳方案更具可扩展性。第三，它被用作消息传递层，用于在诸如领导者选举等重要事件发生时进行通知。

4、Nacos 组件

4.1 基础描述

Nacos 致力于发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您实现动态服务发现、服务配置管理、服务及流量管理。Nacos 更敏捷和容易地构建、交付和管理微服务平台。Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。Nacos 支持作为 RPC 注册中心，例如：支持 Dubbo 框架；也具备微服务注册中心的能力，例如：SpringCloud 框架。

4.2 组件特点

Nacos 在经过多年生产经验后提炼出的数据模型，则是一种服务 - 集群 - 实例的三层模型。如上文所说，这样基本可以满足服务在所有场景下的数据存储和管理, 数据模型虽然相对复杂，但是并不强制使用数据结构的风格，大多数应用场景下，和 Eureka 数据模型是类似的。

Nacos 提供数据逻辑隔离模型，用户账号可以新建多个命名空间，每个命名空间对应一个客户端实例，这个命名空间对应的注册中心物理集群是可以根据规则进行路由的，这样可以让注册中心内部的升级和迁移对用户是无感知的。

三、组件选择

如下注册中心对比图。

综合上述几种注册中心对比，再从现在 SpringCloud 框架流行趋势看，个人推荐后续微服务架构体系选择 Nacos 组件，大致原因如下，社区活跃，经过大规模业务验证，不但可以作为微服务注册中心，也支持作 RPC 框架 Dubbo 的注册中心，且有完善的中文文档，总结下来就一句话：通用中间件，省时；文档详细，省心。

四、源代码地址

GitHub·地址
https://github.com/cicadasmile/husky-spring-cloud
GitEE·地址
https://gitee.com/cicadasmile/husky-spring-cloud

推荐文章：微服务基础系列