一、nginx常用配置命令

配置命令路径

/usr/local/nginx/sbin

查看nginx版本

./nginx -v

停止nginx服务

./nginx -s stop

启动nginx服务

./nginx

重新加载nginx，适用于当nginx.conf配置文件修改后，使用下面命令可以使得配置文件生效

./nginx -s reload

查看nginx服务是否运行

netstat -ntlp

二、nginx配置文件

由三部分组成

（一）、第一部分：全局块

nginx服务器全局生效的配置命令

worker_processes  1;   # 服务器并发处理能力，值越大并发能力越强（受自身配置限制）

（二）、第二部分：events块

影响nginx和用户网络的连接

worker_connections  1024;  #最大连接数1024个，需灵活配置

（三）、第三部分：http块

nginx配置最频繁的部分，比如代理，日志，缓存、第三方模块等等。
需要注意的是http块可以包括http全局块和server块

1、http全局块

包括文件引入、MIME-TYPE定义，日志自定义、连接超时等等

http {
    include       mime.types;      #文件扩展名与文件类型映射表
    default_type  application/octet-stream;  # 访问到未定义的扩展名的时候，就默认为下载该文件

2、server块

与虚拟主机有密切关系，主要是为了节省硬件成本
一个http块可以包含多个server块，而一个server块就等于一个虚拟主机
server块又包含全局server块和location块
全局server块

server {
    listen       8012;       #  目前监听的端口号
    server_name  localhost;  # 主机名称

3、location块

   location / {     #表示默认首页
            root   html;
            index  index.html index.htm;

三、nginx配置反向代理

（一）、预计实现的效果

1、访问URL http://www.giunwr.cn:8012/xxx(不包括下面2种情况) 内部跳转到tomcat服务器8080端口
2、访问http://www.giunwr.cn:8012/8080/xxx 内部跳转到 http://www.giunwr.cn:8080/xxx
3、访问 http://www.giunwr.cn:8012/8081/xxx 内部跳转到 http://www.giunwr.cn:8081/xxx

（二）、前期准备

安装tomcat服务(需要安装2个，一个8080端口，一个8081端口)
下载tomcat，如果链接404，就到官网下再找个

wget https://dlcdn.apache.org/tomcat/tomcat-10/v10.0.16/bin/apache-tomcat-10.0.16.tar.gz

安装过程

tar -zxvf  apache-tomcat-10.0.16.tar.gz # 解压
cd apache-tomcat-10.0.16  # 进入tomcat主目录
cd bin  # 进入bin目录
./startup.sh   # 启动tomcat服务

如果jdk报错
安装命令如下

yum -y install java-1.8.0-openjdk*

查看tomcat服务是否正常运行

cd logs/        #   进入日志路径
tail -f catalina.out    # 查看 tomcat运行日志

内网环境测试
可以正常访问

外网环境测试
emmm, 忘记开防火墙了（放行8080端口）

放行8080端口后，
访问URL http://www.giunwr.cn:8012
外网测试成功

修改tomcat默认端口
修改配置文件server.xml

apache-tomcat-10.0.16/conf   # 配置文件路径

测试文件的准备
在webapps目录下创建相关的html文件

（三）、实现反向代理

修改nginx.conf文件

 vim /usr/local/nginx/conf/nginx.conf

其中 ~ 表示正则匹配，优先级高于/

修改好后记得重新加载配置文件

 ./nginx -s reload

在没有防火墙的情况下访问成功

关闭防火墙，再进行测试
直接访问8080端口直接报错

访问8012端口，访问成功，说明这个命令只是在服务器内部做代理，并没有走公网。

proxy_pass http://127.0.0.1:8080

访问http://www.giunwr.cn:8012/8080/xxx 内部跳转到 http://www.giunwr.cn:8080/xxx

访问 http://www.giunwr.cn:8012/8081/xxx 内部跳转到 http://www.giunwr.cn:8081/xxx

四、nginx配置负载均衡

（一）、预期效果

浏览器输入地址http://www.giunwr.cn:8012/test/a.html,大概平均分配到8080和8081端口的tomcat服务器，实现负载均衡。
默认分配测试是轮询

（二）、前期准备

1、准备2台tomcat服务，一个端口为8080，一个端口为8081
2、2台服务器都需要在webapps目录下创建目录test，并在目录test里面创建a.html

（三）、实现功能

修改nginx配置文件
在http块中修改

upstream myserver {
    server 127.0.0.1:8080;
server 127.0.0.1:8081;
}
server {
    listen       8012;
    server_name  localhost;
    location / {
        root   html;
    proxy_pass http://myserver;
        i

其中upstream在http块里面。myserver为自定义的名称
多访问几次URLhttp://www.giunwr.cn:8012/test/a.html，可以发现几乎是8080的tomcat服务和8081的tomcat服务器之间来回访问

 for ((i=1;i<5;i++));do curl  'http://www.giunwr.cn:8012/test/a.html' ;done

（四）、负载均衡的分配策略

1、轮询（默认就是这种策略）

按请求时间逐一分配，如果某个服务器挂了，就自动剔除

2、weight(权重)

默认weight值是1,值越大表示权重越大，分配到的几率也就越大
当后端服务器性能不均时候，可以考虑该策略
示例

upstream myserver {
    server 127.0.0.1:8080 weight=5;
	server 127.0.0.1:8081 weight=10;
}

3、ip_hash

每个请求按访问ip的hash结果分配，这样子访客固定访问一个后端服务器，可以解决session问题
举个例子：
A用户固定ip，第一次访问到8080tomcat，那么后面就都是访问到这台机器
示例

upstream myserver {
    ip_hash;
    server 127.0.0.1:8080;
	server 127.0.0.1:8081;
}

4、fair(第三方)

根据后端响应时间来分配请求，需要时间短的优先分配
示例
示例

upstream myserver {
    server 127.0.0.1:8080;
	server 127.0.0.1:8081;
	fair;
}

五、nginx配置动静分离

（一）、预期效果

nginx适合处理静态界面（或者说静态请求），
tomcat适合处理动态界面（或者说动态请求）
动静分离的方式：
1、静态文件一个域名,放在独立的服务器中
2、混合发布，使用nginx分离
通过location指定不同后缀名实现不同的请求和转发。比如expires头部，用于设置过期时间

这边使用第一种方案

（二）、前期准备

准备静态资源

（三）、配置与实现

配置

location /www/ {
    root   /data/;
    index  index.html index.htm;
}
location /txt/ {
        root   /data/;
        # 列出当前目录的下的资源
        autoindex  on;
    }

实现效果

六、第三方模块stub_status安装

（一）、安装步骤

1、查看是安装该模块（默认不安装）需要进入nginx目录下的sbin目录

[sbin]# ./nginx -V 2>&1|grep stub_status

如果内容为空，即没有安装
3、查看当前已经安装的模块

./nginx -V

在这里插入图片描述

4、重新配置参数
在原来的参数基础上加上 with-http_stub_status_module

./configure --prefix=/usr/local/nginx --pid-path=/var/local/nginx/nginx.pid --lock-path=/var/local/nginx/nginx.lock --error-log-path=/var/local/nginx/error.log --http-log-path=/var/local/nginx/access.log --with-http_gzip_static_module --with-http_stub_status_module --http-client-body-temp-path=/var/local/nginx/client --http-proxy-temp-path=/var/local/nginx/proxy --http-fastcgi-temp-path=/var/local/nginx/fastcgi --http-uwsgi-temp-path=/var/local/nginx/uwsgi --http-scgi-temp-path=/var/local/nginx/scgi

5、做好备份

cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak

6、重新编译
注意只需要编译即可

make

7、替换掉原来的二进制nginx文件
在nginx安装目录下的objs目录里面

cp /root/wr/nginx-1.20.2/objs/nginx /usr/local/nginx/sbin/

（二）、配置与实现

1、配置简单的监控功能
在server块里面写入下面配置命令

location /nginx_status {
        stub_status;
        allow all;
}

2、重新启动nginx

./nginx -s reload

3、实现效果
访问http://主机地址/nginx_status即可

参数参考文档
active connections – 活跃的连接数量
server accepts handled requests — 总共处理了xxx个连接 , 成功创建xxx次握手, 总共处理了xxx个请求
reading — 读取客户端的连接数.
writing — 响应数据到客户端的数量
waiting — 开启 keep-alive 的情况下,这个值等于 active – (reading+writing), 意思就是 Nginx 已经处理完正在等候下一次请求指令的驻留连接.

（三）、遇到的问题

1、无法替换二进制nginx文件

原因是nginx服务器还在运行，需要停止nginx

./nginx -s stop

2、重新加载nginx报错
nginx: [error] open() “/usr/local/nginx/logs/nginx.pid” failed (2: No such file or directory)

解决办法，重新指定一下nginx配置文件

./nginx -c /usr/local/nginx/conf/nginx.conf

七、nginx压缩模块

在http模块里面开启压缩

gzip  on;    #开启压缩响应
gzip_http_version 1.1;  # 只针对http1.1进行压缩
gzip_comp_level 9;      # 压缩等级为9
gzip_types text/plain;  # 压缩类型为文本

其他具体参数可以参考文档
参考文档：https://www.jb51.net/article/146413.htm

八、https配置

1、先判断是否又ssl模块，可参考第六大点
2、这边已安装过ssl模块（–with-http_ssl_module）
修改配置文件，添加server模块接即可

🍈全局配置文件

全局配置文件能够对一些默认配置值进行修改。Spring Boot使用一个application.properties或者application.yaml的文件作为全局配置文件，该文件存放在src/main/resource目录或者类路径的/config，一般会选择resource目录。接下来，将针对这两种全局配置文件进行讲解∶

🍉application.properties配置文件

使用Spring lnitializr方式构建Spring Boot项目时，会在resource目录下自动生成一个空的application.properties文件，Spring Boot项目启动时会自动加载application.properties文件。我们可以在application.properties文件中定义Spring Boot项目的相关属性，当然，这些相关属性可以是系统属性、环境变量、命令参数等信息，也可以是自定义配置文件名称和位置。

server.port=17006
spring.config.name=zjq
spring.application.name=zjq-properties
spring.redis.host=localhost
spring.redis.port=6039
spring.redis.password=
spring.redis.database=0

接下来，通过一个案例对Spring Boot项目中application.properties配置文件的具体使用进行讲解。
演示:准备两个实体类文件，演示将application.properties配置文件中的自定义配置属性注入到PropertiesConfig实体类的对应属性中

1. 创建两个实体类Goods和PropertiesConfig

@Data
public class Goods {

    private Integer id;
    private String name;
}

@ConfigurationProperties(prefix = "zjq-prop")
@Component
@Data
public class PropertiesConfig {

    private Integer id;
    private String username;
    private List hobby;
    private String[] family;
    private Map map;
    private Goods goods;
}

@ConfigurationProperties： 将配置文件中以zjqProp开头的属性通过setXxx方法注入到该类的属性中
@Component： 把PropertiesConfig类作为Bean到spring容器中，只有这样才能@ConfigurationProperties注解进行赋值

2. 在resources目录下创建的application.properties文件配置如下：
   
   编写application.properties配置文件时，由于要配置的PropertiesConfig对象属性是我们自定义的,Spring Boot无法自动识别，所以不会有任何书写提示。在实际开发中，为了出现代码提示的效果来方便配置，在使用@ConfigurationProperties注解进行配置文件属性值注入时，可以在pom.xml文件中添加一个SpringBoot提供的配置处理器依赖:

<!--自定义配置提示-->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-configuration-processor</artifactId>
  <optional>true</optional>
</dependency>

在pom.xml中添加上述配置依赖后，还需要重新运行项目启动类或者使用“Ctrl+F9"快捷键（即BuildProject)重构当前Spring Boot项目方可生效。
效果如下：

3. 查看application.properties配置文件是否正确，同时查看属性配置效果，创建项目测试类，在该测试类中引入PropertiesConfig实体类Bean，并进行输出测试。

@RunWith(SpringRunner.class) // 测试启动类，并加载Spring Boot测试注解
@SpringBootTest //标记为SpringBoot测试类，并加载ApplicationContext上下文环境
public class ConfigTest {

    @Autowired
    private PropertiesConfig propertiesConfig;
    @Test
    public void propertiesConfigTest(){
        System.out.println(propertiesConfig);
    }
}

输出如下：

至此，说明application.properties配置文件属性配置正确，并通过相关注解自动完成了属性注入。

🍊application.yaml配置文件

YAML文件格式是Spring Boot支持的一种JSON超集文件格式，相较于传统的Properties配置文件，YAML文件以数据为核心，是一种更为直观且容易被电脑识别的数据序列化格式。application.yaml配置文件的工作原理和application.properties是一样的，只不过yaml格式配置文件看起来更简洁一些。我本人开发过程中一般用这种格式，更简洁更有层次感。
YAML文件的扩展名可以使用.yml或者.yaml。
application.yml文件使用“key:(空格)value"格式配置属性，使用缩进控制层级关系。这里，针对不同数据类型的属性值，介绍一下YAML

🍋value值为普通数据类型（例如数字、字符串、布尔等)

当YAML配置文件中配置的属性值为普通数据类型时，可以直接配置对应的属性值，同时对于字符串类型的属性值，不需要额外添加引号，示例代码如下

🍌value值为数组和单列集合

当YAML配置文件中配置的属性值为数组或单列集合类型时，主要有两种书写方式︰缩进式写法和行内式写法。缩进式有两种写法，行内式写法如下：

zjq-yml:
  #缩进式写法1
  hobby:
    - 爬山
    - 羽毛球
    - 篮球
  #缩进式写法2
  hobby:
    爬山,
    羽毛球,
    篮球    
  #行内式写法
  hobby:[爬山,羽毛球,篮球]  

通过上述示例对比发现，YAML配置文件的行内式写法更加简明、方便。另外，包含属性值的中括号“[”还可以进一步省略，在进行属性赋值时，程序会自动匹配和校对

🍍value值为Map集合和对象

当YAML配置文件中配置的属性值为Map集合或对象类型时，YAML配置文件格式同样可以分为两种书写方式:缩进式写法和行内式写法。

zjq-yml:
  #缩进式写法
  map:
    name: 共饮一杯无
    feature: 相当哇塞
  #行内式写法
  map: {"name":"共饮一杯无","feature":"相当哇塞"}

在YAML配置文件中，配置的属性值为Map集合或对象类型时，缩进式写法的形式按照YAML文件格式编写即可，而行内式写法的属性值要用大括号“"包含。
接下来，在Properties配置文件演示案例基础上，通过配置application.yaml配置文件对YmlConfig对象（属性同上述PropertiesConfig类）进行赋值，具体使用如下

1. 在项目的resources目录下，新建一个application.yml配置文件，在该配置文件中编写为YmlConfig类设置的配置属性。

zjq-yml:
  id: 666
  username: 共饮一杯无
  hobby:
    - 爬山
    - 羽毛球
    - 篮球
  family: [father,mother,wife]
  #缩进式写法
#  map:
#    name: 共饮一杯无
#    feature: 相当哇塞
  #行内式写法
  map: {"name":"共饮一杯无","feature":"相当哇塞"}
  goods: {"id":"666","name":"宇宙飞船"}

2. 执行测试验证

    @Autowired
    private YmlConfig ymlConfig;

    @Test
    public void ymlConfigTest(){
        System.out.println(ymlConfig);
    }

输出如下：

💡注意：application.properties和application.yml如果配置相同属性，application.properties会覆盖application.yml的配置。

🥭配置文件属性值的注入使用

Spring Boot全局配置文件设置属性时:
如果配置属性是Spring Boot已有属性，例如服务端口server.port，那么Spring Boot内部会自动扫描并读取这些配置文件中的属性值并覆盖默认属性。
如果配置的属性是用户自定义属性，例如刚刚自定义的Person实体类属性，还必须在程序中注入这些配置属性方可生效。
Spring Boot支持多种注入配置文件属性的方式，下面来介绍如何使用注解@ConfigurationProperties和@Value注入属性

🍎使用@ConfigurationProperties注入属性

Spring Boot提供的@ConfigurationProperties注解用来快速、方便地将配置文件中的自定义属性值批量注入到某个Bean对象的多个对应属性中。上述全局配置properties和yml配置代码使用@Component和@ConfigurationProperties(prefix = “zjq-prop”)将配置文件中的每个属性映射到PropertiesConfig类组件中。此处不再赘述。

🍏使用@Value注入属性

@Value注解是Spring框架提供的，用来读取配置文件中的属性值并逐个注入到Bean对象的对应属性中，Spring Boot框架从Spring框架中对@value注解进行了默认继承，所以在Spring Boot框架中还可以使用该注解读取和注入配置文件属性值。使用@Value注入属性的示例代码如下。
配置类：

@Configuration
@Data
public class ValueConfig {

    @Value("${my.name}")
    private String name;

    @Value("${my.address}")
    private String address;


    @Value("${my.feature}")
    private String feature;
}

上述代码中，使用@Configuration和@Value注入Person实体类的id属性。其中，@Value不仅可以将配置文件的属性注入Person的id属性，还可以直接给id属性赋值，这点是@ConfigurationProperties不支持的
配置文件：

my:
  name: zjq-dev
  address: zjq-小溪
  feature: 帅的雅痞

测试验证：

    @Autowired
    private ValueConfig valueConfig;

    @Test
    public void valueConfigTest(){
        System.out.println(valueConfig);
    }

输出如下：

可以看出，测试方法valueConfigTest()运行成功，同时正确打印出了ValueConfig实体类对象。需要说明的是，本示例中只是使用@Value注解对实例中Student对象的普通类型属性进行了赋值演示，而@Value注解对于包含Map集合、对象以及YAML文件格式的行内式写法的配置文件的属性注入都不支持，如果赋值会出现错误。

🍐自定义配置

spring Boot免除了项目中大部分的手动配置，对于一些特定情况，我们可以通过修改全局配置文件以适应具体生产环境，可以说，几乎所有的配置都可以写在application.peroperties文件中，Spring Boot会自动加载全局配置文件从而免除我们手动加载的烦恼。但是，如果我们自定义配置文件，Spring Boot是无法识别这些配置文件的，此时就需要我们手动加载。接下来，将针对Spring Boot的自定义配置文件及其加载方式进行讲解

🍑使用@PropertySource加载配置文件

对于这种加载自定义配置文件的需求，可以使用@PropertySource注解结合@Configuration注解配置类的方式来实现。@PropertySource注解用于指定自定义配置文件的具体位置和名称。同时，为了保证Spring Boot能够扫描该注解，还需要类上添加@Configuration注解将实体类作为自定义配置类。当然，如果需要将自定义配置文件中的属性值注入到对应类的属性中，可以使用@ConfigurationProperties或者@Value注解进行属性值注入
演示:

1. 打开Spring Boot项目的resources目录，在项目的类路径下新建一个zjq.properties自定义配置文件，在该配置文件中编写需要设置的配置属性。

zjq.name=詹先生
zjq.age=18
zjq.feature=帅

2. 新创建一个配置类CustomPropertiesConfig，提供zjq.properties自定义配置文件中对应的属性，并根据@PropertySource注解的使用进行相关配置

/**
 * 自定义配置
 * @author zjq
 * @date 2021/9/11 23:03
 * <p>title:</p>
 * <p>description:</p>
 *
 *要使用@ConfigurationProperties需要在主类指定@EnableConfigurationProperties
 */
@ConfigurationProperties(prefix = "zjq")
@PropertySource("classpath:zjq.properties")
@Configuration
@Data
public class CustomPropertiesConfig {

    private String name;

    private Integer age;

    private String feature;
}

主要是一个自定义配置类，通过相关注解引入了自定义的配置文件，并完成了自定义属性值的注入。针对示例中的几个注解，具体说明如下:

• @Configuration注解表示当前类是一个自定义配置类，并添加为Spring容器的组件，这里也可以使用传统的@Component注解;
• @PropertySource("classpath:zjq.properties")注解指定了自定义配置文件的位置和名称，此示例表示自定义配置文件为classpath类路径下的test.properties文件;
• @ConfigurationProperties(prefix = "zjq")注解将上述自定义配置文件zjq.properties中以zjq开头的属性值注入到该配置类属性中。
• 如果配置类上使用的是@Component注解而非@Configuration注解，那么@EnableConfigurationProperties注解还可以省略。

3. 进行测试

    @Autowired
    private CustomPropertiesConfig customPropertiesConfig;

    @Test
    public void customPropertiesConfigTest(){
        System.out.println(customPropertiesConfig);
    }

可以正常输出配置。

🍒使用@Configuration编写自定义配置类

在Spring Boot框架中，推荐使用配置类的方式向容器中添加和配置组件。
在Spring Boot框架中，通常使用@Configuration注解定义一个配置类，Spring Boot会自动扫描和识别配置类，从而替换传统Spring框架中的XML配置文件。
当定义一个配置类后，还需要在类中的方法上使用@Bean注解进行组件配置，将方法的返回对象注入到Spring容器中，并且组件名称默认使用的是方法名，当然也可以使用@Bean注解的name或value属性自定义组件的名称
演示:

1. 新创建一个类MyService，该类中不需要编写任何代码

public class MyService {
}

创建了一个空的MyService类，而该类目前没有添加任何配置和注解，因此还无法正常被Spring Boot扫描和识别

2. 新建一个配置类MyConfig，并使用@Configuration注解将该类声明一个配置类，内容如下:

@Configuration // 定义该类是一个配置类
public class MyConfig {
    @Bean // 将返回值对象作为组件添加到spring容器中，该组件id默认为方法名
    public MyService myService() {

        return new MyService();
    }
}

MyConfig是@Configuration注解声明的配置类(类似于声明了一个XML配置文件)，该配置类会被Spring Boot自动扫描识别;使用@Bean注解的myService()方法，其返回值对象会作为组件添加到了Spring容器中（类似于XML配置文件中的标签配置)，并且该组件的id默认是方法名myService。

3. 进行测试

    @Autowired
    private ApplicationContext applicationContext;
    @Test
    public void iocTest() {
    System.out.println(applicationContext.containsBean("myService"));
    }

上述代码中，先通过@Autowired注解引入了Spring容器实例ApplicationContext，然后在测试方法iocTest()中测试查看该容器中是否包括id为myService的组件。
从测试结果可以看出，测试方法iocTest()运行成功，显示运行结果为true，表示Spirng的IOC容器中也已经包含了id为myService的实例对象组件，说明使用自定义配置类的形式完成了向Spring容器进行组件的添加和配置。

🍓随机数设置及参数间引用

在Spring Boot配置文件中设置属性时，除了可以像前面示例中显示的配置属性值外，还可以使用随机值和参数间引用对属性值进行设置。下面，针对配置文件中这两种属性值的设置方式进行讲解。

🥝随机值设置

在Spring Boot配置文件中，随机值设置使用到了Spring Boot内嵌的RandomValuePropertySource类，对一些隐秘属性值或者测试用例属性值进行随机值注入。
随机值设置的语法格式为${random.xx}，xx表示需要指定生成的随机数类型和范围，它可以生成随机的整数、uuid或字符串，示例代码如下：

my:
  secret: ${random.value} # 配置随机值
  number: ${random.int} #配置随机整数
  bignumber: ${random.long} # 配置随机long类型数
  uuid: ${random.uuid} # 配置随机uuid类型数
  number:
    less:
      than:
        ten: ${random.int(10)} #配置小于10的随机整数
    in:
      range: ${random.int[1024,65536]} # 配置范围在[ 1024,65536]之间的随机整

上述代码中，使用RandomValuePropertySource类中random提供的随机数类型，分别展示了不同类型随机值的设置示例。

🍅参数间引用

在Spring Boot配置文件中，配置文件的属性值还可以进行参数间的引用，也就是在后一个配置的属性值中直接引用先前已经定义过的属性，这样可以直接解析其中的属性值了。
使用参数间引用的好处就是，在多个具有相互关联的配置属性中，只需要对其中一处属性预先配置，其他地方都可以引用，省去了后续多处修改的麻烦
参数间引用的语法格式为${xx}，xx表示先前在配置文件中已经配置过的属性名，示例代码如下

app.name=MyApp
app.description=$ {app.name} is a Spring Boot application

上述参数间引用设置示例中，先设置了"app.name=MyApp"，将app.name属性的属性值设置为了MyApp;接着，在app.description属性配置中，使用${app.name}对前一个属性值进行了引用
接下来，通过一个案例来演示使用随机值设置以及参数间引用的方式进行属性设置的具体使用和效果，具体步骤如下

1. 打开Spring Boot项目resources目录下的application.properties配置文件，在该配置文件中分别通过随机值设置和参数间引用来配置两个测试属性，示例代码如下

spring:
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
        namespace: f70bfdsfb-6fdsf3-43fd-9eba-8a5dsfsge81
      config:
        server-addr: ${spring.cloud.nacos.discovery.server-addr}
        namespace: ${spring.cloud.nacos.discovery.namespace}

2. 测试类验证

    @Value("${spring.cloud.nacos.config.server-addr}")
    private String addr;
    @Value("${spring.cloud.nacos.config.namespace}")
    private String namespace;

    @Test
    public void placeholderTest() {
        System.out.println("addr："+addr);
        System.out.println("namespace："+namespace);
    }

输出如下：

🥥banner图定义

在resources目录下创建banner.txt文件，项目启动的时候会加载里面的banner图。
还可以配置一些属性信息：

• ${AnsiColor.BRIGHT_RED}：设置控制台中输出内容的颜色
• ${application.version}：用来获取MANIFEST.MF文件中的版本号
• ${application.formatted-version}：格式化后的${application.version}版本信息
• ${spring-boot.version}：Spring Boot的版本号
• ${spring-boot.formatted-version}：格式化后的${spring-boot.version}版本信息

我的banner.txt文件配置如下：

${AnsiColor.BRIGHT_BLUE}
${spring-boot.version}

                          /$$$$$$             /$$$$$$                      /$$
                         /$$__  $$           /$$__  $$                    | $$
 /$$$$$$$$ /$$  /$$$$$$ | $$  \__/  /$$$$$$ | $$  \__/  /$$$$$$   /$$$$$$ | $$
|____ /$$/|__/ /$$__  $$|  $$$$$$  /$$__  $$| $$       /$$__  $$ /$$__  $$| $$
   /$$$$/  /$$| $$  \ $$ \____  $$| $$  \ $$| $$      | $$  \ $$| $$  \ $$| $$
  /$$__/  | $$| $$  | $$ /$$  \ $$| $$  | $$| $$    $$| $$  | $$| $$  | $$| $$
 /$$$$$$$$| $$|  $$$$$$$|  $$$$$$/|  $$$$$$/|  $$$$$$/|  $$$$$$/|  $$$$$$/| $$
|________/| $$ \____  $$ \______/  \______/  \______/  \______/  \______/ |__/
     /$$  | $$      | $$
    |  $$$$$$/      | $$
     \______/       |__/


//                          _ooOoo_                               //
//                         o8888888o                              //
//                         88" . "88                              //
//                         (| ^_^ |)                              //
//                         O\  =  /O                              //
//                      ____/`---'\____                           //
//                    .'  \\|     |//  `.                         //
//                   /  \\|||  :  |||//  \                        //
//                  /  _||||| -:- |||||-  \                       //
//                  |   | \\\  -  /// |   |                       //
//                  | \_|  ''\---/''  |   |                       //
//                  \  .-\__  `-`  ___/-. /                       //
//                ___`. .'  /--.--\  `. . ___                     //
//              ."" '<  `.___\_<|>_/___.'  >'"".                  //
//            | | :  `- \`.;`\ _ /`;.`/ - ` : | |                 //
//            \  \ `-.   \_ __\ /__ _/   .-` /  /                 //
//      ========`-.____`-.___\_____/___.-`____.-'========         //
//                           `=---='                              //
//      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^        //
//            佛祖保佑       永不宕机     永无BUG                  //


更多banner参考网站：
http://patorjk.com/software/taag/#p=display&f=Graffiti&t=zjq
https://www.degraeve.com/img2txt.php#sample

效果如下：

😄😄😄可以用来镇压bug。

本文内容到此结束了，
如有收获欢迎点赞👍收藏💖关注✔️，您的鼓励是我最大的动力。
如有错误❌疑问💬欢迎各位大佬指出。
主页：共饮一杯无的博客汇总👨‍💻

保持热爱，奔赴下一场山海。🏃🏃🏃

        上篇文章介绍了 Nacos 作为注册中心的用法，除此之外，Nacos 还能作为配置中心使用，那这篇文章就介绍下 Nacos 作为配置中心的基本用法，首先我们先了解下为什么需要使用配置中心。

一、为什么需要配置中心：

在没有配置中心之前，传统应用配置的存在以下痛点：

（1）采用本地静态配置，无法保证实时性：修改配置不灵活且需要经过较长的测试发布周期，无法尽快通知到客户端，还有些配置对实时性要求很高，比方说主备切换配置或者碰上故障需要修改配置，这时通过传统的静态配置或者重新发布的方式去配置，那么响应速度是非常慢的，业务风险非常大

（2）易引发生产事故：比如在发布的时候，容易将测试环境的配置带到生产上，引发生产事故。

（3）配置散乱且格式不标准：有的用properties格式，有的用xml格式，还有的存DB，团队倾向自造轮子，做法五花八门。

（4）配置缺乏安全审计、版本控制、配置权限控制功能：谁？在什么时间？修改了什么配置？无从追溯，出了问题也无法及时回滚到上一个版本；无法对配置的变更发布进行认证授权，所有人都能修改和发布配置。

        而配置中心区别于传统的配置信息分散到系统各个角落的方式，对系统中的配置文件进行集中统一管理，而不需要逐一对单个的服务器进行管理。那这样做有什么好处呢？

（1）通过配置中心，可以使得配置标准化、格式统一化

（2）当配置信息发生变动时，修改实时生效，无需要重新重启服务器，就能够自动感知相应的变化，并将新的变化统一发送到相应程序上，快速响应变化。比方说某个功能只是针对某个地区用户，还有某个功能只在大促的时段开放，使用配置中心后只需要相关人员在配置中心动态去调整参数，就基本上可以实时或准实时去调整相关对应的业务。

（3）通过审计功能还可以追溯问题

二、Nacos配置中心的使用：

        微服务中配置中心的主流解决方案主要有三种：Nacos、Apollo、Config+Bus，不过这篇文章我们主要介绍 Nacos 作为配置中心的用法，对其他两种方式感兴趣的读者请自行上网查阅

1、Springboot 整合 Nacos 配置中心：

（1）首先我们声明项目的版本信息：

<properties>
    <spring-boot.version>2.3.2.RELEASE</spring-boot.version>
    <spring-cloud.version>Hoxton.SR9</spring-cloud.version>
    <spring-cloud-alibaba.version>2.2.6.RELEASE</spring-cloud-alibaba.version>
</properties>

<!--  只声明依赖，不引入依赖 -->
<dependencyManagement>
    <dependencies>
        <!-- 声明springBoot版本 -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>${spring-boot.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <!-- 声明springCloud版本 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring-cloud.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <!-- 声明 springCloud Alibaba 版本 -->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-alibaba-dependencies</artifactId>
            <version>${spring-cloud-alibaba.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

（2）添加 nacos 配置中心的 maven 依赖：

<!-- SpringCloud Ailibaba Nacos Config -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

（3）在 application.properties 文件中添加 nacos 配置中心相关配置：

spring.profiles.active=dev
spring.application.name=cloud-producer-server
server.port=8080

# nacos 配置中心地址
spring.cloud.nacos.config.server-addr=localhost:8848
# 配置文件的类型
spring.cloud.nacos.config.file-extension=yaml

（4）在 nacos 控制台新建一个 DataID 为 cloud-producer-server-dev.yaml 的配置集：

为什么 DataID 的命名为 cloud-producer-server-dev.yaml 会在下文介绍

 （5）编写测试类：

//配置发布之后，动态刷新配置
@RefreshScope
@RestController
@RequestMapping("provider")
public class ProviderController
{
    // 使用原生注解@Value()导入配置
    @Value("${user.id}")
    private String id;
    @Value("${user.name}")
    private String name;
    @Value("${user.age}")
    private String age;

    @GetMapping("getNacosConfig")
    public String providerTest()
    {
        return "我是provider，已成功获取nacos配置中心的数据：(id:" + id + ",name:" + name + ",age:" + age +")";
    }
}

（6）启动服务验证：

        启动项目，访问 http://localhost:8080/provider/getNacosConfig 接口，可以看到 nacos 配置中心的配置信息已经生效并被成功获取到了

（7）验证动态刷新配置：

        配置的动态刷新是配置中心最核心的功能之一，假设我现在需要修改 user.name 的值，那么我直接改变 Nacos 中的配置会生效吗？我们试下直接将 Nacos 中的配置修改成 “zhangsan”，如下图：

 此时不重启项目并重新访问该接口，结果如下：

        我们发现配置已经动态刷新了，这是为什么呢？其实是由于我们在类上添加了 @RefreshScope 注解而产生的效果。

//配置发布之后，动态刷新配置
@RefreshScope
@RestController
@RequestMapping("provider")
public class ProviderController

2、Nacos 的核心概念：

2.1、Data ID：

（1）Data ID 的命名格式：

        前面我们演示了在 nacos 控制台新建一个 DataID 为 cloud-producer-server-dev.yaml 的数据集，那么这个 Data ID 是什么呢？Data ID 是配置集的唯一标识，一个应用可以包含多个配置集，每个配置集都需要被一个有意义的名称标识。那么 Data ID 怎么取值呢？格式通俗一点就是 “前缀-环境-扩展名”，如下所示：

${spring.cloud.nacos.config.prefix}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}

① prefix：前缀，默认是 spring.application.name 的值，也可以通过配置项 spring.cloud.nacos.config.prefix 来配置。

# 若不指定，默认采用应用名的方案
spring.application.name=cloud-producer-server

# 手动指定配置的dataID前缀标识
# spring.cloud.nacos.config.prefix=cloud-producer-server-config

② active：配置运行环境，即为当前环境对应的 profile。

注意：当 spring.profiles.active 为空时，对应的连接符 ”-“ 也将不存在，dataId 的拼接格式变成 ${prefix}.${file-extension}

# dev表示开发环境
spring.profiles.active=dev

③ file-exetension：配置文件的类型，默认是 properties，也可以通过配置项 spring.cloud.nacos.config.file-extension 来配置，目前支持的类型有 TEXT、JSON、XML、YAML、HTML、Properties

# 指定配置文件类型为yaml文件
spring.cloud.nacos.config.file-extension=yaml

④ 最终配置：

        经过前面三个步骤，我们最终在nacos配置中心的控制台新增配置文件就是：cloud-producer-server.yaml

2.2、环境隔离-命名空间Namespace：

        Nacos 引入命名空间 Namespace 的概念来进行多环境配置和服务的管理及隔离。例如，你可能存在本地开发环境dev、测试环境test、生产环境prod 三个不同的环境，那么可以创建三个不同的 Namespace 区分不同的环境。创建方式如下：

 创建完成后，就可以在Nacos 控制台的配置列表上面看到不同的命名空间了，如下图：

        成功创建新命名空间后，就可以在 springboot 的配置文件配置命名空间的 id 切换到对应的命名空间，并获取对应空间下的配置文件，但在没有指定命名空间配置的情况下，默认的配置都是在 public 空间中，指定命名空间的方式如下：

# 对应创建的命名空间的ID，此处对应的是dev命名空间
cloud.nacos.config.namespace=483bb765-a42d-4112-90bc-50b8dff768b3

2.3、业务隔离-Group分组：

        Group 也可以实现环境隔离的功能，但 Group 设计的目的主要是做同一个环境中的不同服务分组，把不同的微服务的配置文件划分到同一个分组里面去，Nacos 如果不指定 Group，则默认的分组是 DEFAULT_GROUP。

        如果没有 Group，试想一下这个场景：有两个微服务，一个是订单系统，一个是用户系统，但是他们有着相同的配置，比如 datasource-url，那么如何区分呢？这时候 Group 就派上用场了。上述场景中订单系统、用户系统可以单独分为一个组，比如 ORDER_GROUP、USER_GROUP，当然这是比较细粒度的分组，根据企业的业务也可以多个微服务分为一组。

        接下来我们演示一下创建配置集时以及集成时如何指定分组，还是前面的例子，新建配置集是在如下位置指定Group分组：

 接下来在 application.properties 文件分组：

spring.cloud.nacos.config.namespace=483bb765-a42d-4112-90bc-50b8dff768b3

3、小结：

Nacos 实现配置管理和动态配置刷新很简单，总结如下步骤：

• ① 添加对应 spring-cloud-starter-alibaba-nacos-config 依赖
• ② 使用原生注解 @Value() 导入配置
• ③ 使用原生注解 @RefreshScope 刷新配置
• ④ 根据自己业务场景做好多环境配置隔离(Namespace)、不同业务配置隔离(Group)

4、共享配置：

        当我们微服务的数量越来越多，势必会有相同的配置，这时我们可以将相同的配置抽取出来作为项目中共有的配置，比如集群中的数据源信息、日志的配置信息，nacos 也是支持这种一个配置中心多个配置集这种写法的。

（1）我们在nacos中新建两个 Data ID 分别是 db.yaml 和 log.yaml 的文件。

（2）在配置文件中分别加入部分配置内容

（3）在 Springboot 项目中添加如下的 nacos 配置：

spring:
  cloud:
    nacos:
      config:
        extension-configs[0]:
          data-id: db.yaml
          # 默认为DEFAULT_GROUP
          group: DEFAULT_GROUP
          # 是否动态刷新，默认为false
          refresh: true
        extension-configs[1]:
          data-id: log.yaml
          group: DEFAULT_GROUP
          refresh: true

为了更加清晰的在多个应用间配置共享的 Data Id，官方推荐使用 shared-configs，配置如下：

spring:
  cloud:
    nacos:
      config:
        shared-configs[0]:
          data-id: db.yaml
          # 默认为DEFAULT_GROUP
          group: DEFAULT_GROUP   
          # 是否动态刷新，默认为false
          refresh: true   
        shared-configs[1]:
          data-id: log.yaml
          group: DEFAULT_GROUP
          refresh: true

（4）思考：在这2个文件中出现相同配置，nacos如何选取？

        当多个 Data Id 同时出现相同的配置时，它的优先级关系是 spring.cloud.nacos.config.extension-configs[n].data-id 其中 n 的值越大，优先级越高。

注意：spring.cloud.nacos.config.extension-configs[n].data-id 的值必须带文件扩展名，文件扩展名既可支持 properties，又可以支持 yaml/yml。此时 spring.cloud.nacos.config.file-extension 的配置对自定义扩展配置的 Data Id 文件扩展名没有影响。

（5）不同方式配置加载优先级：

        Nacos 配置中心目前提供以下三种配置能力从 Nacos 拉取相关的配置，当三种方式共同使用时，他们的一个优先级关系是:A < B < C：

• A：通过 spring.cloud.nacos.config.shared-configs[n].data-id 支持多个共享 Data Id 的配置
• B：通过 spring.cloud.nacos.config.extension-configs[n].data-id 的方式支持多个扩展 Data Id 的配置
• C：通过内部相关规则(spring.cloud.nacos.config.prefix、spring.cloud.nacos.config.file-extension、spring.cloud.nacos.config.group)自动生成相关的 Data Id 配置

---

相关阅读：

常见的服务器架构入门：从单体架构、EAI 到 SOA 再到微服务和 ServiceMesh

常见分布式理论（CAP、BASE）和一致性协议（Gosssip协议、Raft一致性算法）

一致性哈希算法原理详解

Nacos注册中心的部署与用法详细介绍

Nacos配置中心用法详细介绍

SpringCloud OpenFeign 远程HTTP服务调用用法与原理

什么是RPC？RPC框架dubbo的核心流程

服务容错设计：流量控制、服务熔断、服务降级

sentinel 限流熔断神器详细介绍

Sentinel 规则持久化到 apollo 配置中心

Sentinel-Dashboard 与 apollo 规则的相互同步

Spring Cloud Gateway 服务网关的部署与使用详细介绍

Spring Cloud Gateway 整合 sentinel 实现流控熔断

Spring Cloud Gateway 整合 knife4j 聚合接口文档

常见分布式事务详解（2PC、3PC、TCC、Saga、本地事务表、MQ事务消息、最大努力通知）

分布式事务Seata原理

RocketMQ事务消息原理

---

参考文章：

SpringBoot2.X整合Nacos做配置中心

五十五张图告诉你微服务的灵魂摆渡者Nacos究竟有多强？