服务注册发现与注册中心对比(NACOS 和 ZK)

最新推荐文章于 2024-08-04 13:12:08 发布

春天的早晨

最新推荐文章于 2024-08-04 13:12:08 发布

阅读量4.2k

点赞数 1

分类专栏：面试

原文链接：https://www.cnblogs.com/aixing/p/13327127.html#4zookeeper_101

版权

面试专栏收录该内容

57 篇文章 4 订阅

订阅专栏

文章目录

注册中心简介
- 流程和原理
- - 基础流程
  - 核心功能
注册中心特性对比

注册中心简介

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

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

流程和原理

基础流程

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

核心功能

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

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

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

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

注册中心特性对比

在这里插入图片描述
Nacos 支持 AP（高可用）和 CP（强一致性）模式的切换

zookeeper

zookeeper保证cp。
作为一个分布式协同服务，ZooKeeper非常好，但是对于Service发现服务来说就不合适了；因为对于Service发现服务来说就算是返回了包含不实的信息的结果也比什么都不返回要好；再者，对于Service发现服务而言，宁可返回某服务5分钟之前在哪几个服务器上可用的信息，也不能因为暂时的网络故障而找不到可用的服务器，而不返回任何结果。所以说，用ZooKeeper来做Service发现服务是肯定错误的。

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

基础描述

在这里插入图片描述

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

组件特点

在这里插入图片描述

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

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

Nacos组件

基础描述

在这里插入图片描述

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

组件特点

在这里插入图片描述

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

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

zk和nacos差异

存储和数据更新
Nacos：依赖Mysql数据库做数据存储，当有数据更新的时候，直接更新数据库的数据，然后将数据更新的信息异步广播给Nacos集群中所有服务节点数据变更，在由Nacos服务节点更新本地缓存，然后将通知客户端节点数据变化。

Zookeeper:利用zk的树型结构做数据存储，当有数据更新的时候使用过半机制保证各个节点的数据一致性；然后通过zk的事件机制通知客户端。
服务注册和消费信息直接存储在zk树形节点上，集群下同样采用过半机制保证服务节点间一致性

Nacos支持持久化和非持久化存储即有点 AP和CP 分布式一致性的概念，
持久化使用Raft协议选举master节点，同样采用过半机制将数据存储在leader节点上
非持久直接存储在nacos服务节点的内存中，并且服务节点间采用去中心化的思想，服务节点采用hash分片存储注册信息

参考：
https://www.cnblogs.com/aixing/p/13327127.html#4zookeeper_101 （服务注册发现与注册中心对比-Eureka,Consul,Zookeeper,Nacos对比）
https://blog.csdn.net/weixin_42496542/article/details/109241719 （Nacos和Zookeeper对比）