乐趣区

微服务技术栈常见注册中心组件对比分析

本文源码: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

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

序号 文章标题
01 微服务基础:Eureka 组件,管理服务注册发现
02 微服务基础:Ribbon 和 Feign 组件,实现请求负载均衡
03 微服务基础:Hystrix 组件,实现服务熔断
04 微服务基础:Turbine 组件,实现微服务集群监控
05 微服务基础:Zuul 组件,实现路由网关控制
06 微服务基础:Config 组件,实现配置统一管理
07 微服务基础:Zipkin 组件,实现请求链路追踪
08 微服务基础:与 Dubbo 框架、Boot 框架对比分析
09 微服务基础:Nacos 组件,服务和配置管理
10 微服务基础:Sentinel 组件,服务限流和降级
11 微服务应用:分库分表模式下,数据库扩容方案
12 微服务应用:Shard-Jdbc 分库分表,扩容方案实现
退出移动版