微服务技术栈：常见注册中心组件，对比分析
本文源码：GitHub·点这里 || GitEE·点这里
一、注册中心简介
1、基础概念
在分布式架构的系统中注册中心这个概念就已经被提出了，最经典的就是Zookeeper中间件。
07-1.png
微服务架构中，注册中心是最核心的基础服务之一，注册中心可以看做是微服务架构中的通信中心，当一个服务去请求另一个服务时，通过注册中心可以获取该服务的状态，地址等核心信息。
服务注册主要关系到三大角色：服务提供者、服务消费者、注册中心。
2、流程和原理
基础流程
- 服务启动时，将自身的网络地址等信息注册到注册中心，注册中心记录服务注册数据。
- 服务消费者从注册中心获取服务提供者的地址，并通过地址和基于特定的方式调用服务提供者的接口。
- 各个服务与注册中心使用一定机制通信。如果注册中心与服务长时间无法通信，就会注销该实例，这也称为服务下线，当服务重新连接之后，会基于一定的策略在线上线。
- 服务地址相关信息发生变化时，会重新注册到注册中心。这样，服务消费者就无需手工维护提供者的相关配置。
核心功能
通过上面的基本流程，不难发现一个注册中心需要具备哪些核心功能：
- 服务发现
服务发现是指服务在启动后，注册到注册中心，服务方提供自身的元数据，比如IP地址、端口、运行状况指标的Uri 、主页地址等信息。
- 服务记录
记录注册中心的服务的信息，例如服务名称、IP地址、端口等。服务消费方基于查询获取可用的服务实例列表。
- 动态管理服务
注册中心基于特定的机制定时测试已注册的服务，例如：默认的情况下会每隔30秒发送一次心跳来进行服务续约。通过服务续约来告知Server该Client仍然可用。正常情况下，如果Server在90 秒内没有收到Client 的心跳，Server会将Client 实例从注册列表中删除。
二、基础组件对比
1、Zookeeper组件
1.1基础描述
07-2.jpg
ZooKeeper是非常经典的服务注册中心中间件，在国内环境下，由于受到Dubbo框架的影响，大部分情况下认为Zookeeper是RPC服务框架下注册中心最好选择，随着Dubbo框架的不断开发优化，和各种注册中心组件的诞生，即使是RPC框架，现在的注册中心也逐步放弃了ZooKeeper。在常用的开发集群环境中，ZooKeeper依然起到十分重要的作用，Java体系中，大部分的集群环境都是依赖ZooKeeper管理服务的各个节点。
1.2组件特点
07-3.jpg
从Zookeeper的数据结构特点看，并不是基于服务注册而设计的，ZooKeeper提供的命名空间与文件系统的名称空间非常相似，在数据结构上高度抽象为K-V格式，十分通用，说到这里不得不提一下Redis，也可以作为注册中心使用，只是用的不多。
ZooKeeper组件支持节点短暂存在，只要创建znode的会话处于活动状态，这些znode就会存在，会话结束时，将删除znode。Dubbo框架正是基于这个特点，服务启动往Zookeeper注册的就是临时节点，需要定时发心跳到Zookeeper来续约节点，并允许服务下线时，将Zookeeper上相应的节点删除，同时Zookeeper使用ZAB协议虽然保证了数据的强一致性。
2、Eureka组件
2.1基础描述
07-4.png
SpringCloud框架生态中最原生的深度结合组件，Eureka是Netflix开发的服务发现框架，基于REST的服务，主要用于服务注册，管理，负载均衡和服务故障转移。但是官方声明在Eureka2.0版本停止维护，不建议使用。
2.2组件特点
Eureka包含两个组件：EurekaServer和EurekaClient。
EurekaServer提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。Eureka允许在注册服务的时候，自定义实现检查自身状态的是否健康的方法，这在服务实例能够保持心跳上报的场景下，是一种比较好的体验。
EurekaClient是一个java客户端，用于简化与EurekaServer的交互，客户端同时也就是一个内置的、使用轮询(round-robin)负载算法的负载均衡器。
3、Consul组件
3.1基础描述
07-5.png
Consul是用于服务发现和配置的工具。Consul是分布式的，高度可用的，并且具有极高的可伸缩性，而且开发使用都很简便。它提供了一个功能齐全的控制面板，主要特点是：服务发现、健康检查、键值存储、安全服务通信、多数据中心、ServiceMesh。Consul在设计上把很多分布式服务治理上要用到的功能都包含在内了。
3.2组件特点
Consul提供多个数据中心的支持，基于Fabio做负载均衡，每个数据中心内，都有客户端和服务端的混合构成。预计有三到五台服务端。可以在失败和性能的可用性之间取得良好的平衡。数据中心中的所有节点都参与八卦协议。这意味着有一个八卦池，其中包含给定数据中心的所有节点。这有几个目的：首先，不需要为客户端配置服务器的地址;发现是自动完成的。其次，检测节点故障的工作不是放在服务器上，而是分布式的。这使得故障检测比天真的心跳方案更具可扩展性。第三，它被用作消息传递层，用于在诸如领导者选举等重要事件发生时进行通知。
4、Nacos组件
4.1基础描述
07-6.jpg
Nacos致力于发现、配置和管理微服务。Nacos提供了一组简单易用的特性集，帮助您实现动态服务发现、服务配置管理、服务及流量管理。Nacos更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构(例如微服务范式、云原生范式)的服务基础设施。Nacos支持作为RPC注册中心，例如：支持Dubbo框架；也具备微服务注册中心的能力，例如：SpringCloud框架。
4.2组件特点
07-7.jpg
Nacos在经过多年生产经验后提炼出的数据模型，则是一种服务-集群-实例的三层模型。如上文所说，这样基本可以满足服务在所有场景下的数据存储和管理,数据模型虽然相对复杂，但是并不强制使用数据结构的风格，大多数应用场景下，和Eureka数据模型是类似的。
Nacos提供数据逻辑隔离模型，用户账号可以新建多个命名空间，每个命名空间对应一个客户端实例，这个命名空间对应的注册中心物理集群是可以根据规则进行路由的，这样可以让注册中心内部的升级和迁移对用户是无感知的。
三、组件选择
如下注册中心对比图。
07-8.jpg
综合上述几种注册中心对比，再从现在SpringCloud框架流行趋势看，个人推荐后续微服务架构体系选择Nacos组件，大致原因如下，社区活跃，经过大规模业务验证，不但可以作为微服务注册中心，也支持作RPC框架Dubbo的注册中心，且有完善的中文文档，总结下来就一句话：通用中间件，省时；文档详细，省心。
四、源代码地址
GitHub·地址
https://github.com/cicadasmile/husky-spring-cloud
GitEE·地址
https://gitee.com/cicadasmile/husky-spring-cloud
推荐文章：微服务基础系列
