目录
配置中心（Nacos配置）
个人认为，配置中心就是把你项目的配置信息，挑选一些经常使用的，注册到nacos中，然后在你需要的时候，通过配置文件（yml）直接从nacos上直接拿下来。
背景分析
我们知道，除了代码之外，软件还有一些配置信息，比如数据库的用户名和密码，还有一些我们不想写死在代码里的东西，例如像线程池大小、队列长度等运行参数，以及日志级别、算法策略等， 还有一些是软件运行环境的参数，如Java 的内存大小，应用启动的参数，包括操作系统的一些 参数配置…… 所有这些东西，我们都叫做软件配置。以前，我们把软件配置写在一个配置文件中，就像 Windows 下的 ini 文件，或是 Linux 下的 conf 文件。然而，在分布式系统下，这样的方式就变得非常不好管理，并容易出错。假如生产环境下，项目现在正在运行，此时修改了配置文件，我们需要让这些配置生效，通常的做法是不是要重启服务。但重启是不是会带来系统服务短时间的暂停，从而影响用户体验呢，还有可能会带来经济上的很大损失（例如双11重启下服务）。基于这样的背景，配置中心诞生了。
配置中心概述
配置中心最基础的功能就是存储一个键值对，用户发布一个配置（configKey），然后客户端获取这个配置项（configValue）；进阶的功能就是当某个配置项发生变更时，不停机就可以动态刷新服务内部的配置项，例如，在生产环境上我们可能把我们的日志级别调整为 error 级别，但是，在系统出问题我们希望对它 debug 的时候，我们需要动态的调整系统的行为的能力，把日志级别调整为 debug 级别。还有，当你设计一个电商系统时，设计大促预案一定会考虑，同时涌进来超过一亿人并发访问的时候，假如系统是扛不住的，你会怎么办，在这个过程中我们一般会采用限流，降级。系统的限流和降级本质上来讲就是从日常的运行态切换到大促态的一个行为的动态调整，这个本身天然就是配置起到作用的一个相应的场景。
配置中心的选型
在面向分布式的微服务系统中，如何通过更高效的配置管理方式，实现微服务系统架构持续“无痛”的演进，并动态调整和控制系统的运行时态，配置中心的选型和设计起着举足轻重的作用。市场上主流配置中心有Apollo(携程开源)，nacos(阿里开源)，Spring Cloud Config(Spring Cloud 全家桶成员）。我们在对这些配置中心进行选型时重点要从产品功能、使用体验、实施过程和性能等方面进行综合考量。本次课程我们选择nacos，此组件不仅提供了注册中心，还具备配置中心的功能。
nacos的配置
在sca-provider项目中添加一个controller对象，起名为ProviderLogController，用这个方法来展示日志的配置。
第一步，写如下代码：
package com.jt.provider.controller;
import lombok.extern.slf4j.Slf4j;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
//@Slf4j
@RestController
public class ProviderLogController {
private static Logger logger= LoggerFactory.getLogger(ProviderLogController.class);
@GetMapping("/provider/log/doLog01")
public String doLog01(){
System.out.println();
logger.trace("====trace====");
logger.debug("====debug====");
logger.info("====info====");
logger.warn("====warn====");
logger.error("====error====");
return "log config test";
}
@Value("${logging.level.come.jt:error}")
private String loglever;
@GetMapping("/provider/log/doLog02")
public String doLog02(){
logger.error("log level is"+loglever);
return "log level is"+loglever;
}
}
第二步，在sca-provider项目中添加依赖，这个依赖的作用是设置配置中心，项目将会用一些API从nacos上获取信息
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
第三步，将项目sca-provider的application.yml的名字修改为bootstrap.yml（启动优先级最高），并添加配置中心配置，代码如下：（我试过没改的，报错了，具体原因，百度没有百度到）
server:
port: 8081
spring:
application:
name: sca-provider #进行服务注册必须配置服务名
cloud:
nacos:
discovery:
server-addr: localhost:8848
config:
server-addr: localhost:8848
file-extension: yml
新建nacos配置
点击配置列表，点击右上角的+号进行新建，我们的配置内容是输出日志的权限（日志的权限有：trace <debug<info<warn<error,这里我们使用的是debug）
其中，Data ID的值要与bootstrap.yml中定义的spring.application.name的值相同(服务名-假如有多个服务一般会创建多个配置实例，不同服务对应不同的配置实例)。配置发布以后,会在配置列表中,显示我们的配置,例如:
测试Nacos数据读取
配置创建好以后,启动sca-provider服务,然后打开浏览器,输入http://localhost:8081/provider/log/doLog01，检测idea控制台日志输出。然后再打开nacos控制台动态更新日志级别,再访问资源并检测后台日志输出.
@RefreshScope注解的应用
这个注解的作用就是刷新value注解获取过来的值
第一步：在ProviderLogController类的上面添加一个@RefreshScope注解，例如：
其中,@RefreshScope的作用是在配置中心的相关配置发生变化以后，能够及时看到类中属性值的更新(底层是通过重新创建Controller对象的方式,对属性进行了重新初始化)。
第二步：添加ProviderLogController中添加一个获取日志级别(debug<info<warn<error)的的属性和方法,代码如下:
第三步：启动sca-provider服务,然后打开浏览器并输入http://localhost:8081/provider/log/doLog02进行访问测试。
说明,假如对配置的信息访问不到,请检测项目配置文件的名字是否为bootstrap.yml,检查配置文件中spring.application.name属性的值是否与配置中心的data-id名相同,还有你读取的配置信息缩进以及空格写的格式是否正确.
Nacos配置管理模型
概述
Nacos 配置管理模型由三部分构成，如图所示：
其中：
- Namespace：命名空间，对不同的环境进⾏隔离，⽐如隔离开发环境和⽣产环境。
- Group：分组，将若⼲个服务或者若⼲个配置集归为⼀组。
- Service/DataId：某⼀个服务或配置集，一般对应一个配置文件。
命名空间设计
Nacos中的命名空间一般用于配置隔离，这种命名空间的定义一般会按照环境（开发，生产等环境）进行设计和实现.我们默认创建的配置都存储到了public命名空间，如图所示：
创建新的开发环境并定义其配置，然后从开发环境的配置中读取配置信息，该如何实现呢？
第一步：创建新命名空间，如图所示：
命名空间成功创建以后，会在如下列表进行呈现。
在指定命名空间下添加配置，也可以直接取配置列表中克隆，例如：
克隆成功以后，我们会发现在指定的命名空间中有了我们克隆的配置，如图所示
此时我们修改dev命名空间中Data Id的sca-provider配置，如图所示：
修改项目module中的配置文件bootstrap.yml,添加如下配置，关键代码如下：
spring:
cloud:
nacos:
config:
namespace: 6058fd3f-0d4d-44f2-85d6-5fc7d2348046
……
其中，namespace后面的字符串为命名空间的id，可直接从命名空间列表中进行拷贝.然后重启服务，继续刷新http://localhost:8081/provider/log/doLog02地址。检测输出，看看输出的内容是什么，是否为dev命名空间下配置的内容。
分组设计及实现
当我们在指定命名空间下，按环境或服务做好了配置以后，有时还需要基于服务做分组配置，例如，一个服务在不同时间节点(节假日，活动等)切换不同的配置，可以在新建配置时指定分组名称，如图所示：
其中,这里的useLocalCache为自己定义的配置值,表示是否使用本地缓存.
配置发布以后，修改boostrap.yml配置类，在其内部指定我们刚刚创建的分组，代码如下
server:
port: 8081
spring:
application:
name: sca-provider
cloud:
nacos:
config:
server-addr: 127.0.0.1:8848
group: DEFAULT_GROUP_51 # Group, default is DEFAULT_GROUP
file-extension: yml # Configure the data format of the content, default to properties
namespace: 7da4aa75-f64c-43c6-b101-9d77ad96f1c0
在指定的Controller类中添加属性和方法用于获取和输出DEFAULT_GROUP_51中的useLocalCache的值，代码如下：
package com.jt.provider.controller;
@RefreshScope
@RestController
public class ProviderCacheController {
@Value("${useLocalCache:false}")
private boolean useLocalCache;@RequestMapping("/provider/cache01")
public String doUseLocalCache01(){
return "useLocalCache'value is "+useLocalCache;
}
}
然后重启服务，进行访问测试，检测内容输出。
共享配置设计及读取
当同一个namespace的多个配置文件中都有相同配置时，可以对这些配置进行提取，然后存储到nacos配置中心的一个或多个指定配置文件，哪个微服务需要，就在服务的配置中设置读取即可。例如：
第一步：在nacos中创建一个共享配置文件，例如：
其中，这里的secret可以理解为一个密钥。
第二步：在指定的微服务配置文件(bootstrap.yml)中设置对共享配置文件的读取（这里在添加配置文件时注意格式，如图所示，如果不小心，就会把共享配置的data-id添加到config中，注意！注意！注意！这样就会报配置文件错误），例如：
spring:
application:
name: sca-provider
cloud:
nacos:
config:
server-addr: localhost:8848
# 命名空间
namespace: 83ed55a5-1dd9-4b84-a5fe-a734e4a6ec6d
# 分组名
# group: DEFAULT_GROUP
# 配置中心文件扩展名
file-extension: yml
# 共享配置
shared-configs[0]:
data-id: app-public.yml
refresh: true #默认false,共享配置更新,引用此配置的地方是否要更新
第三步：在指定的Controller类中读取和应用共享配置即可，例如：
package com.jt.provider.controller;
@RefreshScope
@RestController
public class ProviderSecretController {
@Value("${app.secret:123456}")
private String secret;
@GetMapping("/provider/secret")
public String doGetSecret(){
//return String.format()
return "The Secret is "+secret;
}
}
第四步：启动服务,然后打开浏览器进行访问测试。
给大家介绍一个idea小插件
idea连接网页
点击后会出现如下效果
必须使用符合的访问方式进行访问，地址和地址之间必须用3个#号隔开，可以同时写多个地址，这样在测试的时候想要那个地址，就运行那个地址，方便可靠，不用来回切换
790
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
