This article REVIEW:
- Spring Cloud Config basic concepts
- Spring Cloud Config client loading process
- Spring Cloud Config message based bus configuration
- Spring Cloud Config placeholder
- Spring Cloud Config Warehouse Best Practices
- Spring Cloud Config health check problem analysis
This paper describes the basic concepts of Spring Cloud Config, practiced configuration and analyze the problems encountered. On how to start running the Configuration Center can refer to the official Demo.
Spring Cloud version used herein: Edgware.SR3
Spring Cloud Config basic concepts
Spring Cloud Config is used for infrastructure and service applications provide centralized micro external distributed system configuration support.
- Server: a distributed configuration center, independent micro-service applications, configuration used to connect the warehouse (GIT) and provides the client configuration information, encryption / decryption access interface. ,
- Client: micro-services architecture of each micro-service applications and infrastructure, acquisition and start-load configuration information from the configuration center by specifying configuration management application resource center and business-related configuration content
SCC effect:
To achieve the abstract mapping server and client environment variables and configuration properties.
SCC advantages:
The default configuration information is stored using GIT, native support for version management configuration information.
Spring Cloud Config Chart:
FIG message bus-based architecture:
As shown above, several key elements of the architecture of Figure role:
Remote GIT repository:
Place to store configuration files.
Config Server:
Distributed configuration center, micro-specified service account password and other information on the location and connection of the warehouse.
Local GIT repository:
In the Config Server file system, each time the customer orders for configuration information, Config Server GIT repository to get the latest configuration from local, then read and return to the local GIT repository request. When the remote repository can not be obtained, returned directly to the local repository content.
ServerA/B：
Specific micro-service applications, they specify the Config Server address, in order to achieve an external configuration information of the application you want. Will initiate a request for configuration information to the Config Server is loaded when the application starts.
Message Center:
Said second message-based approach is a schematic diagram of the bus, dependent on external MQ component, currently supports Kafka, Rabbitmq. Config Server provided by the distribution center / bus / refresh endpoint sends a message as a producer, the client receives a message from the pull configuration Config Server via an interface in the form of http.
Service Registry:
Config Server can be registered to the service registry, such as Eureka, then the client finds Config Server service list by service registry, select Config Server to a complete medical examination and obtain the remote configuration information.
Spring Cloud Config client loading process
The client application obtains configuration execution flow from the Configuration Management:
1) when the application starts, depending on the application name bootstrap.yml configured {application}, context name {profile}, branch name {label}, to the Config Server request for configuration information.
2) Config Server according to GIT repository information with customers to maintain their own terminal configuration pass over positioning to find the configuration information.
3) by git clone command you will find the configuration is downloaded to Config Server file system (local GIT repository)
4) Config Server to create a Spring ApplicationContext instance and load the configuration file from a local GIT repository, and finally reads the configuration content back to the client application.
5) after obtaining the client application is loaded into the contents of an external configuration example ApplicationContext client, a higher priority than the contents of the configuration Jar client configuration package contents inside, so repeated in Jar package contents will not be loaded.
Spring Cloud Config message based bus configuration
Config Server as a configuration center pom.xml introduced:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bus-kafka</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>Config Server configuration file (yml format):
server:
port: ${CONFIG_SERVER_PORT:8021}
spring:
application:
name: letv-mas-config
# 配置了该项，访问/bus/refresh?destination=应用名:spring.application.index，如果未指定spring.application.index默认使用「应用名:server.port」
index: ${CONFIG_SERVER_IP:127.0.0.1}
cloud:
config:
server:
git:
# 基于 http 协议的单仓库，每一个应用创建一个目录，每个目录下创建配置文件
uri: ${GIT_URI:http://xxxx/config.git}
search-paths: '{application}'
# 配置的 Git 仓库基于 http 协议的，必须配置用户名和密码
username: ${GIT_USERNAME:config_server}
password: ${GIT_PASSWORD:config@123}
# 本地仓库目录设定
basedir: /letv/app/mas/config/repos
# 本地仓库如果有脏数据，则会强制拉取（默认是false）
force-pull: true
# 配置中心启动后从 GIT 仓库下载，如果uri配置中使用了 {application} 作为仓库名，这里要使用默认值false，否则启动报错.
clone-on-start: false
management:
security:
enabled: false
# 用户认证，客户端应用接入时加入安全认证配置
security:
user:
name: config
password: config2018
basic:
enabled: true
# 基于消息总线的 MQ 配置
spring:
cloud:
stream:
kafka:
binder:
zk-nodes: ${ZK_NODES:localhost:2181}
brokers: ${KAFKA_BROKERS:localhost:9092}
requiredAcks: -1
configuration:
security:
protocol: SASL_PLAINTEXT
sasl:
mechanism: PLAIN
jaas:
loginModule: org.apache.kafka.common.security.plain.PlainLoginModule
options:
username: test
password: test-secret
# 开启跟踪事件消息（默认是false）
bus:
trace:
enabled: true
# 自定义 topic 主题
destination: test.springcloud.configConfig Client as a client pom.xml introduced:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bus-kafka</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>Config Client Profile (yml format):
spring:
application:
name: letv-mas-client
index: ${CLIENT_SERVER_IP:127.0.0.1}:${server.port}
profiles:
active: ${CLIENT_PROFILE:default}
#include: busdev,streamdev
cloud:
config:
uri: ${CONFIG_SERVER_DOMAIN:http://config.xxx.cn/}
failFast: true #the client will halt with an Exception
enabled: true
# boostrap.yml 配置优先于启动参数变量 spring.profiles.active
profile: ${spring.profiles.active:${CLIENT_PROFILE:default}}
label: master
# 访问配置中心，用户安全认证
username: config
password: config2018
# 激活定时任务，当 GIT 版本发生变更后加载最新配置上下文
watcher:
enabled: true
security:
user:
name: config
password: config2018
# 基于消息总线的 MQ 配置( Kakfa 队列)，如果zipkin中也使用 Kafka 队列，那么需要通过binder 形式配置做隔离，否则会互相影响，无法下发配置消息。
spring:
cloud:
stream:
# 自定义开关
enabled: true
# 指定中间件
default-binder: config-kafka
binders:
config-kafka:
type: kafka
environment:
spring:
cloud:
stream:
kafka:
binder:
zkNodes: ${ZK_NODES:localhost:2181}
brokers: ${KAFKA_BROKERS:localhost:9092}
# 生产者确认，0、1、-1，默认为1。0为不确认，1为leader单确认，-1为同步副本确认。-1的情况下消息可靠性更高。
required-acks: -1
# 是否自动创建topic，默认为true。设为false的情况下，依赖手动配置broker相关topic>配置，如果topic不存在binder则无法启动。
auto-create-topics: true
configuration:
security:
protocol: SASL_PLAINTEXT
sasl:
mechanism: PLAIN
jaas:
loginModule: org.apache.kafka.common.security.plain.PlainLoginModule
options:
username: test
password: test-secret
bus:
# 是否启用bus
enabled: true
# Bus 使用的队列或 Topic，Kafka 中的 topic，Rabbitmq 中的 queue
destination: test.springcloud.config
trace:
# 是否启用 Bus 事件跟踪，可以通过 /trace 页面查看
enabled: true
refresh:
# 是否发送 refresh 事件，开启时支持基于 config 文件变更的动态配置
enabled: true
env:
# 是否开启 env 事件，开启时支持直接动态配置相应环境变量，如 /bus/env?arg1=value1&arg2=value2
enabled: trueSpring Cloud Config placeholder
Placeholder used:
Here {application} represent the name of the application, when the client to get the configuration Config Server initiated request, Config Server will be filled {application} placeholder to locate the resource configuration storage location information of the client according spring.application.name.
Note: {label} parameter is very special, if GIT branches and tags that contain "/", then {label} parameters are applied in the HTTP URL used "(_)" Alternatively, to avoid changing the URI meaning, pointing to another URI of the resource .
Why should there be a placeholder?
When using GIT as a distribution center to store configuration files for individual micro-service applications, the use of placeholders URI can help us to plan and implement a common warehouse configuration.
Spring Cloud Config Warehouse Best Practices
Local repository:
the Spring of Cloud D, E to the version stored in the default / var / folders / ml / 9rww8x69519fwqlwlt5jrx700000gq / T / config-repo-2486127823875015066 directory.
In version B not actually tested, stored in the temporary directory / tmp / config-repo- random number directory.
In order to avoid some unpredictable problems, we set a fixed local GIT repository directory.
By spring.cloud.config.server.git.basedir=${user.home}/local-config-repoif the directory $ {user.home} found that local-config-repo does not exist, it will be created automatically after the Config Server to start, and from a remote GIT repository to download the configuration stored in this location.
Remote Storage Practices:
single repository directory:
Each project corresponds to a warehouse
spring.cloud.config.server.git.uri=https://gitee.com/ldwds/{application}
Multi-warehouse directory:
under the same warehouse, a directory for each project
spring.cloud.config.server.git.uri=https://gitee.com/ldwds/config-repo-demo.git
spring.cloud.config.server.git.search-paths='{application}'
1) single repository directory Note:
spring.cloud.config.server.git.uri=[https://gitee.com/ldwds/config-repo-demo/](https://gitee.com/ldwds/config-repo-demo/)
spring.cloud.config.serversearch-paths:’{application}'Former client application startup, create a subdirectory, the subdirectory name is spring.application.name application name specified in the configuration in the config-repo-demo warehouse.
Otherwise, the project referenced property is not found, an error will be reported as follows:
Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder 'from' in value "${from}"
2) multi-warehouse directory Note:
in this way can not set parameters
spring.cloud.config.server.git.force-pull=trueand spring.cloud.config.server.git.clone-on-start=true
otherwise will start being given, is also well understood because of the use of {applicatoin} as a placeholder, did not specify the specific name of the warehouse, you can not force pull a remote repository configuration .
If you set up a local repository directory such as spring.cloud.config.server.git.basedir=/data/config-repos/local-config-repothe Config Server starts automatically create / data / config-repos directory, and create a config-repo- random number list named warehouse, warehouse contents of this comes from the default warehouse health check app.
After the client application starts, according to the warehouse to find the {application} application name, Config Server from match to clone a Git repository and directory under config-repo- random numbers.
If the Config Server restart, the client application through / bus / refresh refresh configuration, because there is no repository name prior to the cache, it will automatically create a repository directory config-repo- random numbers and data from the Git clone.
If the Config Server has a local warehouse, reboot or client / bus / refresh refresh configuration the Config Server does not re-establish a new warehouse.
The implementation of the principle of local distribution center warehouse:
local warehouse according to whether there is under basedir .git directory contains a hidden file. If the local depot does not exist, from the distal end of the data warehouse to the local clone; if there is a local warehouse, warehouse fetch the latest data from the remote to the local; then checkout to specify the label, merge data from a remote warehouse, and get the latest branch of the current label the HEAD version, and the default application name app return as environmental information.
Spring Cloud Config health check problem analysis
Health Check pom.xml introduced:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-actuator</artifactId>
</dependency>After adding the dependency on by default health checks. If no health check, you can spring.cloud.config.server.health.enabled=falseclose the parameter setting.
If the configuration is: spring.cloud.config.server.git.uri=[https://gitee.com/ldwds/config-repo-demo.git](https://gitee.com/ldwds/config-repo-demo.git)
enabled by default health checks, I began to think that the default name for the application checks app, profiles as default, label is null monitor (see source code).
But under the GIT repository configuration app does not apply, then visit / health, monitor status is still UP?
{
"status": "UP"
}This understanding is wrong, reasons as follows:
The main distribution center with the address specified GIT repository has a relationship, if the warehouse specified address is https://gitee.com/ldwds/ {application}, {application} check the monitor will replaced by a default application name app as a warehouse address in this case created config-repo- random number as a local repository application {application} {user.home} in a directory (such as: / Users / liudewei1228 / config- repo-7949870192520306956).
Even if the set
spring.config.server.git.basedir=${user.home}/local-config-repo/will not be used to.
why? Because the {application} as a warehouse, is a dynamic, there may be multiple {application} warehouse project, so it will not use a specific directory basedir as a local warehouse.
The following parameters set the configuration health check:
spring.cloud.config.server.health.repositories.config-repo-demo.name=应用名
spring.cloud.config.server.health.repositories.config-repo-demo.label=分支
spring.cloud.config.server.health.repositories.config-repo-demo.profiles=环境变量Find environmental status information is displayed UP, DOWN this procedure any abnormal state (such as a warehouse can not find NoSuchRespositoryException) will be displayed.
Uri contains {application} in the warehouse as the next case, the client application needs to create good spring.application.name = config-client application name as a warehouse in advance before the opening, otherwise it will cause can not be enabled. (Because the {application} project is considered to be a warehouse, not a directory).
Source See: doHealthCheck method of ConfigServerHealthIndicator.java.
Configured correctly warehouse name, label, profiles, access / health interface displays sources, sources in this address can not be accessed, but the actual effect of a logo.
Access / health results:
{
"status": "UP",
"repositories": [
{
"sources": [
"https://gitee.com/ldwds/config-repo-demo/config-client/config-client.properties";
],
"name": "config-client",
"profiles": [
"default"
],
"label": "master"
}
]
}
Otherwise, the information can not find the designated warehouse, only the following information is displayed:
{
"status": "UP",
"repositories": [
{
"name": "config-client",
"profiles": [
"default"
],
"label": "master"
}
]
}The latest Spring Cloud Config improved a lot of problems, we can combine the official website to learn more understanding.
In this paper, the basic concepts of Spring Cloud Config (Spring Cloud E version) based configuration uses message bus, warehouse catalog practice, practice and practice problems encountered in health examination were analyzed, we want to use this configuration center of friend they help.
When the current selection of micro-service architecture, it is recommended to use domestic open source configuration center: Apollo distribution center (Ctrip open source), Nacos Registration & Configuration Center (Ali Baba open source).
I welcome the attention of the public number, scan code concerned, unlock more exciting articles, grow with you ~
