标签:尺寸 data 最好 完成 分布式 eee login zook ==
Spring Cloud Config为分布式系统中的外部化配置提供服务器和客户端支持。使用Config Server,您可以在所有环境中管理应用程序的外部属性。客户端和服务器上的概念映射与Spring Environment和PropertySource抽象相同,因此它们非常适合Spring应用程序,但可以与任何语言运行的任何应用程序一起使用。当应用程序通过部署管道从开发到测试并进入生产时,您可以管理这些环境之间的配置,并确保应用程序具有迁移时需要运行的所有内容。服务器存储后端的默认实现使用git,因此它可以轻松支持配置环境的标记版本,以及可用于管理内容的各种工具。添加替代实现并使用Spring配置插入它们很容易。
服务器为外部配置(名称 - 值对或等效的YAML内容)提供基于资源的HTTP API。 使用@EnableConfigServer批注可以轻松地将服务器嵌入到Spring Boot应用程序中。 所以这个应用程序是配置服务器:
ConfigServer.java.
与所有Spring Boot应用程序一样,它默认在端口8080上运行,但您可以通过各种方式将其切换到传统端口8888。 最简单的方法是设置默认配置存储库,方法是使用spring.config.name = configserver启动它(Config Server jar中有一个configserver.yml)[相当于自定义配置文件,你可能不喜欢默认application.properities或applicayion.yml]。 另一种方法是使用您自己的application.properties
application.properties.
其中$ {user.home}/config-repo是一个包含YAML和属性文件的git存储库。
注意:在Windows中,如果文件URL是绝对的驱动器前缀,则需要额外的“/”,例如:file:///${user.home}/config。(这个即可以认为是一个本地的git仓库)
以下示例为创建git存储库的方法
使用git存储库的本地文件系统仅用于测试。 在生产中用专门的远程git仓库。
如果只保存文本文件,那么配置仓库的初始克隆将是快速和高效的。如果您开始存储二进制文件,特别是大型文件,您可能会在第一次请求配置时遇到延迟,或者服务器中的内存错误。
您想在哪里存储配置服务器的配置数据? 管理此行为的策略是EnvironmentRepository,为Environment对象提供服务。 此环境是Spring环境中域的浅表副本(包括propertySources作为主要功能)。 环境资源由三个变量参数化:
仓库实现通常就像Spring Boot应用程序一样,从“spring.config.name”加载配置文件,等于{application}参数,“spring.profiles.active”等于{profiles}参数。 配置文件的优先规则也与常规启动应用程序中的相同:profiles 配置文件优先于默认配置文件,如果有多个配置文件,则最后一个配置文件优先级最高(如向Map添加条目)。
示例:客户端应用程序具有此bootstrap配置:
bootstrap.yml.
(与通常的Spring Boot应用程序一样,这些属性也可以设置为环境变量或命令行参数)。
如果仓库是基于文件的,则服务器将从application.yml(在所有客户端之间共享)和foo.yml(以foo.yml优先)创建环境。 如果YAML文件中包含指向Spring配置文件的文档,那么它们将以更高的优先级(按列出的配置文件的顺序)应用,如果存在特定于配置文件的YAML(或属性)文件,则这些文件的优先级也高于 默认值。 较高的优先级转换为环境中先前列出的PropertySource。 (这些规则与独立的Spring Boot应用程序中的规则相同。)
EnvironmentRepository的默认实现使用Git后端【即spring cloud config分布式配置中心默认是通过git存储的】,这对于管理升级和物理环境以及审计更改非常方便。要更改仓库的位置,可以在Config Server中设置“spring.cloud.config.server.git.uri”配置属性(例如,在application.yml中)。如果您使用file:前缀设置它,它应该可以在本地仓库中运行,这样您就可以在没有服务器的情况下快速轻松地启动,但在这种情况下,服务器可以直接在本地仓库上运行而无需克隆它(如果没有,则无关紧要它不是裸露的,因为Config Server永远不会对“远程”仓库进行更改)。要向上扩展Config Server并使其具有高可用性,您需要让服务器的所有实例都指向同一个仓库,因此只有共享文件系统才能工作。即使在这种情况下,最好将ssh:protocol用于共享文件系统仓库,以便服务器可以克隆它并使用本地工作副本作为缓存。
此存储库实现将HTTP资源的{label}参数映射到git标签(提交标识,分支名称或标记)。 如果git分支或标记名称包含斜杠(“/”),则应使用特殊字符串“(_)”指定HTTP URL中的标签(以避免与其他URL路径不一致)。 例如,如果标签是foo / bar,则替换斜杠将导致标签看起来像foo(_)bar。 包含特殊字符串“(_)”也可以应用于{application}参数。 如果您使用像curl这样的命令行客户端,请小心URL中的括号(例如,使用引号‘‘将它们从shell中转义出来)。
使用占位符在Git URI中
Spring Cloud Config Server支持带有{application}和{profile}【和{label}的占位符的git存储库URL)】,其中{application}代表应用名称,当客户端像config server发获取配置请求时,config server会根据客户端的spring.application.name来填充{application}占位符以定位配置资源的存储位置。
此外,在{application}参数中使用特殊字符串“(_)”可以支持多个组织(例如):
其中{application}在请求时以“organization(_)application”格式提供。
模式匹配和多个仓库
通过应用程序(application)和配置文件(profile)名称上的模式匹配,并且支持更复杂的需求。 模式格式是带有通配符的{application}/{profile}名称,多个匹配模式用逗号隔开。
如果{application}/{profile}与任何模式都不匹配,它将使用“spring.cloud.config.server.git.uri”下定义的默认uri。 在上面的例子中,
对于smple它只匹配所有spring.application.name名为“simple”的一个应用程序无论profile为什么。
对于sepcial它匹配spring.application.name以special开头或special在中间并且profile是以dev开头的。
“local”仓库匹配所有配置文件中以“local”开头的所有应用程序名称(/ *后缀自动添加到任何没有配置文件匹配器的模式)。
只有在要设置的唯一属性是URI时,才能使用上面“simple”示例中使用的“单行”快捷方式。 如果您需要设置其他任何内容,则需要使用完整 表单。
repo中的pattern属性实际上是一个数组,因此您可以使用YAML数组(或属性文件中的[0],[1]等后缀)来绑定到多个模式。 如果要运行具有多个配置文件的应用程序,则可能需要执行此操作。 例:
Spring Cloud会猜测包含不以*结尾的配置文件的模式意味着您实际上想要匹配以此模式开头的配置文件列表(因此*/staging是[“*/ staging",“*/staging,*“])。 这是常见的,您需要在本地“开发”配置文件中运行应用程序,例如远程运行“云”配置文件。
搜索
每个仓库还可以选择将配置文件存储在子目录中,搜索这些目录的模式可以指定为searchPaths。 例如:
在上面示例中,服务器在顶级和“foo/”子目录以及名称以“bar”开头的任何子目录中搜索配置文件。
克隆仓库时机
默认情况下,服务器在首次请求配置时克隆远程存储库。 可以将服务器配置为在启动时克隆存储库。 配置 cloneOnStart为true例如:
在上面实例中,服务器在接受任何请求之前在启动时克隆team-a的config-repo。 在请求来之前,不会克隆所有其他仓库。
总结:
在Config Server启动时设置要克隆的存储库有助于在Config Server启动时快速识别配置错误的配置源(例如,无效的存储库URI)。 如果未对配置源启用cloneOnStart,则配置服务器可能会使用配置错误或无效的配置源成功启动,并且在应用程序从该配置源请求配置之前不会检测到错误。
Git认证
要在远程仓库上使用HTTP基本身份验证,请单独添加“用户名”和“密码”属性(不在URL中),例如:
如果您不使用HTTPS和用户凭据,当您将密钥存储在默认目录(?/.ssh)中并且uri指向SSH位置时,SSH也应该开箱即用。“git@github.com:配置/云配置”。 重要的是,Git服务器的条目存在于?/ .ssh/known_hosts文件中,并且它是ssh-rsa格式。 不支持其他格式(如ecdsa-sha2-nistp256)。 为了避免意外,您应该确保Git服务器的known_hosts文件中只有一个条目,并且它与您提供给配置服务器的URL匹配。 如果您在URL中使用了主机名,则希望在known_hosts文件中使用主机名,而不是IP。 使用JGit访问存储库,因此您在其上找到的任何文档都应该适用。 HTTPS代理设置可以在?/.git/config中设置,也可以通过系统属性(-Dhttps.proxyHost和-Dhttps.proxyPort)以与任何其他JVM进程相同的方式设置。
如果您不知道?/.git目录在哪里使用git config --global来操作设置(例如git config --global http.sslVerify false)。
使用属性进行Git SSH配置
默认情况下,当使用SSH URI连接到Git存储库时,Spring Cloud Config Server使用的JGit库使用SSH配置文件,例如?/.ssh/ known_hosts和/etc/ssh/ssh_config。 在Cloud Foundry等云环境中,本地文件系统可能是短暂的或不易访问的。 对于这些情况,可以使用Java属性设置SSH配置。 要激活基于属性的SSH配置,必须将属性spring.cloud.config.server.git.ignoreLocalSshSettings设置为true。
Property Name | Remarks |
---|---|
ignoreLocalSshSettings |
If true, use property based SSH config instead of file based. Must be set at as 如果为true,则使用基于属性的SSH配置而不是基于文件。 必须设置为spring.cloud.config.server.git.ignoreLocalSshSettings,而不是在仓库中定义。 |
privateKey |
Valid SSH private key. Must be set if 有效的SSH私钥。 如果ignoreLocalSshSettings为true且Git URI为SSH格式,则必须设置 |
hostKey |
Valid SSH host key. Must be set if 有效的SSH主机密钥。 如果还设置了hostKeyAlgorithm,则必须设置 |
hostKeyAlgorithm |
One of 其中一个ssh-dss,ssh-rsa,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521。 如果还设置了hostKey,则必须设置 |
proxyHost |
Hostname for the ssh proxy connection. Is optional and used only when ssh代理连接的主机名。 是可选的,仅在ignoreLocalSshSettings为true时使用 |
proxyPort |
Port for the ssh proxy connection. Must be set if ssh代理连接的端口。 如果还设置了proxyHost,则必须设置 |
strictHostKeyChecking |
true或false。 如果为false,则忽略主机密钥错误 |
knownHostsFile |
Location of custom .known_hosts file 自定义.known_hosts文件的位置 |
preferredAuthentications |
Override server authentication method order. This should allow evade login prompts if server has keyboard-interactive authentication before 覆盖服务器身份验证方法顺序。 如果服务器在publickey方法之前具有键盘交互式身份验证,则应允许evade登录提示。 |
使用占位符在Git搜索路径中
Spring Cloud Config Server还支持带有{application}和{profile}(以及{label}的占位符的搜索路径(如果需要)。 例:
在仓库中搜索与目录(以及顶层)同名的文件。 通配符在带占位符的搜索路径中也有效(搜索中包含任何匹配的目录)。
强行拉取Git仓库(整合详细总线采坑了)
如前所述,Spring Cloud Config Server会克隆远程git存储库,并且如果本地副本变得脏了(例如,OS进程更改了文件夹内容),那么Spring Cloud Config Server无法从远程存储库更新本地副本。
为了解决这个问题,有一个强制拉动属性,如果本地副本很脏,它将使Spring Cloud Config Server从远程存储库强行拉出。 例:
如果您有多个仓库配置,则可以为每个存储库配置force-pull属性。 例:
默认force-pull属性值为false
删除Git存储库中未跟踪的分支
由于Spring Cloud Config Server在签出分支到本地存储库后具有远程git存储库的克隆(例如,通过标签获取属性),它将永久保留此分支或直到下一个服务器重新启动(这将创建新的本地存储库)。 因此可能存在删除远程分支但仍然可以获取其本地副本的情况。 如果Spring Cloud Config Server客户端服务以--spring.cloud.config.label = deletedRemoteBranch启动,那么它将从deletedRemoteBranch本地分支获取属性,但不从master获取属性。
为了保持本地存储库分支的整洁和与远程存储库保持一致,可以设置deleteuntrackedbranch属性。例子
deleteUntrackedBranches属性的默认值为false。
使用基于VCS的后端(git、svn)文件被检出或克隆到本地文件系统。默认情况下,它们被放在系统临时目录中,并带有config-repo的前缀。例如在linux上,它可以是/tmp/config-repo-。一些操作系统经常清理临时目录。这可能导致意想不到的行为,如丢失属性。为了避免这个问题,通过将spring.cloud.config.server.git.basedir或spring.cloud.config.server.svn.basedir设置为不驻留在系统临时结构中的目录来更改Config Server使用的目录【即更改从远程git或svn拉取下来,在本地存储的位置】。
配置服务器中也有一个“本机”配置文件,它不使用Git,而是从本地类路径或文件系统(您希望使用“spring.cloud.config.server.native.searchLocations”指向的任何静态URL)加载配置文件。要使用本机概要文件,只需使用“spring.profiles.active=native”启动配置服务器。
注意:
请记住使用文件资源的file:前缀(没有前缀的默认值通常是类路径src/main/resource)。 与任何Spring Boot配置一样,您可以嵌入${}样式的环境占位符,但请记住,Windows中的绝对路径需要额外的“/”,例如:file:///${user.home}/config-repo
注意:
searchLocations的默认值与本地Spring Boot应用程序相同(所以[classpath:/,classpath:/ config,file:./,file:./ config])。 这不会将application.properties从服务器公开给所有客户端,因为服务器中存在的任何属性源在被发送到客户端之前都会被删除。
注意:
文件系统后端非常适合快速入门和测试。 要在生产中使用它,您需要确保文件系统是可靠的,并在Config Server的所有实例之间共享。
搜索位置可以包含{application},{profile}和{label}的占位符。 通过这种方式,您可以隔离路径中的目录,并选择对您有意义的策略(例如,每个应用程序的子目录或每个配置文件的子目录)。
如果不在搜索位置使用占位符,则仓库会将HTTP资源的{label}参数附加到搜索路径上的后缀,因此将从每个搜索位置和具有相同名称的子目录加载属性文件。 标签(标记的属性在Spring环境中优先)。 因此,没有占位符的默认行为与添加以/ {label} /结尾的搜索位置相同。 例如file:/tmp/config与file:/tmp/config,file:/tmp/config/{label}相同。 可以通过设置spring.cloud.config.server.native.addLabelLocations = false来禁用此行为。
基于文件的仓库
使用基于文件(即git,svn和native)的存储库,application*中具有文件名的资源在所有客户端应用程序之间共享(因此application.properties,application.yml,application - *.properties等)。 您可以使用具有这些文件名的资源来配置全局默认值,并根据需要由特定于应用程序的文件覆盖它们。
注意:
使用“native”配置文件(本地文件系统后端),建议您使用不属于服务器自身配置的显式搜索位置。 否则,将删除默认搜索位置中的application*资源,因为它们是服务器的一部分。
Spring Cloud Config Server支持JDBC(关系数据库)作为配置属性的后端。 您可以通过将spring-jdbc添加到类路径,使用“jdbc”配置文件或添加类型为JdbcEnvironmentRepository的bean来启用此功能。 如果在类路径中包含正确的依赖项,Spring Boot将配置数据源.
数据库需要有一个名为“PROPERTIES”的表,其中包含“APPLICATION”,“PROFILE”,“LABEL”(具有通常的环境含义)列,以及Properties样式中键和值对的“KEY”和“VALUE”。 所有字段都是Java中的String类型,因此您可以将它们设置为所需长度的VARCHAR。 属性值的行为方式与它们来自名为{application}-{profile} .properties的Spring Boot属性文件(包括所有加密和解密)的行为方式相同,后者将作为后处理步骤应用(即不在 存储库实现直接)。
在某些情况下,您可能希望从多个环境仓库中提取配置数据。 为此,您只需在配置服务器的应用程序属性或YAML文件中启用多个配置文件。 例如,如果要从Git存储库以及SVN存储库中提取配置数据,则应为配置服务器设置以下属性。
除了指定URI的每个repo之外,您还可以指定order属性。 order属性允许您指定所有仓库的优先级顺序。 order属性的数值越低,它将具有更高的优先级。 存储库的优先级顺序将有助于解决包含相同属性值的存储库之间的任何潜在冲突。
注意:
从环境仓库检索值时的任何类型的故障都将导致整个多环境失败。
使用多环境时,所有repos都包含相同的标签非常重要。 如果您的环境与上述环境类似,并且您使用标签主机请求配置数据,但SVN repo不包含名为master的分支,则整个请求将失败。
自定义多环境仓库
除了使用Spring Cloud中的一个环境仓库之外,还可以将您自己的EnvironmentRepository bean作为多环境的一部分包含在内。 为此,您的bean必须实现EnvironmentRepository接口。 如果要在复合环境中控制自定义EnvironmentRepository的优先级,则还应实现Ordered接口并覆盖getOrdered方法。 如果您没有实现Ordered接口,那么您的EnvironmentRepository将被赋予最低优先级。
Config Server附带一个运行状况指示器,用于检查配置的EnvironmentRepository是否正常工作。 默认情况下,它会向EnvironmentRepository请求名为app的应用程序,默认配置文件和EnvironmentRepository实现提供的默认标签。
name 应用名
label分支名
profiles环境名
您可以通过设置spring.cloud.config.server.health.enabled = false来禁用运行状况指示器。
默认config server允许匿名访问。为了防止配置内容外泄,对config server进行安全保护。
您可以以任何有意义的方式(从物理网络安全到OAuth2承载令牌)自由保护您的Config服务器,而Spring Security和Spring Boot可以轻松完成任何操作。
要使用默认的Spring Boot配置的HTTP基本安全,只需在类路径中包含Spring security(例如通过Spring - Boot -starter-security)。默认值是“user”的用户名和随机生成的密码,这在实践中不会很有用,因此我们建议您配置密码(通过security.user.password)并对其进行加密(参见下面的说明)。
config server
config client(配置与两种,详细见下文)
先决条件:要使用加密和解密功能,您需要在JVM中安装全功能JCE(默认情况下不存在)。 您可以从Oracle下载“Java Cryptography Extension(JCE)Unlimited Strength Jurisdiction Policy Files”,并按照安装说明进行操作(实际上将JRE lib/security目录中的2个策略文件替换为您下载的那些)。
如果远程属性源包含加密内容(以{cipher}开头的值),当微服务客户端加载配置时,它们将被自动解密。 这种设置的主要优点是,属性值在“静止”时(例如在git存储库中)不必是纯文本。 如果某个值无法解密,则会从属性源中删除该值,并使用相同的键添加其他属性,但前缀为“invalid”。 和一个表示“不适用”的值(通常为“<n/a>”)。 这主要是为了防止密文被用作密码并意外泄露。
如果要为配置客户端应用程序设置远程配置仓库,则可能包含这样的application.yml,例如:
application.yml.
.properties文件中的加密值不得用引号括起来,否则不会解密该值:
application.properties.
您可以安全地将此纯文本推送到共享的git存储库,并保护密码。
服务器还公开/encrypt和/decrypt端点(假设这些端点是安全的并且只能由授权代理访问)。 如果您正在编辑远程配置文件,则可以使用Config Server通过POST到/encrypt端点来加密值,例如:【以下为加密】
注意:请确保不要在加密值中包含任何curl命令统计信息。 将值输出到文件可以帮助避免此问题。
反向操作也可通过/decrypt获得(假设服务器配置了对称密钥或完整密钥对),列如:【以下为解密】
获取加密值并添加{cipher}前缀,然后再将其放入YAML或属性文件中,然后再提交并将其推送到远程,可能不安全的存储。
/encrypt和/decrypt端点也接受格式为/*/{name}/{profiles}的路径,当客户端调用主环境资源时,这些路径可用于控制每个应用程序(名称)和配置文件的加密。
以为主要为对称加密需要通过encrypt.key参数来指定秘钥的方式。
注意:
要以这种精细的方式控制加密,您还必须提供一个TextEncryptorLocator类型的@Bean,它为每个名称和配置文件创建一个不同的加密器。 默认情况下提供的那个不执行此操作(因此所有加密都使用相同的密钥)。
spring命令行客户端(安装了Spring Cloud CLI扩展)也可用于加密和解密,例如,
上述配置中foo为秘钥
Config Server可以使用对称(共享)密钥或非对称密钥(RSA密钥对)。 非对称选择在安全性方面更优越,但使用对称密钥通常更方便,因为它只是在bootstrap.properties中配置的单个属性值。
要配置对称密钥,您只需将encrypt.key设置为秘密字符串(或使用环境变量ENCRYPT_KEY使其不受纯文本配置文件的影响)。
config server
要配置非对称密钥,您可以将密钥设置为PEM编码的文本值(在encrypt.key中),或通过密钥库(例如由JDK附带的keytool实用程序创建)。 密钥库属性是encrypt.keyStore.*=*
location(资源位置),
password(解锁密钥库)
alias(用于标识要使用的store中的哪个键)
加密是使用公钥完成的,并且需要私钥进行解密。 因此,如果您只想进行加密(并准备使用私钥本地解密值),原则上您只能配置服务器中的公钥。 在实践中,您可能不希望这样做,因为它将密钥管理过程分散到所有客户端,而不是将其集中在服务器中。 另一方面,如果您的配置服务器确实相对不安全且只有少数客户端需要加密属性,那么它是一个有用的选项。
要创建用于测试的密钥库,您可以执行以下操作:
将server.jks文件放在类路径中(例如),然后放在Config Server的bootstrap.yml中进行相关配置:
有时您希望客户端在本地解密配置,而不是在服务器中执行此操作。 在这种情况下,您仍然可以拥有/encrypt和/decrypt端点(如果您提供encrypt.*配置来查找密钥),但您需要显式关闭属性的解密。 bootstrap中的spring.cloud.config.server.encrypt.enabled= false。[yml | properties]。 如果您不关心端点,那么如果既未配置密钥也未配置启用标志,则它应该可以正常工作。
Spring Boot应用程序可以立即利用Spring Config Server(或应用程序开发人员提供的其他外部属性源),并且还将获取与环境变化事件相关的一些其他有用功能。
这是在类路径上具有Spring Cloud Config Client的任何应用程序的默认行为。 当配置客户端启动时,它会绑定到配置服务器(通过在bootstrap中设置属性spring.cloud.config.uri)并使用远程属性源初始化Spring Environment。
最终结果是,所有想要使用Config Server的客户端应用程序都需要一个bootstrap.yml(或环境变量),其中包含spring.cloud.config.uri中的服务器地址(默认为“http://localhost:8888")。
如果您使用的是DiscoveryClient实施,例如Spring Cloud Netflix和Eureka Service Discovery或Spring Cloud Consul(Spring Cloud Zookeeper尚不支持),那么您可以根据需要将Config Server注册到Discovery Service, 但在默认的“Config First”模式下,客户端将无法利用注册。
如果您更喜欢使用DiscoveryClient来查找配置服务器,可以通过设置spring.cloud.config.discovery.enabled = true【启动将config client注册到注册中心】(默认为“false”)来实现。 最终结果是客户端应用程序都需要具有适当发现配置的bootstrap.yml(或环境变量)。 例如,使用Spring Cloud Netflix,您需要定义Eureka服务器地址,例如 在eureka.client.serviceUrl.defaultZone中。 使用此选项的价格是启动时额外的网络往返,以查找服务注册。 好处是,只要发现服务名是固定不变的,ip可以随意改变。 默认config server serviceID是“configserver”,但您可以使用spring.cloud.config.discovery.serviceId在客户端上更改它(并且在服务器上以通常的方式为服务更改,例如通过设置spring.application.name)。
列如:
application.properties
发现客户端实现都支持某种元数据映射(例如,对于Eureka,我们有eureka.instance.metadataMap)。 可能需要在其服务注册元数据中配置Config Server的一些其他属性,以便客户端可以正确连接。 如果使用HTTP Basic保护配置服务器,则可以将凭据配置为“用户名”和“密码”。 如果Config Server有上下文路径,您可以设置“configPath”。 例如,对于作为Eureka客户端的配置服务器:
bootstrap.yml.
在某些情况下,如果服务无法连接到配置服务器,则可能需要失败启动服务。 如果这是所需的行为,请设置bootstrap配置属性spring.cloud.config.failFast = true,客户端将以异常停止。
如果您希望应用程序启动时配置服务器偶尔可用,您可以要求它在发生故障后继续尝试。 首先,您需要设置spring.cloud.config.failFast = true,然后您需要在类路径中添加spring-retry和spring-boot-starter-aop。 默认行为是重试6次,初始退避间隔为1000毫秒,指数乘数为1.1,以便后续退避。 您可以使用spring.cloud.config.retry.*配置属性配置这些属性(和其他属性)。
Config Service从/{name}/{profile}/{label}提供属性源,其中客户端应用程序中的默认绑定是
${spring.application.name}
${spring.profiles.active}
(actually Environment.getActiveProfiles()
)所有这些都可以通过设置spring.cloud.config.*来实现(其中*代表“name”,“profile”或“label”)。 “label”对于回滚到先前版本的配置非常有用; 使用默认的Config Server实现,它可以是git标签,分支名称或提交ID。 Label也可以作为逗号分隔列表提供,在这种情况下,列表中的项目将逐个尝试,直到成功为止。 这在处理功能分支时非常有用,例如,当您可能希望将配置标签与分支对齐时,可以将其设置为可选(例如spring.cloud.config.label = myfeature,develop)。
如果您在服务器上使用HTTP Basic安全性,则客户端只需要知道密码(如果不是默认密码,则使用用户名)。 您可以通过配置服务器URI或通过单独的用户名和密码属性来实现,例如
bootstrap.yml.
or
bootstrap.yml.
spring.cloud.config.password和spring.cloud.config.username值覆盖URI中提供的任何内容。
Config Client提供Spring Boot Health Indicator,尝试从Config Server加载配置。 可以通过设置health.config.enabled = false来禁用运行状况指示器。 出于性能原因,还会缓存响应。 生存的默认缓存时间为5分钟。 要更改该值,请设置health.config.time-to-live属性(以毫秒为单位)。
微信公众号:
JAVA程序猿成长之路
分享资源,记录程序猿成长点滴。专注于Java,Spring,SpringBoot,SpringCloud,分布式,微服务。
标签:尺寸 data 最好 完成 分布式 eee login zook ==
原文地址:https://www.cnblogs.com/niugang0920/p/12190217.html