Nacos学习
1.简介
bootstrap.yml的读取优先级最高)
bootstrap.yml(本地) > application.yml(本地) > application-dev.yml(本地) > order-service.yaml(nacos) >
order-service-dev.yaml(nacos)
应用程序在启动和运行的时候往往需要读取一些配置信息,配置基本上伴随着应用程序的整个生命周期,比如:数据库连接参数、启动参数等。
特点:配置是独立于程序的只读变量;
配置伴随应用的整个生命周期;
配置可以有多种加载方式:
常见的有程序内部hard code ,配置文件,环境变量,启动参数,基于数据库等;
配置需要治理
在微服务架构中,当系统从一个单体应用,被拆分成分布式系统上一个个服务节点后,配置文件也必须跟着迁移(分割) , 这样配置就分散了;
配置中心将配置从各应用中剥离出来,对配置进行统一管理)应用自身不需要自己去管理配置
Nacos是阿里的一个开源产品,它是针对微服务架构中的服务发现、配置管理、服务治理的综合型解决方案。
1)服务发现与服务健康检查
Nacos使服务更容易注册,并通过DNS或HTTP接口发现其他服务, Nacos还提供服务的实时健康检查,以防止向不健康的主机或服务实例发送请求。
2)动态配置管理
动态配置服务允许您在所有环境中以集中和动态的方式管理所有服务的配置。Nacos消除了在更新配置时重新部署应用程序,这使配置的更改更加高效和灵活。
3)动态DNS服务
Nacos提供基于DNS协议的服务发现能力,旨在支持异构语言的服务发现,支持将注册在Nacos上的服务以域名的方式暴露端点,让三方应用方便的查阅及发现。
4)服务和元数据管理
Nacos能让您从微服务平台建设的视角管理数据中心的所有服务及元数据,包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略。
2.Nacos启动
docker run -p 8848:8848 -e MODE=standalone --name nacos -d nacos/nacos-server
Windows版本 编辑startup.cmd 修改mode为standalone
Linux版本 bin/startup.sh ‐m standalone或者修改配置文件mode为standalone
1)引入依赖
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
<version>2021.1</version>
</dependency>
2)修改配置文件
spring:
cloud:
nacos:
discovery:
server-addr: 192.168.62.62:8848
config:
server-addr: 192.168.62.62:8848
namespace: public
file-extension: yaml
shared-configs:
- application-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}
username: nacos
password: nacos
第一种,直连模式:当nacos部署变更后,client要修改配置
第二种,vip模式(负载均衡模式):VIP组件依然是ip:port的模式,不容易记忆和理解
第三种,域名模式:增加IO时延
spring.datasource.platform=mysql
db.num=1
db.url.0=jdbc:mysql://192.168.8.14:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconn
ect=true&useUnicode=true&useSSL=false&serverTimezone=UTC
db.user.0=root
db.password.0=root
192.168.92.133:8849
192.168.92.133:8850
192.168.92.133:8851
如果出现内存不足:修改启动脚本(bin\startup.sh)的jvm参数
3.Nacos相关介绍
用于进行租户粒度的配置隔离,命名空间不仅适用于nacos的配置管理,同样适用于服务发现。Namespace 的常用场景之一是不同环境的配置的区分隔离,例如开发测试环境和生产环境的资源(如配置、服务)隔离等。
对配置和服务进行分组,也是起到隔离作用,当您在 Nacos 上创建一个配置时,如果未填写配置分组的名称,则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景:可用于区分不同的项目或应用,例如:学生管理系统的配置集可以定义一个group为:STUDENT_GROUP。
应用注册时候的服务名称
进行雪崩保护, 设置0-1之间的值,当服务设置为永久实例(spring.cloud.nacos.discovery.ephemeral =false),服务下线后仍然保存在注册中心,但是健康状态为false,当设置了保护阈值假设为0.6,两个服务实例下线其中一个,当健康实例/总实例=0.5<保护阈值0.6则会进行雪崩保护,下线的服务依然作为可用服务进行调用,分担压力,防止洪峰流量压垮剩下的健康实例。
服务实例的集合,服务实例组成一个默认集群, 集群可以被进一步按需求划分,比如北京集群、福建集群。Nacos中分为三层隔离,分别是命名空间(namespace)隔离、组(group)隔离、集群(cluster-name)隔离。命名空间是绝对隔离,配置和服务都不可调用。组隔离是同一命名空间下,不同组配置可以共享和继承,但是服务不能跨组调用。而集群隔离,是可以让同一命名空间,同一个分组下,同一集群内服务隔离或不隔离。
集群隔离,主要解决的痛点是:用nacos多人协同开发几个相同的微服务模块时,每个开发人员希望自己本地启动的微服务,会调用到自己本地的另外一个微服务。而公共的微服务还是调用远程的服务器上的微服务。
办法如下:
通过引入如下两个配置:
spring.cloud.nacos.discovery. cluster-name=limy
服务名.ribbon.NFLoadBalancerRuleClassName=com.alibaba.cloud.nacos.ribbon.NacosRule
结合负载均衡器权重的机制,设置的值越大,分配的流量越大
1.CAP原则又称CAP定理,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)
2.临时实例,选择AP架构,使用Distro协议,分布式协议的一种,阿里内部的协议,服务是放在内存中
3.持久实例,选择CP架构,使用Raft协议来实现,服务是放在磁盘中
注册nacos的client节点注册时ephemeral=true,那么nacos集群对这个client节点的效果就是ap的采用distro,而注册nacos的client节点注册时ephemeral=false,那么nacos集群对这个节点的效果就是cp的采用raft
点击下线之后,默认20S不可访问到该服务
![在这里插入图片描述](https://img-blog.csdnimg.cn/4c9f5974f06d462bb52182c1fccf4f6d.png#pic_center)
4.Nacos配置使用介绍
1.配置管理->配置列表->显示已经创建配置,可以切换查看不同命名空间下的配置
2.新建配置
Data ID:Data ID 是配置集的唯一标识,一个应用可以包含多个配置集,每个配置集都需要被一个有意义的名称标识;一般为 前缀-环境-扩展名:prefix:前缀,默认是 spring.application.name 的值,也可以通过配置项 spring.cloud.nacos.config.prefix 来配置;active:配置运行环境,即为当前环境对应的 profile;file-exetension:配置文件的类型,默认是 properties 类型有:TEXT、JSON、XML、YAML、HTML、Properties
3.历史版本
可以查看配置的历史版本和提供回滚操作
4.监听查询
查看当前配置文件有没正确的推送到nacos客户端
5.权限管理
修改nacos服务application.properties文件
nacos.core.auth.enabled=true
6.用户管理/角色管理授权等
1.引入依赖(参考单机模式依赖)
2.nacos服务器添加配置(参考上面)
3.增加bootstrap.yml配置 如果data Id跟服务名不一致,就要手动指定data id
spring:
cloud:
nacos:
server-address: 127.0.0.1:8848,127.0.0.1:8849
config:
namespace: public
file-extension: yaml
extension-configs:
- data-id: common-config.yaml
refresh: true
username: nacos
password: nacos
4.@RefreshScope 方法和类上
@Value注解可以获取到配置中心的值,但是无法动态感知修改后的值,需要利用@RefreshScope注解
Nacos面试题
1. Nacos和Eureka的区别
Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式,非临时实例采用主动检测模式;临时实例心跳不正常会被剔除,非临时实例则不会被剔除
Nacos集群默认采用AP方式,当集群中存在非临时实例时,采用CP模式;Eureka采用AP方式
Nacos是基于netty的长连接;eureka是定时心跳的短连接
默认心跳频率不同eureka 30S心跳 3次未收到,EurekaServer 60S定时间隔下线;nacos 5S心跳,15S实例置为不健康,30S删除实例
保护机制:Eureka检查15分钟内正常实例占比,低于85%则保护失效实例,默认90S没有回复剔除,直到健康比例大于85%
Nacos健康实例低于设定的保护阈值则把不健康的实例也返回使用,牺牲了部分流量,保证服务不会雪崩
nacos是注册中心+配置中心;eureka仅仅是注册中心,需要配合springcloud-config使用配置中心