分布式架构的注册中心，该怎么选？
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了分布式架构的注册中心，该怎么选？相关的知识，希望对你有一定的参考价值。
参考技术A 互联网架构下，大部分系统已经转型分布式。其中服务注册发现中心，分布式服务中非常重要的组成部分。按需选择合适的注册中心，也变的尤为重要。Eureka是SpringCloud全家桶中非常重要的一个组件，主要是实现服务的注册和发现。Eureka做到了CAP理论中的AP，强调服务的高可用性。实现中分Eureka Server和Eureka Client两部分。
Eureka客户端会向Eureka注册中心注册为服务，并通过心跳来更新它的服务租约。同时也可以从服务端查询当前注册的服务信息并把他们缓存到本地并周期性的刷新服务状态。若服务集群出现分区故障时，Eureka会转入自动保护模式，允许分区故障的节点继续提供服务；若分区故障恢复，集群中其他分区会把他们的状态再次同步回来。
SpringCloud对其做了非常好的集成封装，是官方推荐的注册中心。
Zookeeper是大数据Hadoop中的一个分布式调度组件，强调数据一致性和扩展性，可用于服务的注册和发现。她是dubbo中默认的服务注册中心，也是目前使用最广泛的分布式服务发现组件。注重CAP理论中的CP。
Consul是一个高可用的分布式服务注册中心，由HashiCorp公司推出，Golang实现的开源共享的服务工具。Consul在分布式服务注册与发现方面有自己的特色，解决方案更加“一站式”，不再需要依赖其他工具。
1、通过HTTP接口和DNS协议调用API存储键值对，使服务注册和服务发现更容易；
2、支持 健康 检查，可以快速的告警在集群中的操作
3、支持key/value存储动态配置
4、支持任意数量的区域
ETCD是一个高可用的分布式键值数据库，可用于共享配置、服务的注册和发现。ETCD采用Raft一致性算法，基于Go语言实现。ETCD作为后起之秀，又非常大的优势。
1、基于HTTP+JSON的API，使用简单；
2、可选SSL客户认证机制，更安全；
3、单个实例支持每秒千次写操作，快速。
4、采用Raft一致性算法保证分布式。
微服务技术栈：常见注册中心组件，对比分析
本文源码：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
推荐文章：微服务基础系列
以上是关于分布式架构的注册中心，该怎么选？的主要内容，如果未能解决你的问题，请参考以下文章
Spring Cloud中五花八门的分布式组件我到底该怎么学
Spring Cloud中五花八门的分布式组件我到底该怎么学