nacos注册中心配置参数(nacos配置中心源码)
微服务初体验(二):使用Nacos作为配置中心并集成Dubbo
首先启动Nacos,按照上篇文章的步骤,启动Nacos服务和项目,访问Nacos的web页面。确保项目中的服务都注册到注册中心当中了。在application.yml同级目录下添加bootstrap.yml,在Spring boot项目中bootstrap.yml会比application.yml优先初始化,所以我们需要在bootstrap.yml中引入Nacos官方指定的配置文件即可(上篇文章中已经把Nacos作为配置中心的配置写入了application.yml,现在只需要把它从applicaiton.yml中剪切出来即可, 其中的spring:application:name会作为Nacos中新增配置时的Data ID,需要留意 ),再新增属性gorup进行分组测试,如下图
接着打开Nacos的服务的web页面,打开配置管理-配置列表,点击右侧新增按钮,进行新增。
Data ID: bootstrap.yml配置文件中spring:application:name对应的名称 ;
Group:指定分组(便于不同环境下的项目配置管理,因为笔者这里属于测试,所以填写的是和上文中的配置文件中group对应的test一致);
描述:针对于该配置的描述;
配置格式:配置文件的格式,要和Data ID中的后缀格式一致(这里笔者用的是yml,那么下面就选择yaml,注意该位置也可以选择properties,但是必须和上面bootstrap.yml文件中的file-extension的值相匹配);
配置内容:具体的配置内容(这里笔者将项目中的application.yml中的配置全部拷贝至其中);
测试启动consumer服务,在application.yml中为空的时候,项目启动端口还是如Nacos配置中的9011,说明项目依赖Nacos的配置中心成功,其他服务如法炮制即可:
新增一个测试Controller,然后加上@RefreshScope注解,表明该Controller中的配置数据为自动刷新 。
编辑Nacos中的配置文件consumer新增相关参数type: test,访问Controller,返回test。效果如下图:
将Nacos中consumer.yml文件的type: test修改为type: prod,在不重启项目的情况下重新访问对应的controller,效果如下图:
因为Dubbo是属于各个服务之间都要公用的依赖,所以将其引入cloud-common当中,详细的版本可以去 mvnrepository 搜索合适自己项目的
引入依赖后需要编写消费者服务中的配置文件,将Dubbo服务注册至Nacos,新增如下内容,其中subscribed-services指的是生产者服务,prot:-1指的是端口随机,registry:address:指的是Dubbo对应的注册中心那这里就应该设置为Nacos
接下来新增接口服务,项目类型为Maven项目,在项目中新增一个接口。并在cloud-provider(生产者)和cloud-consumer(消费者)pom.xml文件中都引入该模块
在生产者实际服务中实现该接口对应的方法
在服务消费者的Controller中引入该Service,并在该Service上加入@Reference注解,注意在引入jar包的时候选择带有Dubbo的,不要使用Jdk原生的
编写消费者服务中测试Dubbo调用的接口,进行测试,测试结果如下图:
【保姆级】Spring Boot如何使用Nacos配置参数
超级详细的保姆级配置教程多图预警 ( ′ ▽ ` )?
生成如下目录结构:
打开命令行,进入到你电脑的Nacos的bin目录下,我这里是: /Users/aqin1012/Java/nacos/bin
调用 sh startup.sh -m standalone 启动单个Nacos
新建配置文件:
填写配置参数:
使用Postman进行简单的本地测试(当然用别的工具也都行~~有比postman好用的工具欢迎评论区戳俺??~~)
(1) 直接发送请求( localhost:8085/aqin/testNacosConfig/ )
(2) 修改Nacos的配置参数并发布
(3) 不重启服务,再次发送请求
搞定,撒花??????~~
什么是Nacos?Nacos注册配置中心介绍
英文全称Dynamic Naming and Configuration Service,Na为naming/nameServer即注册中心,co为configuration即注册中心,service是指该注册/配置中心都是以服务为核心。服务在nacos是一等公民
Nacos注册中心分为server与client,server采用Java编写,为client提供注册发现服务与配置服务。而client可以用多语言实现,client与微服务嵌套在一起,nacos提供sdk和openApi,如果没有sdk也可以根据openApi手动写服务注册与发现和配置拉取的逻辑
Nacos服务领域模型主要分为命名空间、集群、服务。在下图的分级存储模型可以看到,在服务级别,保存了健康检查开关、元数据、路由机制、保护阈值等设置,而集群保存了健康检查模式、元数据、同步机制等数据,实例保存了该实例的ip、端口、权重、健康检查状态、下线状态、元数据、响应时间。这些数据的作用会在第三章讲到
服务注册方法:以Java nacos client v1.0.1 为例子,服务注册的策略的是每5秒向nacos server发送一次心跳,心跳带上了服务名,服务ip,服务端口等信息。同时 nacos server也会向client 主动发起健康检查,支持tcp/http检查。如果15秒内无心跳且健康检查失败则认为实例不健康,如果30秒内健康检查失败则剔除实例。
不同的命名空间逻辑上是隔离的,不特殊设置的情况下,服务不会跨命名空间请求,命名空间主要的作用是区分服务使用的范围,比如开发、测试、生产、灰度可以分别设置四个命名空间来互相隔离。
以springcloud为例,首先用maven导入nacos clinet的依赖:
先导入springcloud的alibaba-nacos-config和alibaba-nacos-discovery两个依赖,这两个依赖是用于nacos clinet与cloud结合的工具,0.2.x对应springboot 2.x.x ,0.1.x对应springboot 1.x.x。这两个组件可以和各种版本的nacos-client结合。把其中的nacos-clinet依赖给排除,引入想要引入的nacosclinet版本,如下:
在bootstrap.properties上添加配置中心的配置
在application-xxx.properties新增如下配置
如果springboot启动类没有 @EnableDiscover 注解则加上
完成如上更改,即可使用Nacos注册/配置服务
演示:
使用Feign、Ribbon均可,在这不做过多介绍
普通application参数在配置中心直接配置皆可,如果需要可以动态刷新的配置,需要在相应类上加上 @RefreshScope 注解,示例如下,当在nacos配置中心更改配置后,方法getId的值也会刷新。
配置中心参数修改/设置
如下两张图:在nacos控制台的 配置管理-配置列表 中顶部选择相应的命名空间,点击列表右上角的加号新增配置,Data ID 为 项目名-{spring.profiles.active}.properties,Group如果在bootstrap.properties中不指定则填默认的DEFAULT_GROUP,描述写该配置的描述,配置内容填写Properties格式或者Yaml格式。
在控制台的 服务管理-服务列表 选择一个服务点击详情,在下方的集群列表可以看到有上线/下线按钮,点击即可以对该实例执行上线/下线操作,下线后的实例不会被请求
可以通过手动配置权重来控制流量,当一个集群内两个实例,权重越高,到达该实例的请求比例越多。
权重的初始值是1
保护阈值的范围是0~1
服务的健康比例=服务的健康实例/总实例个数
当服务健康比例=保护阈值时候,无论实例健不健康都会返回给调用方
当服务健康比例保护阈值的时候,只会返回健康实例给调用方
在 服务管理-服务列表 选择一个服务点击详情可以配置
Nacos-参数配置
Nacos中的参数有很多,如:命名空间、分组名、服务名、保护阀值、服务路由类型、临时实例等,那这些参数都是什么意思?又该如何设置?
在Nacos中通过命名空间(Namespace)+分组(Group)+服务名(Name)可以定位到一个唯一的服务实例。
命名空间(Namespace):Nacos服务中最顶层、也是包含范围最广的概念,用于强制隔离类似环境或者租户等场景。Nacos的服务也需要使用命名空间来进行隔离。 命名空间在Nacos控制台的一级目录里可以找到,如下所示:
在服务列表中也能看到命名空间的身影,如下所示:
命名空间默认为public,在项目开发中,如果不指定命名空间,那么会使用默认值public。 官方推荐使用运行环境来定义命名空间 ,如生产版本可使用public,开发版可定义为private。在项目开发中,可通过配置"spring.cloud.nacos.discovery.namespace"老定义命名空间,如下所示:
命名空间在使用前,必须先在控制台新建命名空间 ,如下所示:
如果在控制台没有新建命名空间,直接在项目中使用的话,是不能将服务成功注册到Nacos中的,如下在项目中配置一个未新建的dev命名空间,如下所示:
然后启动项目,会发现,在Nacos控制台的服务列表中一直刷新不到任何服务实例
分组名(Group):Nacos中次于命名空间的一种隔离概念,区别于命名空间的强制隔离属性,分组属于一个弱隔离概念,主要用于逻辑区分一些服务使用场景或不同应用的同名服务,用常用的情况主要是同一个服务的测试分组和生产分组、或者将应用名作为分组以防止不同应用提供的服务重名。 分组名在Nacos控制台的服务列表中可以看到,如下所示:
分组名默认为DEFAULT_GROUP,在项目中可通过"spring.cloud.nacos.discovery.group"来设置,如下所示:
此项可省略,省略时的默认值为DEFAULT_GROUP。 分组名可以直接在项目中使用 ,无需像命名空间那样,在使用前还要在控制台中新建,设定了分组名之后,刷新服务列表就可以看到新的分组名称了,如下所示:
服务名(Name):该服务实际的名字,一般用于描述该服务提供了某种功能或能力。 通常推荐使用由运行环境作为命名空间、应用名作为分组,服务功能作为服务名的组合来确保该服务的天然唯一性,当然使用者可以忽略命名空间和分组,仅使用服务名作为服务唯一标识,这就需要使用者在定义服务名的额外增加自己的规则来确保在使用中能够唯一定位到该服务而不会发现到错误的服务上。服务名在项目中可以通过"spring.application.name"来指定,如下所示:
健康保护阈值(ProtectThresHold):为了防止因过多实例故障,导致所有流量全部流入剩余实例,继而造成流量压力将剩余实例被压垮形成雪崩效应。应将健康保护阈值定义为一个0到1之间的浮点数。当域名健康实例数占总服务实例数的比例小于该值时,无论实例是否健康,都会将这个实例返回给客户端。这样做虽然损失一部分流量,但是保证了集群中剩余健康实例能正常工作。 简单来说,保护阈值是一个0-1浮点数,保护阈值是允许群里中健康实例占比的最小值,如果实际健康实例的占比小于或等于设置的保护阈值时,就会触发阈值保护,如下所示,设置保护阈值为0.75:
停掉唯一的健康实例,集群的健康实例占比降成了0%,小于设置的保护阈值0.75,此时就会触发阈值保护,如下所示:
服务路由类型的设置如下所示:
它是用来设置服务的路由策略的,默认值为none。如果 设置为label(标签)模式,需要设置响应的标签表达式来匹配实例选择器(Selector),通过实例选择器可以完成自定义负载均衡策略, 比如我们可以自定义实例选择器,实现就近访问的负载均衡策略,这样消费者在调用时,会优先调用离自己比较近的IP节点,从而实现更高效的服务调用。
权重(Weight):实例的级别配置。权重为浮点数,范围为0-10000。权重越大,分配给该实例的流量越大。 它是针对服务实例进行设置的,如下所示:
在Nacos中服务实例有二种类型:持久化实例和临时实例(也叫非持久化实例)。 在控制台中"临时实例"为true时,表示此服务为临时实例,如下所示:
临时实例和持久化实例的区别主要有一下两点:
在项目开发中,可以通过设置
“spring.cloud.nacos.discovery.ephemeral”来指定服务的实例类型,默认为临时实例,也就是默认“spring.cloud.nacos.discovery.ephemeral=true”。如果要设置持久化实例,需要设置“spring.cloud.nacos.discovery.ephemeral”设置为 false,如下图所示:
服务的实例类型一旦确定之后,整个生命周期内不允许被修改,如果试图修改实例类型会提示如下错误:
深入理解Spring Cloud一(3)Nacos配置中心
通过上一节的介绍,我们已经知道了配置加载的扩展点。下面我们已具体的Nacos配置中心来进行说明。
NacosConfigBootstrapConfiguration是@BootstrapConfiguration的配置类,在bootstrap 的SpringApplication创建的过程中,会加载这个类。这个Configuration类包括两个Bean,分别是NacosConfigManager,NacosPropertySourceLocator。
NacosConfigManager的核心作用是创建NacosConfigService,通过NacosConfigService从远程配置中心拉取配置。
NacosPropertySourceLocator是PropertySourceLocator的实现类,上一节已经详细介绍过PropertySourceLocator。
NacosConfigAutoConfiguration是@EnableAutoConfiguration的配置类,当application创建SpringApplication的过程中会被加载,会加载两个重要的Bean,NacosContextRefresher和NacosConfigManager,NacosConfigManager上面已经结束过。
NacosContextRefresher主要作用就是注册Nacos监听器。
监听器又是如何触发的?
Nacos使用长轮询方式获取配置,判断文件是否有变动,如果有变动则触发监听器。
NacosConfigService创建的时候,会创建ClientWorker对象,同时会创建长轮询任务。
我们继续往下看LongPollingRunnable
如果文件MD5不一致,则触发监听器
最终实现回调
判断文件是否变动的核心是长轮询,客户端比较简单,只需要设置较长时间的读超时即可。后面我们会继续探究Nacos服务端的长轮询是如何时间的。