Nacos profile

Nacos is based on Java and is named Name Configurations, where Na, Co, and S are used to form Nacos. Named configuration. Name is Name Server, indicating the naming service. Configurations Is called a Configurations Server, which configures the service.

You can see that Nacos mainly provides two functions: service registration and service configuration management. Name Server replaces Consul, and Configurations Server replaces Spring Cloud Config + Spring Cloud Bus.

Nacos installation

  1. Environment to prepare

    • The 64-bit OPERATING system supports Linux, Unix, Mac, and Windows. Linux is recommended.
    • JDK 1.8 or above.
    • Maven 3.2.x above.

  2. Download: github.com/alibaba/nac…

  3. Nacos directory

    • Bin: script directory to start the Nacos directory
    • Conf: Nacos configuration file directory
    • Target: indicates the dependency directory of Nacos
    • Data: Nacos Directory for saving data after successful startup

  4. Start a single node of Nacos

    Nacos starts in cluster mode by default, and in a small project you can set it up to run in standalone mode. Add -m standalone in the command.

    Linux/Unix/Mac OS boot: In the nacOS /bin directory

    ./startup.sh -m standalone
Copy the code

    Windows startup: In the nacos/bin directory

    startup.cmd -m standalone
Copy the code

  5. Nacos Default port: 8848

  6. Visit Nacos console: http://localhost:8848/nacos/ (default user name and password are Nacos)

    If access to the console is blank, clear the browser cache.

Nacos client development

  1. Introduce dependencies in the client pom.xml

    <! -- Nacos Registry client -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<! -- Nacos Configuration Center client -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency> 
Copy the code

  2. The client adds the bootstrap class annotation

    @SpringBootApplication
// Spring Cloud native annotations, enable service registration and discovery, optionally added
@EnableDiscoveryClient
public class ClientApplication {

    public static void main(String[] args) { SpringApplication.run(ClientApplication.class, args); }}Copy the code

  3. The Nacos console determines a Namespace for the configuration file, if not required (the default Namespace is used in this article).

  4. Create the configuration file client-dev.yml in a Namespace precreated by the console

    server:
  port: 9000

spring:
  cloud:
    # Nacos configuration
    nacos:
      discovery:
        Register the client into the Nacos Server registry
        server-addr: ${spring.cloud.nacos.server-addr}
Copy the code

  5. Client bootstrap.yml configuration

    The purpose of local configuration is to locate the configuration file corresponding to the remote configuration center before service startup. Therefore, the Namespace, Group, and Data ID are configured locally to locate the configuration file.

    In Spring Cloud Alibaba, it is recommended to put the local configuration in bootstrap.yml, although it is possible to put it in application.yml.

    spring:
  # Data ID: prefix
  application:
    name: client
  # Data ID: environment
  profiles:
    active: dev
  cloud:
    nacos:
      # Nacos Server address
      server-addr: localhost:8848
      Nacos Server configuration center configuration
      config:
        When the service starts, go to the Nacos Server configuration center and pull the configuration
        server-addr: ${spring.cloud.nacos.server-addr}
        The default namespace is Public, which can be omitted. If you create a new namespace, you need to use the namespace ID, not the name
        namespace: Public
        The default group is DEFAULT_GROUP. If the namespace is Public, omit the group configuration
        group: DEFAULT_GROUP
        # Data ID: suffix
        file-extension: yaml
Copy the code

  6. Successful Registration service

    If the service is not registered, check the client’s porn.xml to see if web dependencies are introduced, or try restarting the Nacos service.

    <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
Copy the code

Nacos Configures central functions

In the Spring Cloud configuration center solution implemented above, Spring Cloud Config, Spring Cloud Bus and GitHub are integrated to realize automatic refreshing of configuration center and configuration. GitHub serves as a remote repository for configuration, and Spring Cloud Config serves as an independent configuration management Server to manage local configuration. Meanwhile, Webhock pulls configuration files from the remote repository to realize configuration refresh. Finally, each microservice implementation configuration is loaded via the message Bus Spring Cloud Bus broadcast.

The Nacos component provided in Spring Cloud Alibaba implements the function of configuration center, which no longer relies on remote repositories such as GitHub to store configuration files, but directly resides on the Nacos Server. Instead of relying on Spring Cloud Bus and messaging middleware (RabbitMQ) to update the configuration, when the configuration file on the Nacos Server is changed, it is automatically broadcast to each micro-service, thus eliminating the need to create a separate Config service.

Automatic refresh of configurations

Add the @refreshScope annotation to the Controller class

 @RestController
 // Refresh the configuration automatically
 @RefreshScope
 public class TestController {

     @Value("${user.name}")
     private String username;

     @GetMapping("/test")
     public String test(a) {
         System.out.println(username);
         returnusername; }}Copy the code

The namespace

Because Nacos stores the configuration files for all microservices, if there are two microservice projects with the user service, there must be two user.yaml, which will inevitably cause file conflicts. So Nacos provides a namespace, giving each project a separate namespace that holds only all the configuration files for that project. The default namespace provided by Nacos is public. This namespace cannot be edited, cannot be deleted, and can only be viewed. All configuration files that do not specify a namespace are stored in the public namespace.

The idea of namespaces follows from the Previous Spring Cloud solution, where different repositories are created on GitHub to store different project configuration files.

Creating a Namespace

Each namespace has a unique ID. You are advised to leave the first box blank and automatically generate the ID.

The recommended namespace name is In English.

Adding a Single Configuration

Data ID format: ${prefix}-${spring.profiles.active}.${file-extension}

  • Prefix: prefix, the default for the service name, the default is the bootstrap yml in spring. The application. The name, but can be by spring. Cloud. Nacos. Config. The prefix to specify a prefix.
  • Spring.profiles. Active: environment, which can be dev, prod, or test
  • 14. file-extension: file extension name, currently supported only yamL, properties (must correspond to the configuration selected below)

If spring.profiles.active is not configured, the Data ID format is ${prefix}.${file-extension}.

If file-extension is YML, the file suffix must be yaml and the configuration format must be YAML. After Nacos1.4, yml must be written in the configuration file.

Group: the default DEAFAULT_GROUP, generally divided by environment DEV, PROD, test (if there is no such Group will be directly created).

Description: Indicates the description of the configuration file.

Configuration format: Must be the same as file-extension above.

Namespace, Group, and Data IDS can be assigned to any configuration file, similar to how Maven locates Jar packages.

Import/Export Configuration

Import configuration:

The imported configuration must be a ZIP package.

Export configuration:

Normally, the exported file is a compressed package with a zip suffix. If the exported file does not have a zip suffix, you can import the file with a zip suffix (Chrome only).

Cloning configuration

Clone configuration is to copy the configuration file to another Namespace. You can change the Group and Data ID.

Version history

Because configuration files are often modified, Nacos also uses a similar way to Git to record each version change, which is convenient for version rollback.

Listening to the query

You can listen on configuration files. Among them, MD5 is the best way to sign. If the contents of two configuration files are the same, then MD5 is the same. MD5 is different if there is a single character difference between configuration files. Therefore, when Nacos determines whether the configuration file is updated, it determines whether the MD5 values after two modifications are consistent. When Nacos determines that the profile has changed in content, it immediately pushes the corresponding microservice.