微服务_Nacos
简介
Nacos（全称为“动态服务发现、配置和服务管理平台”）是阿里巴巴开源的一款云原生服务发现和配置管理平台，支持多种语言和多种环境，包括Kubernetes、Docker、Spring Cloud等常见的云原生环境。它提供了服务发现、配置管理、服务治理和流量管理等功能，使得微服务系统的构建和管理更加便捷。Nacos的特点是能够快速定位服务实例，动态管理服务，实时查看服务状态，实时监控服务流量，提升服务的可用性和稳定性。支持CP也支持AP。
对应Spring Cloud中的Eureka(服务注册与发现) + Config + Bus（自动刷新配置）
什么是配置中心
应用程序在启动和运行的时候往往需要读取一些配置信息,配置基本上伴随着应用程序的整个生命周期,比如:数据库连接参数、启动参数等。
如果项目需要更新新功能（二次发版），修改配置非常麻烦，因此在微服务中引入配置中心
特点
-
配置是独立于程序的只读变量
配置对于程序是只读的,程序通过读取配置来改变自己的行为,但是程序不应该去改变配置 -
配置伴随应用的整个生命周期
配置贯穿于应用的整个生命周期,应用在启动时通过读取配置来初始化,在运行时根据配置调整行为。比如:启动时需要读取服务的端口号、系统在运行过程中需要读取定时策略执行定时任务等。 -
配置可以有多种加载方式
常见的有程序内部hard code ,配置文件,环境变量,启动参数,基于数据库等 -
配置需要治理
同一份程序在不同的环境(开发测试生产’)、不同的集群(如不同的数据中心)经常需要有不同的配置，所以需要有完善的环境、集群配置
安装与配置简介
在官网看文档安装
修改conf/appliction.properties，改数据库配置，设置保存配置的数据库
logs在配置文件中的{BASEDIR}
sh脚本直接就后台运行
用法
引入依赖
<dependency>
<groupId>com.alibaba.cloudgroupId>
<artifactId>spring-cloud-starter-alibaba-nacos-configartifactId>
<version>2.2.3.RELEASEversion>
dependency>
client端配置（项目模块）
在bootstrap.propertis/yml文件中配置
（bootstrap比application.文件加载的更早，在父环境中就加载）
配置本服务运行的端口号、自己作为spring应用的名称、环境（会用于在nacos匹配配置文件）
以及nacos相关配置
# Tomcat
server:
port: 9200
# Spring
spring:
application:
# 应用名称
name: ruoyi-auth
profiles:
# 环境配置
active: dev
cloud:
nacos:
discovery:
# 服务注册地址
server-addr: 127.0.0.1:8848
config:
# 配置中心地址
server-addr: 127.0.0.1:8848
# 配置文件格式
file-extension: yml
# 共享配置
shared-configs:
- application-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}
共享配置是所有服务共享的配置文件，在本例中，会在nacos中心匹配到application-dev.yml文件。
如果上面因没有配置环境导致${spring.profiles.active}取不到值，nacos会自动忽视中间那个“-”，匹配applicaion.yml，不用担心会发生错误。
nacos配置中心配置
新建数据集（DataId），基本每个dataId对应一个数据文件.
然后我们可以全当在本地写好配置文件一样直接使用，用法没有改变，可以通过 @Value(“${配置项}”)将配置的值注入
- spring的原理是读取到上下文了么
通常会在Controller里边用@Value取出使用，但是你要是想改变他，就要重新改代码，打包，部署，十分麻烦，我们需要让配置文件的值变得动起来，Nacos也采用了Spring Cloud原生注解@RefreshScope实现配置自动更新。（注解在类上）
经典面试题
Nacos与Eureka的区别有哪些？
接口方式：Nacos与Eureka都对外暴露了Rest风格的API接口，用来实现服务注册、发现等功能
实例类型：Nacos的实例有永久和临时实例之分；而Eureka只支持临时实例
健康检测：Nacos对临时实例采用心跳模式检测，对永久实例采用主动请求来检测；Eureka只支持心跳模式
服务发现：Nacos支持定时拉取和订阅推送两种模式；Eureka只支持定时拉取模式
Nacos的服务注册表结构是怎样的？
Nacos采用了数据的分级存储模型，最外层是Namespace，用来隔离环境。然后是Group，用来对服务分组。接下来就是服务（Service）了，一个服务包含多个实例，但是可能处于不同机房，因此Service下有多个集群（Cluster），Cluster下是不同的实例（Instance）。
对应到Java代码中，Nacos采用了一个多层的Map来表示。结构为Map
Nacos如何支撑阿里内部数十万服务注册压力？
Nacos内部接收到注册的请求时，不会立即写数据，而是将服务注册的任务放入一个阻塞队列就立即响应给客户端。然后利用线程池读取阻塞队列中的任务，异步来完成实例更新，从而提高并发写能力。
Nacos如何避免并发读写冲突问题？
Nacos在更新实例列表时，会采用CopyOnWrite技术，首先将旧的实例列表拷贝一份，然后更新拷贝的实例列表，再用更新后的实例列表来覆盖旧的实例列表。
这样在更新的过程中，就不会对读实例列表的请求产生影响，也不会出现脏读问题了。
- 父项目pom那个client是啥？
- spring父application环境是父项目的么？如果不是maven项目会怎么样？
- 在启动的地方有个work目录