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

2020/06/16 07:55
阅读数 106

本文源码: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分库分表,扩容方案实现
展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部