赞
踩
Nacos是 Dynamic Naming and Configuration Service的首字母简称,一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos是阿里开放的一款中间件,它主要提供三种功能:持久化节点注册,非持久化节点注册和配置管理。
Nacos(Namespace Aware Clustered Object Store)是阿里巴巴开源的一个动态服务发现、配置管理和服务管理平台。它主要包含两个核心模块:配置管理和服务发现。
Nacos 提供了灵活且强大的服务注册与发现机制,主要包括以下几个方面:
Nacos 作为配置中心功能基于 Raft 算法来实现,Raft 算法分布式系统开发首选共识算法,它通过“一切以领导者为准”方式,实现一系列值共识和各节点日志一致。Raft 选举规程 涉及三种角色和任期(Term),
Follower:默默地收和处理来自 Leader 消息,当等待 Leader 心跳信息超时时候,就主动站出来,推荐自己当 Candidate。
Candidate:向其他节点发送投票请求,通知其他节点来投票,如果赢得了大多数(N/2+1)选票,就晋升Leader。
Leader:负责处理客户端请求,进行日志复制等操作,每一轮选举目标就选出一个领导者;领导者会不断地发送心跳信息,通知其他节点“我领导者,我还活着,你们不要发起新选举,不用找个新领导者来替代我。”
Term:这跟民主社会选举很像,每一届新履职期称之为一届任期
在实际应用中,Nacos更常用作配置中心而不是注册中心。尽管Nacos提供了注册中心和配置中心的功能,但根据实践经验和推荐做法,更多的团队会选择将Nacos用作配置中心,而将服务发现和注册功能交给其他工具如Consul、Eureka等来实现。
以下是一些原因:
首先,Nacos采用的是长轮询的方式。也就是说,由Nacos Client向Nacos Server端去发起配
置更新查询的请求。所谓长轮询,就是客户端发起一次轮询请求到服务器端,当服务器端的配置没有
任何变更的时候,这个连接会一直打开,直到服务端有配置变更或者连接超时之后才返回。
Nacos Client端需要去获取服务端变更的配置内容,但前提是需要先进行比较。也就是说将客户端本地缓存的
配置信息和服务器端获取的配置信息进行比较。一旦发现本地缓存的配置内容和服务端的配置内容有差异,那么,就表示服务器端的配置有更新。于是,需要把更新的配置拉到本地,在这个过程中,有可能因为客户端的配置比较多,而导致对比的时间较长,使得配置的同步效率非常低。
于是Nacos针对这样一个场景,做了两个方面的优化:
1、减少网络通信的数据量。客户端把需要进行对比的配置按配置项进行分片,每个分片的大小是3000项,也就
是说每一次最多拿3000个配置项去Nacos Server端进行对比。
2.分阶段进行对比和更新。第一阶段,客户端把3000个配置项的Key以及对应Value的MD5值拼接成一个字符
串,然后发送到Nacos Server端进行判断,服务端会逐个比较这些配置中MD5不同的Key,把存在更新的Key返回给客户端。第二阶段,客户端拿到这些数据有变更的Key,循环逐个调用服务端,从而获取这些Key对应的Value值。那么,这两个优化的核心目的是去减少网络通信中数据包的大小。把一次大数据包的通信拆分成了多个小数据包的通信。虽然会增加网络通信的次数,但是,提高了整体的数据传输的性能。
最后,再加上长轮询的方式,既减少了Pull的轮询次数,又利用了长轮询的优势,很好地实现了配置动态更新的
同步功能。
Nacos是一个用于动态服务发现、配置管理和服务治理的开源平台。在Nacos中,临时节点和永久节点是指在服务注册和发现中使用的两种不同类型的节点。
Distro协议和Raft协议
@Nacos Distro协议是阿里巴巴开源的Nacos项目中使用的一种数据复制协议。Nacos是一个用于动态服务发现、配置管理和服务治理的平台,Distro协议则用于在Nacos的集群环境中实现数据的可靠复制和同步。
Nacos Distro协议的主要目标是保证集群中的各个节点之间的数据一致性和可靠性。它的工作方式如下:
Java 中有很多服务和框架可以使用 Nacos 作为服务注册与发现、配置管理的解决方案。以下是一些常见的 Java 服务和框架:
Nacos是一个服务发现和配置管理平台,它支持AP(可用性和分区容错性)和CP(一致性和分区容错性)两种模式。因此,Nacos并不是单纯属于AP或CP的,而是可以根据用户的需求和场景进行选择和配置。
在AP模式下,Nacos优先考虑系统的可用性,即使在网络分区(即系统的一部分无法与另一部分通信)的情况下,也能保证服务的可用性。这种模式下,Nacos采用了Raft协议来确保数据的一致性。Raft协议是一种为分布式系统设计的共识算法,通过选举和日志复制的方式来保证数据的一致性。
而在CP模式下,Nacos则更侧重于数据的一致性,即确保所有的节点都能看到相同的数据版本。在这种模式下,Nacos采用了Distro协议,这是一种阿里自研的协议,用于保证数据的性能和一致性。
因此,选择AP还是CP模式,主要取决于用户的业务需求和系统特点。如果对可用性要求较高,比如在云计算、微服务架构等场景中,可以选择AP模式;如果对数据一致性有严格要求,比如在金融、电商等需要确保数据准确性的场景中,可以选择CP模式。
Nacos 能够同时实现 AP 和 CP 的特性主要是通过在设计上的灵活性和可配置性来实现的,而非在单个实例上同时保证 AP 和 CP。
Nacos 实现配置变化客户端可以感知到的机制是通过长轮询(Long Polling)或者基于推送的方式。
Nacos 2.X 在 1.X 的架构基础上,通信层通过 gRPC 和 Rsocket 实现了长连
接 RPC 调用和推送能力。主要是为了改善Nacos在大规模集群环境下的性能和稳定性
Nacos 2.x 新增了 RPC 的通信方式,主要是为了解决以下几个问题和需求:
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。