一文吃透微服务配置中心：SpringCloudConfig

在原有工程中创建一个moudle，命名为config，在pom.xml加入配置中心的依赖:

org.springframework.cloud

spring-cloud-config-server</ artifactId></ dependency>

common</ artifactId>com. lynn.blog

1.8-SNAPSHOT

在上述依赖中，我们加入了spring-cloud-config-server依赖，该依赖为配置中心的服务端依赖，有了它我们就可以将当前工程作为配置中心的服务端工程。

(3)创建启动类ConfigApplication:

@EnableConfigServer

public 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: master

eureka:

instance:

prefer-ip-address: trueclient:

register-with-eureka: truefetch-registry : true

service-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 : test

label : masterdiscovery :

enabled: true

#配置中心spring.application.name指定的名字serviceId: config

eureka:

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文件:

src/main/resourcestrue

**/*.jks

src/main/resourcesfalse

**/*.jks

由于第一个配置中设置了为true，Maven在编译时不会原样复制，而会做一定的处理再复制到classes下,所以为了保证密钥文件不被破坏,需要利用排除.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端点):

org.springframework.boot

spring-boot-starter-actuator

该依赖已在common 工程中添加，这里单独说明是为了告诉读者refresh端点依赖哪个包。(2)在test工程下创建一个控制器，便于我们测试:

@RestController

@RefreshScope

public 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所示。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

最后

面试题文档来啦，内容很多，485页！

由于笔记的内容太多，没办法全部展示出来，下面只截取部分内容展示。

1111道Java工程师必问面试题

MyBatis 27题 + ZooKeeper 25题 + Dubbo 30题：

Elasticsearch 24 题 +Memcached + Redis 40题：

Spring 26 题+ 微服务 27题+ Linux 45题：

Java面试题合集：

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
oom: 33%;" />

最后

面试题文档来啦，内容很多，485页！

由于笔记的内容太多，没办法全部展示出来，下面只截取部分内容展示。

1111道Java工程师必问面试题

[外链图片转存中…(img-kZ2SXPH3-1713433049025)]

MyBatis 27题 + ZooKeeper 25题 + Dubbo 30题：

[外链图片转存中…(img-pf9EAkfH-1713433049025)]

Elasticsearch 24 题 +Memcached + Redis 40题：

[外链图片转存中…(img-CM91tfBs-1713433049025)]

Spring 26 题+ 微服务 27题+ Linux 45题：

[外链图片转存中…(img-PO17wZJk-1713433049026)]

Java面试题合集：

[外链图片转存中…(img-YoXK4rN6-1713433049026)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！