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!