There are already many introductions about the use of Nacos on the Internet, and it is indeed easy to use if it is made in China. There are also a lot about Consul, but they are all integrated with Spring Boot. This article talks about the integration and simple use of Consul and Solon (meaning it is very simple to use).
Speaking of Consul deployment, it is most convenient to use docker-compose. Great for small projects to use:
version: '3' services: consul: image: library/consul container_name: consul volumes: - "./data:/consul/data" - "./config:/consul/config" ports: - 8300:8300 - 8301:8301 - 8301:8301/udp - 8302:8302 - 8302:8302/udp - 8400:8400 - 8500:8500 - 153:53/udp command: "agent -server -bind=0.0.0.0 -client=0.0.0.0 -node=consul_Server1 -bootstrap-expect=1 -ui"
After startup, use "http://localhost:8500" to open (account: admin; password: public), and you will enter the management background.
1. Meet Solon
Solon is an efficient application development framework: faster, smaller, and simpler, and it is also a new Java ecosystem.
Startup is 5 to 10 times faster; qps is 2 to 3 times higher; runtime memory is saved by 1/3 to 1/2; packaging can be reduced to 1/2 to 1/10; and jdk8, jdk11, jdk17, jdk19 are supported at the same time.
Solon project official website: https://solon.noear.org
2. Understanding Solon Cloud Config
Solon Cloud is a set of interface and configuration specifications for distributed (or microservice) development. Among them, Solon Cloud Config is a cloud configuration service, which mainly provides the interface of the distributed configuration service and adapts to the relevant middleware client:
- Adapt to middleware through CloudConfigService interface
- Use CloudClient.config() to obtain an adaptation instance, which supports manual operations
- Generally used through configuration and @CloudConfig annotation
Among them, consul-solon-cloud-plugin is consul's adaptation of solon cloud config. It is also the protagonist of this article.
3. Project integration
3.1. Prepare two configurations in the Consul management background
After installing consul, you need to prepare the configuration data. consul has no concept of namespace or group, but consul-solon-cloud-plugin still supports groups, separated by "/". Create a new "demo/demoapp.yml" configuration (this configuration is used to import into application properties):
demo.user.name: "1"
Then prepare the "demo/demo-ds" configuration (this configuration will be used directly):
demo.ds: url: "" username: "" password: ""
3.2. Create a project and complete the configuration
With Solon Initializr ( https://solon.noear.org/start/ ) to generate a maven + java template project (this is more convenient). Open the project with development tools (IDEA is good, and their company also provides free tools for open source authors. It’s a good company!). Add dependencies in pom.xml:
<dependencies> <dependency> <groupId>org.noear</groupId> <artifactId>consul-solon-cloud-plugin</artifactId> </dependency> </dependencies>
Then, in the application property configuration file "app.yml", add the connection information of consul:
solon.app: name: "demoapp" group: "demo" solon.cloud.consul: server: "127.0.0.1" #consul service address config: load: "demoapp.yml" #Load configuration to application properties (multiple separated by ",")
"…config.load" will import configuration into application properties. Afterwards, it can be injected with "@Inject", and can also be obtained with "Solon.cfg().get(...)".
3.3, code application
In the template project, next to "App.java", add the "Config.java" class:
@Configuration public class Config { //Inject username // from config.load imported into application properties @Inject("${demo.user.name}") String userName; //Inject and convert to data source //directly from "demo/demo-ds" @Bean public DataSource ds(@CloudConfig("demo-ds") HikariDataSource ds){ return ds; } }
Directly obtain the consul configuration, which can be obtained manually through the "@CloudConfig" annotation or "CloudClient.config().pull(group, name)".
4. Application of multiple vest projects
In many cases, companies will have the same code, but different operating items. In this scenario, it is natural to hope that the code does not need to be changed. It can be switched through the "solon.app.group" configuration, does not support namespaces, and can only borrow virtual groups.
4.1. Add new configuration
In consul, add "demo2/demoapp.yml" and "demo2/demo-ds". Then copy the previous configuration.
4.2. Modify project application configuration
- Modify the configuration through app.yml
solon.app: name: "demoapp" group: "demo2" solon.cloud.consul: server: "127.0.0.1" #consul service address config: load: "demoapp.yml" #Load configuration to application properties (multiple separated by ",")
- By specifying at startup (method 2)
java -Dsolon.app.group=demo2 -jar demoapp.jar
- Specified by the environment variable of the container image (method 3)
services: demoapp: image: demo/demoapp:1.0.0 container_name: demoapp environment: - solon.app.group=demo2 - TZ=Asia/Shanghai ports: - 8080:8080
Method two and method three. There is no need to change anything, just specify it when deploying and running, recommended!