2024年Java最全使用SpringCloudConfig进行分布式配置：存储库后端类型，2024年最新Java面试点梳理_springcloudconfig使用

总结

上述知识点，囊括了目前互联网企业的主流应用技术以及能让你成为“香饽饽”的高级架构知识，每个笔记里面几乎都带有实战内容。

很多人担心学了容易忘，这里教你一个方法，那就是重复学习。

打个比方，假如你正在学习 spring 注解，突然发现了一个注解@Aspect，不知道干什么用的，你可能会去查看源码或者通过博客学习，花了半小时终于弄懂了，下次又看到@Aspect 了，你有点郁闷了，上次好像在哪哪哪学习，你快速打开网页花了五分钟又学会了。

从半小时和五分钟的对比中可以发现多学一次就离真正掌握知识又近了一步。

人的本性就是容易遗忘，只有不断加深印象、重复学习才能真正掌握，所以很多书我都是推荐大家多看几遍。哪有那么多天才，他只是比你多看了几遍书。

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

在本章中，之前的所有示例都使用了文件系统后端，这意味着配置文件是从本地文件系统或类路径加载的。这种类型的后端非常适合教程或测试。但是，如果要在生产模式中使用Spring Cloud Config,则需要考虑其他选项。第一个是基于Git的存储库后端(Repository Backend)，并且在默认情况下也会启用它。当然，它并不是唯一可用作配置源存储库的版本控制系统(Version Control System，VCS) 。

另一个选项是SVN (它是Subversion 的简称，这也是一个开放源代码的版本控制系统)。或者，开发人员还可以考虑创建一个复合环境，它可能同时包含Git和SVN存储库。下一个受支持的后端类型是Vault,它基于由HashiCorp提供的工具。在管理密码或证书等安全属性时尤其有用。接下来我们将详细讨论每一一个解决方案。

文件系统后端

======

关于文件系统后端的内容，其实在前面的示例中已经讨论过很多了。所有这些示例都展示了如何在类路径中存储属性源，并且还可以从磁盘加载它们。默认情况下，Spring Cloud Config Server会尝试在应用程序的工作目录或此位置的config子目录中查找文件。开发人员可以使用spring cloud.config. server.native. .searchI ocations属性覆盖默认位置。搜索位置路径可能包含application. profile 和label等占位符。如果在位置路径中没有使用任何占位符，则存储库会自动将label参数附加为后缀。

因此，配置文件将从每个搜索位置和与label 参数同名的子目录加载。这意味着file:/home/example/config与fle:/home/example/config. fle:/home/example/config/ {label}是相同的。通过将

spring.cloud.config.server.native.addLabelLocations 设置为false 可以禁用此行为。

正如前文所述，文件系统后端不是生产部署的好选择。如果将属性源放在JAR文件内的类路径中，则每次更改都需要重新编译应用程序。另外，使用JAR之外的文件系统虽然不需要重新编译，但如果在高可用性模式下有多个配置服务实例，则此方法可能会很麻烦。在这种情况下，需要跨所有实例共享文件系统或保存每个运行实例的所有属性源的副本。Git 后端就没有这些缺点，这也是它被推荐用于生产模式的原因。

Git 后端

=======

Git版本控制系统具有的一些功能，使其作为属性源的存储库非常有用。它允许开发人员轻松管理和审核更改。通过使用众所周知的VCs机制，如提交(Commpit) 、还原(Revert)和分支(Branch)，开发人员可以比使用文件系统方法更轻松地执行重要操作。这种类型的后端还有另外两个关键优势。它会强制在Config Server 源代码和property文件存储库之间产生分离。如果开发人员再看一遍前面的示例，就会发现这些示例的property文件是与应用程序源代码一起存储的。

