Spring Cloud Config (configuration center)
Hello everyone, have not written a technical blog for some time. Because of the work, it is difficult to allocate time. In recent years, with the rise of service, a number of services have emerged as a framework, such as Dubbo,thrift,spring-cloud. There are a lot of companies using Dubbo in China, Dubbo is also a prerequisite for Java programmers to interview, and its official documentation is very clear and understandable, which makes the popularity of Dubbo very easy. Thrift is the Apache contribution, seems to have been popular for some time, small part of this framework is not very understanding. Then Spring-cloud once launched, it is popular in the technology circle, this time small series also in learning Spring-cloud, will learn the things and share with you, if there is wrong place, also please make a lot of corrections.
First, Introduction
Spring Cloud Config provides server and client support for external configurations in distributed systems. With config Server, you can manage its external properties for applications in all environments. It is ideal for spring applications or for use in other language applications. As your application progresses through the deployment process from development to testing and production, you can manage the configuration between these environments and determine everything that your application needs to run when it is migrated. The default implementation of the server storage backend uses git, which makes it easy to support the configuration environment for the label version and access to the various tools for managing content.
Spring Cloud Config Service side features
- HTTP, which provides resource-based APIs (key-value pairs, or equivalent YAML content) for external configurations
- Encryption and decryption of property values (symmetric and asymmetric encryption)
- Very simple embedding in the spring boot application by using the @enableconfigserver.
Config client features (specifically, spring applications)
- Binds the Config service side and initializes the spring environment with a remote property source.
- Encryption and decryption of property values (symmetric and asymmetric encryption)
Getting Started example:
As long as the classpath has spring boot actuator and spring Config client,spring boot application will attempt to connect the configuration service http://localhost : 8888, this address is the default address for Spring.cloud.config.uri. If you want to change this address, you can do it in bootstrap. Set Spring.cloud.config.uri in [Yml or properties] or through system properties or through environment variables.
@Configuration @enableautoconfiguration@restcontrollerpublic class Application { @Value ("${config.name}") String name = "World"; @RequestMapping ("/") Public String Home () { return "Hello" + Name; } public static void Main (string[] args) { springapplication.run (application.class, args);} }
The config.name in the example above can be either from a local configuration file or from a remote Configuration service. By default, the remote Configuration service will be used first.
In order to run your own Configuration service center, you can use Spring-cloud-config-server dependencies, and @enableconfigserver annotations. If you set up Spring.config.name=configserver, the app will run on port 8888 and provide data from a sample warehouse. You need to set Spring.cloud.config.server.git.uri to specify your own configuration data. By default, it is a git repository and can also be configured for cost-effective file systems.
Second, Spring Cloud config server
The server provides resource-based HTTP for external configurations (key-value pairs or equivalent yaml content). It can be embedded in the Spring boot app using @enableconfigserver. Examples are as follows:
@SpringBootApplication @enableconfigserverpublic class Springcloudconfigserverapplication {public static void main ( String[] args) {Springapplication.run (springcloudconfigserverapplication.class, args);}}
Like all spring boot apps, it runs on port 8080 by default, and you can switch it to 8888 ports in a variety of ways. The simplest can be set Spring.config.name=configserver (the jar Package in config server has a configserver.yml), which sets a default configuration repository. Another way to do this is to use your own application.properties, which is also the recommended way to make a small recommendation:
Server.port:8888spring.cloud.config.server.git.uri:git Address
The git address is your Yaml or properties file.
Environment Warehouse
Where do you want to store configuration data? The strategy to support this behavior is environmentrepository, which serves the environment instance. This environment is a shallow copy of spring environment. The environment is parameterized by 3 variables.
- {Application} maps the client's "Spring.application.name"
- {Profile} Maps client's "spring.profiles.active" (comma separated list)
- {label} It is a service-side feature that marks a set of configuration files for a version
The implementation of the warehouse typically behaves like the spring boot load configuration file, "Spring.config.name" equals the {application} parameter, and "spring.profiles.active" equals the {profile} parameter. Profiles's precedence rules are the same as normal rules, and the profiles of activities is better than the default. If there are multiple profiles, the last one wins.
Configuration instances for the client:
Spring: application: name:foo profiles: active:dev,mysql
In the spring boot application, these parameters can also be set through environment variables or command line parameters.
Git back end
The default implementation of Environmentrepository is to use the Git backend, which is very handy for managing updates, physical environments, and audit changes. To change the address of the warehouse, you can set the "Spring.cloud.config.server.git.uri" property (in the Application.properties file) on the configuration server. If you set it up with the file: Start, it will run from the local repository so that it can be started very quickly and easily without a server. In this case, the server will run directly in the local repository. In order to extend the configuration service and make it highly available, you need to point all instances of the service to the same warehouse, so only the shared file system can work. Even in this case, it is best to use the SSH: protocol of the shared file system repository so that the server can clone it and use the local working copy as the cache.
The implementation of the warehouse maps the {label} parameter in the HTTP resource to the GIT tag (commit ID, branch name, or tag). If the Git branch or tag name contains "/", the label in the HTTP URL is replaced with a special character "(_)". For example, if the name of the branch is Foo/bar, the format of the label in HTTP is foo (_) bar. This special character can also be used in the {application} parameter.
Placeholders in the Git URI
Spring Cloud Config Server supports the use of placeholders in Git URLs, using {application} and {profile} (if you use {label}, remember that it is used in the git tag). So you can easily support the principle of "one application, one warehouse". As follows:
Spring: Cloud: config: server: git: uri:https://github.com/myorg/{application}
or an environment a warehouse principle, use {profile} instead of {application}. You can also use the special character "(_)" in the {application} parameter to support multiple organizations.
Spring: Cloud: config: server: git: uri:https://github.com/{application}
The {application} parameter is in the format "organization (_) application".
Pattern matching and multi-warehouse
Using pattern matching in {application} and {profile} parameters can support more complex requirements. The format of the pattern is a comma-delimited set of {application}/{profile}, where the arguments can use wildcards. For example:
Spring: Cloud: config: server: git: uri:https://github.com/spring-cloud-samples/ Config-repo repos: simple:https://github.com/simple/config-repo Special: pattern:special*/dev* , *special*/dev* uri:https://github.com/special/config-repo Local: pattern:local* Uri:file :/home/configsvc/config-repo
If {application}/{profile} does not match to any pattern, it will use the default warehouse address: Spring.cloud.config.server.git.uri. In the example above, the "simple" warehouse matches "simple/*" (it only matches a single warehouse, in all environments). The "local" warehouse will match all {application} names beginning with "local" and also in all environments. The "/*" prefix is automatically added to all schemas that do not have the {profile} set.
Each warehouse can also store configuration files under subdirectories, pattern matching can also be used to search for these directories, and searchpaths should be developed as follows:
Spring: Cloud: config: server: git: uri:https://github.com/spring-cloud-samples/ Config-repo searchpaths:foo,bar*
In the example above, the configuration file will be searched in Foo and the directory starting with bar.
By default, the server clones the remote repository the first time the configuration file is requested, and the server can be configured to clone the repository when it is started, as follows:
Spring: Cloud: config: server: git: uri:https://git/common/config-repo.git Repos: Team-a: pattern:team-a-* cloneonstart:true uri:http://git/team-a/config-repo.git team-b: pattern:team-b-* cloneonstart:false uri:http://git/team-b/config-repo.git team-c: pattern:team-c-* Uri:http://git/team-a/config-repo.git
In the example above, the TEAM-A repository will be cloned at the start of the server, and the other repositories will be cloned on the first request.
Certification
If the remote Git repository requires a user name and password, you can refer to the following example
Spring: Cloud: config: server: git: uri:https://github.com/spring-cloud-samples/ Config-repo Username:trolley Password:strongpassword
In this case, Spring Cloud Config server is introduced here, there are some less commonly used features are not introduced here, you can refer to the Spring Cloud website. The sample code for the Spring Cloud config server can be referenced in my github address: https://github.com/bigbugliu/spring-cloud-config-server.
Third, Spring Cloud Config Client
The spring boot app can immediately use spring Config Server. As long as there is a jar package for spring Cloud Config client in Classpath, the application will request the configured server. He will initialize the spring environment with the properties of the bound configuration server (configured in Spring.cloud.config.uri).
In some cases, you may want to start a service failure if the service cannot connect to the configuration server. If this is the desired behavior, set the boot configuration properties spring.cloud.config.failFast=true
and the client will stop with an exception.
If you want the configuration server to be unavailable occasionally when your application starts, you can ask it to continue trying after a failure occurs. First, you need to set up spring.cloud.config.failfast=true, and then you need to add spring-retry and SPRING-BOOT-STARTER-AOP to your classpath. The default behavior is to retry 6 times, with an initial backoff interval of 1000ms and an exponential multiplier of 1.1 for subsequent backoff. You can configure these properties (and others) using the Spring.cloud.config.retry.* configuration properties.
Please refer to my Github:https://github.com/bigbugliu/spring-boot-demo for detailed code.
Spring Cloud config is finished, and you are welcome to discuss it in the comments section.
Spring Cloud--config (Configuration Center)