随着微服务架构的兴起,服务的规模不断增长,对于服务的发现、配置和管理变得越来越复杂。
在这个背景下,Nacos应运而生,以其强大的功能和灵活性成为云原生领域的瑞士军刀之一。
Nacos是一个由阿里巴巴开源的项目,它提供了服务注册与发现、动态配置管理、服务和配置的实时监听等功能,使得开发者可以更加轻松地构建和管理微服务架构。
在Euerka不维护的时候,Nacos站出来挑扛起了大旗。
不得不说是真的好用,完美适配SpringCloud,使得微服务更加完善!
当然免费版可能会有些问题,听说企业收费的是难以想象的好用!有得赚就不会停止维护,就会越来越好,我们一起期待,它给我们带来更好的功能!
文章比较长,还请耐心看完,先收藏慢慢看,后面有源码部门!
话不多说,我们一起来深入了解一下吧!
2018年3月:首次开源
在2018年3月,Nacos首次以开源的形式亮相。作为一个全功能的服务发现和配置管理平台,Nacos的目标是帮助开发者构建和管理微服务架构。
2018年8月:成为Apache孵化项目
由于其强大的功能和快速的社区发展,Nacos于2018年8月进入了Apache软件基金会的孵化阶段,成为Apache的孵化项目。
2019年3月:成为Apache顶级项目
在经过孵化期的发展和审查后,Nacos于2019年3月正式成为Apache顶级项目。这意味着 Nacos 的社区达到了一定的规模和贡献度,得到了广泛认可。
2019年4月:发布Nacos 1.0.0 GA
同时支持 AP 和 CP 一致性,可以大规模地生产环境中使用,新版本不仅针对社区的需求和集群的稳定性相应地增加了一些新特性,而且还发布了服务发现模块的性能测试报告,以及完整的 API 列表和架构设计文档。快速增长期!
2021年03月:发布Nacos 2.0
对于服务注册和发现使用 gRPC 框架
,Nacos 2.0 注册性能相、注销实例性能比较 Nacos 1.x 总体提升至少 2 倍;Nacos 2.0 查询性能相比较 Nacos 1.x 总体提升至少 3 倍,单机多线程甚至提升了 10 倍;这一时期基本没有对手!
Nacos 是 Dynamic Naming and Configuration Service
的首字母简称,一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。
我们看一下Nacos 生态图:
动态配置服务
动态配置服务让您能够以中心化、外部化和动态化的方式管理所有环境的配置。动态配置消除了配置变更时重新部署应用和服务的需要。配置中心化管理让实现无状态服务更简单,也让按需弹性扩展服务更容易。
把Yaml文件放到Nacos上统一管理和切换。
服务发现及管理
动态服务发现对以服务为中心的(例如微服务和云原生)应用架构方式非常关键。Nacos支持DNS-Based和RPC-Based(Dubbo、gRPC)模式的服务发现。Nacos也提供实时健康检查,以防止将请求发往不健康的主机或服务实例。借助Nacos,您可以更容易地为您的服务实现断路器。
2.0以后采用gRPC进行服务的注册!
动态DNS服务
通过支持权重路由,动态DNS服务能让您轻松实现中间层负载均衡、更灵活的路由策略、流量控制以及简单数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以DNS协议为基础的服务发现,以消除耦合到厂商私有服务发现API上的风险。
服务及其元数据管理
Nacos 能让您从微服务平台建设的视角管理数据中心的所有服务及元数据,包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。
灰度发布的配置就是元数据的一些参数!
我们根据对照表来下载哈!
由于我们使用的Springboot版本是3.0之前的,所以要引入SpringCloudAlibaba 2021.0.5版本的,这个版本的Nacos只能安装2.2.0的。所以我们不能安装最新版的Nacos2.2.3
,当然你也可以试一下,看看是不是向下兼容。
对照表地址
经过对照表我们本次下载客户端版本为2.2.0
。
下载慢的可以使用迅雷!本次以Windows为例,Linux可以下载上面的,想看源码的也可以下载下面的源码!
Nacos2.2.0下载
这是绿色软件,不需要安装,尽量放到没有中文目录下,防止不必要的麻烦!
启动这里有个坑:
对于Nacos2.0以上版本默认启动是以集群的方式启动,需要你指定成单机启动,当然你可以使用集群哈,这里就不带大家搭集群了!
对于1.X直接双击启动即可!
找到bin目录,我们在上方输入cmd
回车。
由于公司项目启动着nacos,咱的nacos改了端口为:18848。
输入启动命令:
startup.cmd -m standalone
启动成功,我们可以进行访问了!
http://192.168.50.108:18848/nacos/index.html
用户名和密码都是nacos
启动完美结束!
我们一般要把Nacos的配置信息进行持久化,默认是使用嵌入式数据库Derby
数据库。
可以发现nacos的pom里引入了:
<dependency>
<groupId>org.apache.derbygroupId>
<artifactId>derbyartifactId>
<version>${derby.version}version>
dependency>
这个数据库咱也不熟,为了方便查看和管理,通常会选择一个外部的数据库。
在nacos0.7版本之后增加了支持MySQL数据源能力。
官方比较推荐使用MySQL来进行持久化的!配置文件里已经给我们准备好了配置的东西,解开注释修改成自己的MySQL地址就好了!
先到conf目录下拿到SQL文件,然后再数据库中执行一下就可以了!
这里以Navicat为例哈:
导入conf下的SQL文件:
我们开始修改Nacos的配置文件:application.properties
解开注释,配置自己的数据库用户和密码就行了!
一定要重启一下Nacos!
我们来讲一下Nacos的核心——配置中心功能吧;
这个对标的是Spring Cloud Config
,需要单独引依赖!
配置中心是分布式系统中一种用于集中管理和动态配置应用程序配置信息的服务。
在微服务架构中,配置管理是一个重要的问题,因为不同的服务可能需要不同的配置,并且这些配置可能会随时发生变化。配置中心的目标是使配置更加集中、易管理。
命名空间(Namespace)
命名空间是 Nacos 中的一个重要概念,它用于隔离不同环境或应用的配置信息。通过使用命名空间,可以在同一个 Nacos 集群中管理多个环境(如开发、测试、生产)的配置信息,从而实现配置的多租户管理。
配置集(Data ID)
配置集是 Nacos 中用于存储配置信息的基本单元。每个配置集都有一个唯一的标识符,称为 Data ID。Data ID 通常由配置的业务模块和应用名组成,用于唯一标识一个配置集。(对标我们一个个的微服务)
分组(Group)
分组是配置集的另一个维度,用于将不同用途或维度的配置集归类到同一个组中。通过分组,可以更好地组织和管理配置信息。
动态更新
:配置信息放到yml文件中,防止硬编码在程序里,动态更新配置(无需重启)。
多环境配置
:不同的配置创建版本,并在需要时切换配置版本。这有助于在不同环境(例如开发、测试、生产)之间轻松管理配置。
集中管理
:配置中心允许开发者将应用程序的配置信息集中存储在一个地方,而不是分散存储在各个微服务中。这样可以更方便地管理和维护配置。
可视化管理
:一些配置中心提供了可视化的配置管理界面,方便用户直观地查看和管理配置信息。
历史配置查看
:一些配置中心提供了历史配置查看功能,可以方便用户查看历史版本的配置信息,对于问题追溯和回滚配置是有帮助的。
配置的监听和推送
在使用之前需要了解一下bootstrap.yml(properties )
bootstrap 是 Spring Boot 中一个特殊的配置文件,用于在应用程序启动时配置一些系统级别的属性,通常用于一些在应用程序上下文创建之前就需要加载的配置。
我们把配置文件放到Nacos上,你把Nacos的地址再放在application.yml中,会加载不到,从而拿不到Nacos中的配置文件,项目无法启动。所以需要把项目中的application.yml
命名为:bootstrap.yml
。
让程序先去加载bootstrap.yml,拿到Nacos信息,再从Nacos里拿到配置信息,然后就可以加载了,连接数据库等等!
我们在项目中使用Nacos后,就会在启动项目成功后,在控制台输出:
2023-11-16 14:02:08.490 INFO 24660 ---
[ main] c.a.c.n.registry.NacosServiceRegistry :
nacos registry, DEFAULT_GROUP service-message 192.168.50.108:2002 register finished
代表我们的服务注册到Nacos上了!
我们发现日志打印的类是NacosServiceRegistry
,所以说这个类就是注册核心类!
我们一起看看这个类到底发生了什么!
我们打断点开看一下是谁调用的这个方法:
这是SpringBoot思想约定大于配置,在NacosServiceRegistryAutoConfiguration配置生效后,当Spring容器初始化完成后,会发送 WebServerInitializedEvent 事件!
我们从调用链中发现:AbstractAutoServiceRegistration
通过实现ApplicationListener
来实现程序的监听,从而执行到register方法!
AbstractAutoServiceRegistration UML图
我们继续看这个注册方法,直接找到核心方法:
namingService.registerInstance(serviceId, group, instance);
一直点,直到出现三个实现方法,让自己选择。
至于源码中怎么选择的,我们一起看一下:
三个实现会先执行NamingClientProxyDelegate
来获取具体使用那种方式,类里的方法:
private boolean ephemeral = true;
private NamingClientProxy getExecuteClientProxy(Instance instance) {
return instance.isEphemeral() ? grpcClientProxy : httpClientProxy;
}
此时在Nacos2.0之前默认注册是采用Http来发送的,2.0之后采用了效率更高的gRPC进行发送的!
此时我们来到gRpc的代理类中:
我们进去就可以看到gRpc的调用,具体内部就带大家看了,关于gRpc的事情,大家可以搜一下,是Google开发的!
此时我们已经完成一半了,请求发送成功了,我们开始移步Nacos源码了,需要的自行下载哈!
Nacos源码下载地址
此时需要找到官网的服务注册地址,也就是刚刚我们发送gRpc的地址:
curl -X POST 'http://127.0.0.1:8848/nacos/v1/ns/instance?serviceName=nacos.naming.serviceName&ip=20.18.7.10&port=8080'
找到源码从这里为入口往下走,这里就不带大家跟了,NamingApp起不来,找了很多,没有说的,大家可以试一下,跑个测试就行了。
不能Debug,小编这里只能跟到这里,给大家提供一个思路:
getInstanceOperator().registerInstance(namespaceId, serviceName, instance);
com.alibaba.nacos.naming.core.InstanceOperatorClientImpl#registerInstance
中:
clientOperationService.registerInstance(service, instance, clientId);
来到这个实现类:
com.alibaba.nacos.naming.core.v2.service.impl.EphemeralClientOperationServiceImpl#registerInstance
NotifyCenter.publishEvent(new ClientOperationEvent.ClientRegisterServiceEvent(singleton, clientId));
点击:ClientRegisterServiceEvent
,
来到类:com.alibaba.nacos.naming.core.v2.event.client.ClientOperationEvent.ClientRegisterServiceEvent
查看有哪些引用,找到这个类,他来监听然后继续执行:
com.alibaba.nacos.naming.core.v2.index.ClientServiceIndexesManager#onEvent
这个类里:
handleClientOperation((ClientOperationEvent) event);
addPublisherIndexes(service, clientId);
NotifyCenter.publishEvent(new ServiceEvent.ServiceChangedEvent(service, true));
这里继续发布另一个事件,点击ServiceChangedEvent
来到这个类:
com.alibaba.nacos.naming.core.v2.event.service.ServiceEvent.ServiceChangedEvent
查看引用,来到这个类方法:
com.alibaba.nacos.naming.push.v2.NamingSubscriberServiceV2Impl#onEvent
里面会整上一个延时队列:
delayTaskEngine.addTask(service, new PushDelayTask(service, PushConfig.getInstance().getPushTaskDelay()));
delayTaskEngine是我们后面的方向:PushDelayTaskExecuteEngine
先去构造方法看,发现先调用的父类,就先去看父类:
NacosDelayTaskExecuteEngine
先要看构造方法:
public NacosDelayTaskExecuteEngine(String name, int initCapacity, Logger logger, long processInterval) {
super(logger);
// 初始化待处理任务
tasks = new ConcurrentHashMap<>(initCapacity);
// 一个单线程的处理任务线程池
processingExecutor = ExecutorFactory.newSingleScheduledExecutorService(new NameThreadFactory(name));
// 开启线程池,放里面添加上面说的task
processingExecutor
.scheduleWithFixedDelay(new ProcessRunnable(), processInterval, processInterval, TimeUnit.MILLISECONDS);
}
会执行:com.alibaba.nacos.common.task.engine.NacosDelayTaskExecuteEngine#processTasks
这一段主要是:通过定义一个延时执行的线程池定时去扫描task缓存,执行任务。
可以看看PushDelayTaskExecuteEngine
的UML图:
从新回到PushDelayTaskExecuteEngine
的构造方法:
setDefaultTaskProcessor(new PushDelayTaskProcessor(this));
点击:PushDelayTaskProcessor
来到这个类:com.alibaba.nacos.naming.push.v2.task.PushDelayTaskExecuteEngine.PushDelayTaskProcessor
来到执行的process方法:
NamingExecuteTaskDispatcher.getInstance() .dispatchAndExecuteTask(service, new PushExecuteTask(service, executeEngine, pushDelayTask));
点击:dispatchAndExecuteTask
看到放里面添加任务:
executeEngine.addTask(dispatchTag, task);
来到这个类:
NacosExecuteTaskExecuteEngine
构造方法往里看:
在给TaskExecuteWorker[]添加元素,我们在看这个数组:TaskExecuteWorker
然后继续看构造方法:realWorker = new InnerWorker(this.name);
然后realWorker.start();
启动:
会来到:com.alibaba.nacos.common.task.engine.TaskExecuteWorker.InnerWorker#run
来执行任务:task.run();
现在一脸懵了,一直在解耦,没发打断点,太难了,有大佬懂的NamingApp启动的可以交流一下。
之前看过2.0之前的源码,和这个完全不一样,懵逼了。
不过思想应该没变,注册表本质还是一个Map。
看了之前的笔记是:private final Map
不过现在可能变了,后面专门整一期文章看看源码,有点跑偏了。还是以实战为主,源码我们后面单独看哈!
还有就是延迟单线程思想,你会发现Nacos的注册是单线程的,都会放在阻塞队列里一个个的去执行。
大家不需要担心这个效率会不会慢,一般用这个的就算有几百个服务,一起注册也是很快的,这种发布大家还是可以忍受的。成熟的程序后,不会一次注册很多!
这里就先不写了,上面一个注册,花了好几天时间。
我们先暂时跳过:
后面搞懂了,把注册和发现的源码单独写一篇。
有兴趣的可以跟一下:
curl -X GET 'http://127.0.0.1:8848/nacos/v1/ns/instance/list?serviceName=nacos.naming.serviceName'
这个无疑也是从注册表Map中那信息!
自己可以建一个聚合项目,然后体会一下,这里不就带大家建了!
版本的对照,上面已经说了,大家可以去官网查看!
父模块:
<spring.boot.version>2.6.13spring.boot.version>
<spring.cloud.dependencies.version>2021.0.5spring.cloud.dependencies.version>
<spring.cloud.alibaba.version>2021.0.5.0spring.cloud.alibaba.version>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-dependenciesartifactId>
<version>${spring.cloud.dependencies.version}version>
<type>pomtype>
<scope>importscope>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-dependenciesartifactId>
<version>${spring.boot.version}version>
<type>pomtype>
<scope>importscope>
dependency>
<dependency>
<groupId>com.alibaba.cloudgroupId>
<artifactId>spring-cloud-alibaba-dependenciesartifactId>
<version>${spring.cloud.alibaba.version}version>
<type>pomtype>
<scope>importscope>
dependency>
子模块:
要有bootstrap的依赖,默认2020以上版本把bootstrap禁用了,需要自己单独引,不然会报错!
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-webartifactId>
dependency>
<dependency>
<groupId>com.alibaba.cloudgroupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discoveryartifactId>
dependency>
<dependency>
<groupId>com.alibaba.cloudgroupId>
<artifactId>spring-cloud-starter-alibaba-nacos-configartifactId>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-bootstrapartifactId>
dependency>
结构如下:
三份除了端口和服务名不一样,其余都是相同的!
server:
port: 2000
spring:
application:
# 应用名称
name: service-order
cloud:
nacos:
discovery:
# 服务注册地址
server-addr: localhost:18848
config:
# 配置中心地址
server-addr: ${spring.cloud.nacos.discovery.server-addr}
username: nacos
password: nacos
启动服务,我们看看能否注册到Nacos上!
我们发现是没有任何问题的,我们后面测试把配置信息放在Nacos上!
在之前我们可以新建命名空间,来进行开发、测试、生产环境的配置隔离!
我们创建了三个:
上面概念时已经讲过了,有三种维度,实际常用的一般就是前两种,分组的话取默认的即可!
我们来创建配置:
这里有个Data Id命名的规范,
一般是服务名+环境名+后缀
例子:service-stock-dev.yml
把程序里加上这些信息:
server:
port: 2001
spring:
profiles:
active: dev
application:
# 应用名称
name: service-stock
cloud:
nacos:
discovery:
# 服务注册地址
server-addr: localhost:18848
config:
# 命名空间
namespace: 03a31fa6-f665-40f2-9886-20b4c60498c5
# 配置中心地址
server-addr: ${spring.cloud.nacos.discovery.server-addr}
# 指定yml格式的配置 默认properties
file-extension: yml
# 配置文件prefix
prefix: ${spring.application.name}
# 共享配置
shared-configs:
- dataId: ${spring.application.name}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}
group: ${spring.cloud.nacos.config.group}
group: DEFAULT_GROUP
username: nacos
password: nacos
读取配置类:
// 要交给spring容器,不然获取不到值
@Component
// 配置读取yml文件中前缀
@ConfigurationProperties(prefix = "product")
// 要有get方法,不然无法获取值
@Data
public class Product {
private String name;
private BigDecimal price;
private String num;
}
下面我们写一个测试类,来获取Nacos上配置文件的信息:
配置文件里的信息:
经过几天的总结、梳理,断断续续的,Nacos还是有点东西的,源码设计还是耐人寻味!
我们来总结一下吧!
本篇主要从Nacos的前世今生讲起,介绍了核心点。下载安装配置了Nacos,进行持久化的修改。
介绍Nacos的两个核心功能:服务的注册和发现、配置中心。简单的从服务的注册源码进行查看,还是要自己debug看一下核心流程。基本全是发布订阅来解耦,单线程阻塞队列来防止并发问题。
最后实战了一下,完成的服务的注册和发现,并把application.yml的信息放到Nacos上统一管理。
Nacos的市场占用率还是挺高的,基本除了老项目还再用Eureka,除了自研都是这个了!
看到这里了,还请动一下您的发财小手,关注一下公众号哈!!谢谢您的关注!!文章首发看!!!