background
After SpringBoot references the Apollo (Apollo) distributed configuration management center, the service startup speed in Docker slows down. It only takes 20 seconds to start at the beginning, and it takes two minutes to start after adding the configuration. How much time is wasted every time a service is deployed, and why? How to solve it?
reason
By analyzing the logs, every time you start the service, you need to pull the configuration from the Apollo service and then process it for more than one minute, resulting in a long overall time
The log is as follows
[main] INFO c.c.f.f.i.p.DefaultServerProvider -Environment is set to null. Because it is not available in either (1) JVM system property 'env', (2) OS env variable 'ENV' nor (3) property 'env' from the properties InputStream.
[main] WARN c.c.f.a.i.DefaultMetaServerProvider -Could not find meta server address, because it is not available in neither (1) JVM system property 'apollo.meta', (2) OS env variable 'APOLLO_META' (3) property 'apollo.meta' from server.properties nor (4) property 'apollo.meta' from app.properties
[main] WARN c.c.f.apollo.core.MetaDomainConsts -Meta server address fallback to http://apollo.meta for env UNKNOWN, because it is not available in all MetaServerProviders
Started App in 114.872 seconds (JVM running for 118.52)
Pull process:
solve
Start the local mode and use the mount to make the configuration file accessed by the service in the container exist.
Step 1. Add the startup parameter -Denv=local
example
java -Denv=local -jar xxx.jar
Step 2. Ensure that the configuration file has been pulled and is up to date
Configure the default path
Mac/Linux: /opt/data/{appId}/config-cache
Windows: C:\opt\data{appId}\config-cache
Local mode startup log:
[main] INFO c.c.f.f.i.p.DefaultServerProvider -Loading opt\settings\server.properties
[main] INFO c.c.f.f.i.p.DefaultServerProvider -Environment is set to [local] by JVM system property 'env'.
[TID: N/A] [main] WARN c.c.f.a.spi.DefaultConfigFactory -==== Apollo is in local mode! Won't pull configs from remote server for namespace ! ====
Official website address:
https://www.apolloconfig.com/#/zh/usage/java-sdk-user-guide
small expansion
Apollo
Apollo (Apollo) is a reliable distributed configuration management center, which was born in the Ctrip Framework R&D Department. It can centrally manage the configuration of different environments and different clusters of applications. After the configuration is modified, it can be pushed to the application side in real time, and has a standardized Features such as permissions and process governance are suitable for microservice configuration management scenarios.
The server is developed based on Spring Boot and Spring Cloud, and can be run directly after packaging without additional installation of application containers such as Tomcat.
The Java client does not depend on any framework, can run in all Java runtime environments, and also has good support for Spring/Spring Boot environments.
The .Net client does not depend on any framework and can run on all .Net runtime environments.
Spring Cloud Config
In Spring Cloud, there is a distributed configuration center component spring cloud config, which supports configuration services in memory of configuration services (that is, local), and also supports placement in remote Git warehouses.
In the spring cloud config component, there are two roles, one is config server and the other is config client.
Config Server is a horizontally scalable and centralized configuration server. It is used to centrally manage configurations in various environments of applications. By default, Git is used to store configuration file content, and SVN storage or local file storage can also be used.
Config Client is the client of Config Server, used to operate the configuration content stored in Config Server.
When the microservice starts, it will request the Config Server to obtain the content of the configuration file, and then start the container after the request is received.
Nacos
Official website address:
https://nacos.io/zh-cn/docs/v2/what-is-nacos.html
Nacos /nɑ:kəʊs/ is the acronym for Dynamic Naming and Configuration Service, which is easier to build cloud-native applications A dynamic service discovery, configuration management, and service management platform.
Service registration discovery and service health detection
Dynamic configuration service
Dynamic DNS service
Service and metadata management
Through the introduction of the above popular configuration centers, it is recommended to use nacos.
What is your configuration center using?
Like , collect and follow