步子百科config什么意思（一文吃透微服务配置中心）
我们知道，什意思文一个微服务系统可能由成千上万的吃透服务组成，每个服务都会有自己的微服务配配置，不同服务之间的置中有些配置是相同的，比如数据库。什意思文如果对于每个服务，吃透我们都复制相同的微服务配配置，一旦该配置发生了变化,那么每个服务都需要修改，置中代价可想而知。什意思文
Spring Cloud已经考虑到了这一点，吃透它为我们提供了一整套解决方案，微服务配那就是置中强大的Spring CloudConfig。
Spring Cloud Config简介Spring Cloud Config是什意思文一个高可用的分布式配置中心，它支持将配置存放到内存(本地)，吃透也支持将其放到SVN、微服务配Git等版本管理工具进行统一管理。对于Spring Cloud Config，其官方网站是这样介绍的:
Centralized external configuration management backed by a git repository. The configuration resourcesmap directly to Spring Environment but could be used by non-Spring applications if desired.
大致含义是:通过Git仓库以支持集中式外部配置管理器，配置资源直接映射到Spring环境，但如果有必要，可以由非 Spring应用程序使用。
那么，本篇将引入 Spring Cloud Config组件，带领读者领略它的风采!
创建配置中心创建配置中心一般分为以下几个步骤。
(1)创建Git仓库。为了方便测试,笔者已事先创建好Git仓库,地址为https:/github.com/lynnlovemin/SpringCloudActivity.git。
(2)创建配置中心服务端。
在原有工程中创建一个moudle，命名为config，在pom.xml加入配置中心的依赖:
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-config-server</ artifactId></ dependency><dependency><artifactId>common</ artifactId><groupId>com. lynn.blog</groupId><version>1.8-SNAPSHOT</version></dependency>在上述依赖中，我们加入了spring-cloud-config-server依赖，该依赖为配置中心的服务端依赖，有了它我们就可以将当前工程作为配置中心的服务端工程。
(3)创建启动类ConfigApplication:
@EnableConfigServerpublic class ConfigApplication extends Application{ public static void main(String[] args){ Application.startup(ConfigApplication.class,args);}}可以看到，我们添加了@EnableConfigServer注解，用来启用配置中心服务端。启动类ConfigApplication继承了Application类。
其实，Application类是一个公共的启动父类，所有工程的启动入口都继承了该类并提供了一个静态方法以调用SpringApplication。我们提供这样一个类主要是因为每个SpringCloud子工程的启动类都需要加入了@SpringCloudApplication注解，于是每个子工程的启动类只要继承了Application类，就无须再添加@SpringCloudApplication注解，Application类的代码如下:
@SpringCloudApplication@Componentscan(basePackages = "com.lynn.blog")public abstract class Application { public static void startup(class<?> cls,string[] args){ SpringApplication.run(cls,args);}}我们将Application 设置为抽象类，因为它无须实例化并且提供了静态方法 startup，该方法调用了SpringApplication.run方法，因此在ConfigApplication中直接调用startup方法就可以启动该应用。
读者应该也会注意到，Application类除了添加了@SpringCloudApplication 注解外，还添加了@ComponentScan注解，该注解可以在应用启动后，指定扫描的根包名。由于每个工程的根包名都不一样，比如 register工程为 com.lynn.blog.register，config 工程为 com.lynn.blog.config，而Application类是放到common工程中的，其根包名为com.lynn.blog.common，所以如果不指定扫描的包名，Spring容器会默认扫描com.lynn.blog.common包，导致每个子工程的服务和控制器都无法被扫描到，从而无法注人。虽然根包名都不一样，但是它们都处于com.lynn.blog包下，因此我们可以指定根包名为com.lynn.blog，这样Spring就可以扫描到整个项目。
(4)创建application.yml并增加如下内容:
server:port: 8102spring:application:name: configcloud:client:ip-address:127.e.e.1config:server:git:uri: https://github.com/lynnlovemin/SpringCloudActivity.git#配置存放到这个目录下searchPaths: configusername:***牢**password:**零宗**#使用master分支的配置label: mastereureka:instance:prefer-ip-address: trueclient:register-with-eureka: truefetch-registry : trueservice-url:defaultZone: http://admin: admin123@localhost:8101/eureka/Spring Cloud Config默认的配置仓库为Git，因此无须在配置中告诉Spring Cloud Config，直接设置Git仓库的地址、用户名和密码即可。
在上述配置中，spring.config.server.git.uri为Git仓库所在的 HTTP地址，searchPaths为该仓库的根目录，username为Git仓库用户名，password为Git仓库密码，spring.config.label为分支名，本示例设置为master（主干)分支。图8-1展示了Git仓库的截图。
可以看到，具体的配置文件其实是放到仓库的config目录下的，因此上述配置的searchPaths需要指定为config。
现在分别启动register和l config，并访问localhost:8101，就可以看到如图8-2所示的界面。
至此，配置中心服务端搭建完成。
接下来，我们改造test工程。将工程的配置放到Git仓库中并验证程序是否能够通过配置中心将配置拉取下来。
(1)在我们的Git仓库下创建一个文件，命名为test.yml，将本地配置文件内容复制到test.yml 中并删除test工程的application.yml，如图8-3所示。
(2)在resources下创建 bootstrap.yml 文件，内容如下（注意，这里必须命名为bootstrap.yml，而不是 application.yml ):
spring:cloud :config:#要拉取的配置文件名,多个配置文件以逗号隔开name : testlabel : masterdiscovery :enabled: true#配置中心spring.application.name指定的名字serviceId: configeureka:client:service-url:defaultzone: http: / / admin : admin123@localhost:8101/eureka/其中，sping.cloud.config.name表示要拉取的配置文件名。前面我们已经创建了test.yml，因此这里指定了文件名为test，我们也可以指定多个配置文件，中间以逗号隔开。由于不同的工程可能有相同的配置信息，所以可以考虑增加一个数据库的配置文件，在有数据库连接需求的工程上增加该配置文件。这样的话，如果数据库信息发生改变，只需要改变数据库的配置文件即可，大大提升了应用的可扩展性。
Spring.cloud.config.label指定了要拉取的分支，本示例指定为主干分支，discovery.enabled指定是否拉取配置，serviceId指定了配置中心的名字，该名字为config工程spring. application.name指定的名字。
配置中心同样支持多环境配置，增加test-dev.yml配置文件，在 bootstrap.yml中添加代码spring.cloud.config.profile=devR就会拉取test-dev.yml 的信息。
(3)启动test，可以看到控制台打印出了启动端口9999:
Tomcat initialized with port(s):9999(http)
这时如果将test.yml文件中的端口号改为9998，重启test后可以看到其启动端口已设置为9998,那么说明test已成功从Git仓库拉取了对应的配置。
对配置内容进行加密Spring Cloud Config在Git仓库下默认是以明文存在的。在某些场景下，我们需要对一些敏感数据(如数据库账号、密码等）进行加密存储。
Spring Cloud Config支持对配置内容进行加密存储，下面我们就来看一下如何使用加密功能。8.3.1安装JCE
由于Config Server依赖Java Cryptography Extension(简称JCE )，所以在使用加密功能前我们应先安装JCE。JCE的安装非常简单，只需要下载JCE包(详见 http://www.oracle.com/technetwork/javaljavase/downloads/jce8-download-2133166.html )，如图8-4所示。
然后解压并替换JDK安装目录下jre/lib/security的两个jar包，如图8-5所示。
如果没有security目录，则手动创建该目录。
最后需要重启IDEA，否则可能会报错:
{ "description" :“No key was installed for encryption service","status":"NO_KEY"}至此，JCE就安装完成了。Config Server同时支持对称加密和非对称加密，第4章已经介绍过两者的区别。
对称加密
Config Server默认的加密算法为对称加密算法。首先，在config 工程下新增bootstrap.yml，并设置对称加密的密钥:
encrypt:key : springcloud启动config，Config Server会开启encrypt和 decrypt两个端点，通过postman°可以测试其加密和l解密效果，如图8-6和图8-7所示。
对配置内容加密
我们可以使用{ cipher}标识对配置内容进行加密，修改Git仓库的test.yml文件,增加内容如下:
data:message: '{ cipher} b47b603d1c5551773a2385c6dafebcebf1b5a980ed08171c47ceeb226dd9f7ed'其中，b47b603d1c5551773a2385c6dafebcebf1b5a9800de8171c47c0eb226dd9f7ed 为前面通过postman加密后的字符串。
重启config工程,在浏览器中访问localhost:8102/test-default.yml,可以看到如图8-8所示的内容。
通过图8-8可以看到，Config Server已经将我们加密的内容解密为明文了。
非对称加密
Config Server同样支持非对称加密。与对称加密方法不同，非对称加密的思想是生成两个key :公钥和私钥。公钥用于加密，私钥用于解密。因此，非对称加密安全性更高，同时效率也相对较差。
(1)进入Java安装目录通过keytool生成keystore:
keytool -genkeypair -alias serverkey -keyalg RSA -keystore D:/server.jks根据提示输入相应内容，如图8-9所示。其中，-keystore后面紧跟密钥文件的路径。如果生成失败,请尝试用管理员权限启动cmd命令行。
(2)将server.jks复制到config工程的resources目录下，如图8-10所示。
(3)修改bootstrap.yml，增加以下内容:
encrypt:
keyStore:
location: classpath : server.jks
password: 111111alias: serverkeysecret: 111111
其中，password 为上面设置的密钥库口令，而secret为上面设置的密钥口令，读者一定要区分密钥库口令和密钥口令，两个口令可以相同也可以不同; location为密钥文件路径，由于Maven编译后，会将resources 的所有文件复制到classes目录下，因此这里指定classpath即可; alias为上面命令中-alias后面设置的字符串。
(4)修改pom.xml文件:
<build><resources><resource><directory>src/main/resources</directory><filtering>true</filtering><excludes><!--编译时排除jks文件，即原样复制jks文件到classes 下，不做任何处理--><!--如果不加这段代码，则编译时可能会破坏jks 文件，从而导致加解密失败--><exclude>**/*.jks</exclude></excludes></resource><resource><directory>src/main/resources</directory><filtering>false</filtering><includes><include>**/*.jks</include></includes></resource></resources></build>由于第一个配置中设置了<filtering>为true，Maven在编译时不会原样复制，而会做一定的处理再复制到classes下,所以为了保证密钥文件不被破坏,需要利用<exclude>排除.jks结尾的文件。设置filtering为true时，Maven 会替换placeholder占位符，再复制,在第一个配置中排除了.jks文件，Maven不会复制.jks文件，因此还需要将filtering 设置为false，并通过<include〉将.jks文件包含进去，保证 Maven 会将.jks文件原样复制。
(5)启动config 工程，分别访问地址localhost:8102/encrypt 和 localhost:8102/decrypt，能够得到加密和解密后的结果，如图8-11和图8-12所示。
如果报以下错误，请读者用mvn clean package命令重新编译打包工程:
配置自动刷新有些时候，我们可能会通过修改一些配置来达到我们的期望，如数据库地址发生变化时需要修改配置。如果不进行任何处理，那么每次修改配置都需要重启服务，而一个大型系统可能有成千上万个服务，每个服务都需要重启的话，代价无疑是很巨大的。
Spring Cloud Config 为我们提供了配置的刷新机制，不用重启服务就可以在线修改配置文件。
使用refresh端点刷新配置
我们首先研究手动刷新配置，其方法非常简单。
(1)添加Actuator依赖(Actuator自带refresh端点):<dependency>
<groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-actuator</artifactId></dependency>该依赖已在common 工程中添加，这里单独说明是为了告诉读者refresh端点依赖哪个包。(2)在test工程下创建一个控制器，便于我们测试:
@RestController@RefreshScopepublic class Testcontroller { @Value("$idata.message}")private String port;@RequestMapping("test")public String test(){ return port;}}可以发现，在TestController中新加入了@RefreshScope注解，作用是告诉refresh端点刷新该类所引用的配置。
(3)在Git仓库的test.yml中开启refresh端点，并将data.message 的值修改为test1:
management:endpoints :web:exposure:include: refresh,health,info在Spring Boot 2.0以后，Actuator默认只启动health和info两个端点，无法自动开启refresh端点,需要额外增加配置。
(4)测试。
①分别启动register、config和 test三个工程。②访问localhost:9999/test，返回数据testl。
③修改test.yml，将data.message的值改为test2，并重新执行步骤②，发现返回数据并未发生改变。
④用postman请求refresh端点，如图8-13所示。
⑤再次执行步骤②，发现返回了数据test2，说明配置已经生效。
Spring Cloud Bus自动刷新配置
通过上一节，我们已经实现了配置的刷新。虽然修改配置后无须重启服务，但也需人工干预，手动刷新配置，而且所有节点都必须配置refresh端点，这并不是我们想要的结果。本节，我将通过SpringCloud Bus和 Git仓库的Webhooks，实现配置的自动刷新,即修改配置后无须任何操作即可使配置生效。
Spring Cloud Bus使用轻量级的消息代理(如RabbitMQ、Kafka等）连接分布式系统的节点。通过Spring Cloud Bus可以向每个服务广播消息，如状态的变更。
本文使用RabbitMQ进行消息的分发，读者在集成Spring Cloud Bus之前需优先安装RabbitMQ,安装教程请参照本文第10章。
接下来我们集成Spring Cloud Bus。
(1)在 common工程中添加依赖:
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-bus-amqp</ artifactId></ dependency>前面已经提过，Spring Cloud Bus集成了消息队列，而 amqp正是RabbitMQ的Spring Cloud依赖。
(2)在config工程的 application.yml中增加如下配置:
management:endpoints:web:exposure:include: refresh, health,info, bus-refreshspring:rabbitmq:host: 127.e.8.1port: 5672username: guestpassword: guestvirtualHost:/publisherConfirms: true读者应该已经发现，在上述配置中，include后面多配置了一个端点bus-refresh，Spring CloudConfig是通过bus-refresh端点和 RabbitMQ进行通信的。
spring.rabbitmq为RabbitMQ的基本配置,其中 host为RabbitMQ服务地址,如果安装到本地，则为127.0.0.1或localhost; port为RabbitMQ的端口，默认端口为5672，username为RabbitMQ访问用户名;password为密码; virtualHost为虚拟主机，读者可以理解为每个virtualHost都是一个独立的RabbitMQ服务器，默认为“/”; publisherConfirms 设置为true，表示需要确认消息,也就是说消费者认了该消息，RabbitMQ才会认为该消息已经被接受，否则将会在RabbitMQ服务器中挂起。
(3)测试。
按照7.4.1节的测试方法进行测试，只是需要将refresh端点改成bus-refresh，如图8-14所示。
可以发现，配置也发生了变化，我们只需要调用Config Server的 bus-refresh端点即可完成整个系统的配置刷新。
结合Git仓库的 Webhooks，就可以实现配置的自动刷新，如图8-15所示。
Payload URL设置为远程HTTP bus-refresh端点，当有新配置被提交时，Webhooks会自动请求bus-refresh端点，从而实现配置的自动刷新。
添加用户认证在前面的配置中，我们的配置中心是可以任意访问的，虽然可以对内容进行加密设置，但为了进一步保护我们的数据，可以对配置中心设置安全认证，即输人用户名和密码才能进行访问。
(1)在config工程中添加依赖:
<dependency><groupId>org.springframework. boot</groupId><artifactId>spring-boot-starter-security</artifactId>< /dependency>前面已经提到该依赖是权限验证依赖，此处不再解释。
(2)为application.yml增加以下内容:
spring:security:user:name: admin#安全认证用户名password: admin #安全认证密码上述配置我们通过name 和 password 分别设置好用户名和密码。这样当我们启动config 并访问localhost:8102/时，将会和注册中心一样出现登录框。我们的服务若要访问配置中心，则需要配置用户名和密码，下面以 test工程为例讲解如何配置，方法很简单,只需要在bootstrap.yml添加以下内容即可:
spring:cloud:config:#配置中心用户名username: admin#配置中心密码password: admin我们分别在username 和 password配置项中设置Config Server的用户名和密码。
这时启动test工程，可以看到test工程已成功拉取配置文件。
小结本章主要介绍了Spring Cloud Config的基本用法，涵盖了Config的方方面面，从配置的拉取、内容的加密到安全认证，读者可以根据自身项目的实际要求来选择是否加密，是否进行安全认证。
本文给大家讲解的内容是springcloud实战：配置中心：SpringCloudConfig下篇文章给大家讲解的是springcloud实战：服务网关：SpringCloudGateway；觉得文章不错的朋友可以转发此文关注小编；感谢大家的支持！