可能有些人会说，即使开发人员使用的是文件系统后端，也可 以将整个配置作为一个单独的项目存储在Git.上, 并根据需要将其上传到远程服务器。这样说固然没错，但是，如果能与Spring Cloud Config一起使用Git后端，则可以使用现成的有效机制，何乐而不为呢?此外，它还解决了与运行多个服务器实例相关的问题。如果使用的是远程Git服务器，则可以在所有正在运行的实例中轻松共享更改。

1.不同的协议

要为应用程序设置Git 存储库的位置，可以使用application.yml 中的spring.cloud.config,server.gituri属性。如果开发人员熟悉Git,则应该很清楚地知道，可以使用file、htpthttps和ssh协议实现克隆。对本地存储库的访问允许开发人员在没有远程服务器的情况下快速开始。它可以使用file 前缀进行配置，如spring cloud. config server. gitri-file:/home/git/config-repo。要在高可用性模式下运行Config Server (这是更高级的用法)，则可以使用SSH或HTTPS远程协议。在这种情况下，Spring Cloud Config将克隆远程存储库，并在此基础上使用本地工作副本作为缓存。

2.在URI中使用占位符

这里还支持所有最近列出的占位符，如aplication. profile 和label.开发人员可以使用占位符为每个应用程序创建一个单 独的存储库，如htp:/ithb.co/piomin/ application},甚至可以为每个配置文件创建单独的存储库，如hts:/github. com/piomin/{profile}。这种类型的后端实现可以将HTTP资源的label参数映射到Git标签,该标签可以引用提交ID.分支或标记名称等。同样，要理解这些有趣功能的最合适的方法就是通过示例，所以接下来我们将创建一一个专门用于存储应用程序属性源的Git存储库。

3.构建服务器应用程序

笔者已经创建了一个示例配置存储库，它可以在以下GitHub地址找到:

https://github . com/piomin/sample-spring-cloud-config-repo.git.

在该存储库中放置了本章第一个示例所使用的所有属性源，其中说明了在不同发现区域中运行的客户端应用程序的原生配置文件支持。现在，该存储库保存了此列表中可见的文件，如图5.3所示。

Spring Cloud Config Server默认会在第一次 HTTP资源调用后尝试克隆存储库。如果要在启动后强制克隆它，则应将cloneOnStart属性设置为true。除此之外，还需要设置存储库连接设置和账户身份验证凭据。

spring:

application:

name: config-server

cloud:

config:

server:

git:

uri :https://github . com/piomin/ sample-spring-cloud-config-repo.git

username: ${gi thub。username }

password: $ {github. password }

cloneOnStart: true

运行该服务器之后，我们可以调用之前练习中已知的端点，如ht/o/alos/8889/client- service/zone1或ht:/oca/hos/888/eclient-servicec zone2.yml。其结果与前面的测试结果相同，唯一的区别在于数据源。

现在可以来进行另一项练习。在之前的示例中，由于采用了发现优先引导方法，并且启用了native 配置文件，所以该示例需要对客户端的属性略作修改。现在因为使用的是Git后端，所以，可以针对这种情况开发更智能的解决方案。在当前的方法中，开发人员应该在GitHub上的配置库中创建discovery 分支

tps:/ihub.o/pioin/samoplrep spring- cloud- config rep:/ree/discovery)，然后再把专用于该应用程序的文件放上去(该应用程序将演示发现优先引导机制)。如果将label参数设置为discovery然后再调用Config Server端点，则它将从新分支中获取数据。开发人员可以尝试分别调用ht:/ahost:8889/client-service/zone l/discovery和htpt//ocalhost/889/dicovery/cient-servicc -zone2.yml,然后检查和对比其结果。

现在来考虑另一种情况。假设已经更改了client-service 第三个实例的服务器端口，但由于某种原因，想要回到之前的值。那么，是否必须更改并提交client-service zone3.yml才能使用先前的端口值呢?答案是不必，现在开发人员所要做的就是在调用HTTP API资源时将提交ID作为label参数传递。已经执行的更改如图5.4所示。

如果使用父提交ID而不是分支名称调用API端点,则将返回旧端口号作为响应。图5.4是调用htpt: