This article has been included github.com/lkxiaolou/l… Welcome to star.

Configuration center

Dynamic configuration centers may be used for business configuration, functional switches, degradation of weak dependencies in service governance, and even database passwords.

In the absence of a dedicated configuration central component, we use hard coding, or configuration files, or databases, caches, etc.

Hardcoded configuration changes require recompilation and packaging, configuration files need to restart the application, the database is limited by performance, and the cache loses timeliness.

They may not be perfect, but they can summarize the requirements of the configuration center relatively clearly:

  • Ability to store, retrieve, and listen to configurations (required)
  • Prompt push of configuration changes to listeners (required)
  • Have a visual console to view configuration changes (required)
  • Configuration changes can be implemented in gray scale (bonus points)
  • Rolling back configuration changes (bonus points)

At present, the most used configuration center may be Apollo with open source program, Spring Cloud Config, Ali open source Nacos, Baidu Disconf and so on.

Nacos configuration center

Nacos is an abbreviation of Naming and Configuration Service, and its two major areas are Naming registry and Configuration Center.

This article explains the architecture design and implementation principle of the configuration center of NACOS, based on 2.0.0 (note: 2.0.0 is different from 1.x).

Setup of Nacos debugging environment

  • Clone code from Github (slow connection speed, add –depth=1)
git clone --depth=1 https://github.com/alibaba/nacos.git
Copy the code
  • Import IDE, look at the code, debugging more convenient
  • Start the Server: Run nacos.main () in the console module. This class scans the widest path and can start all modules

    • The JVM parameter can be set to -dnacos. standalone=true -dnacos. functionMode=config to specify standalone mode and start only the config module

    • –spring.config.additional-location=nacos/distribution/conf

    • After normal startup, the console prints the ADDRESS of the Ncos console and enters the Nacos console. Enter the user name and password (the default is Nacos) to log in

  • Client is used for testing. ConfigExample is provided under the Example module to test config. In order to keep the source code intact, you can copy a copy of configExample to modify the test

Nacos configuration model

Namespace + Group + dataId uniquely determines a configuration

  • Namespace: Binds to clients. Each Clinet corresponds to a namespace, which can be used to isolate the environment or distinguish tenants
  • Group: groups services
  • DataId: indicates the configured ID

Client startup process

  • If the NACOS server address is configured during parameter preparation, use it directly. If an endpoint is configured, you can obtain the NACOS server address from the endpoint. In this way, you do not need to restart the client when the server address is changedhttps://nacos.io/en-us/blog/namespace-endpoint-best-practices.html
  • The GRPC connection is created when the client interacts with the server for the first time, and a server is randomly selected to establish the connection. This connection is used in the subsequent years. Retry will be performed if the request fails, and the request level is limited. If the retry fails or the server is disconnected, a new server is selected to establish a link

Request model

From the PROto file of gRPC, we can see that the definition of request and return is relatively uniform

message Metadata {
  string type = 3;
  string clientIp = 8;
  map<string, string> headers = 7;
}

message Payload {
  Metadata metadata = 2;
  google.protobuf.Any body = 3;
}

service Request {
  // Sends a commonRequest
  rpc request (Payload) returns (Payload) {
  }
}
Copy the code
  • Type is the class name of the request/return class
  • ClientIp is the clientIp address
  • Headers is the header information carried
  • The body in Playload is encoded in JSON format

In com. Alibaba. Nacos. API. Config. All configuration can be found in the ConfigService center can use interface

Focus on these interfaces:

  • GetConfig: Reads the configuration
  • PublishConfig: Publish configuration
  • PublishConfigCas: atomic publish configuration that fails if it is changed by another thread, similar to CAS in Java
  • RemoveConfig: Deletes the configuration
  • AddListener: Listens for configuration
  • RemoveListener: Removes the configured listener

Changes to push

The combination of push and pull ensures timeliness and data consistency

Data is stored

The data store in the Nacos configuration center supports the embedded Derby database as well as the external mysql database, which is mainly used for stand-alone testing.

Update ${table} set ${xx}=${zz} where md5=${old_md5} update ${table} set ${xx}=${zz} where md5=${old_md5}

Grayscale and rollback

When gray scale publishing is selected, the IP of gray scale can be filled in for push, and the IP not in the gray scale list will not receive change push, and gray scale and formal are separated.

Grayscale implementation is a record of each release, roll back to the specified version.

conclusion

Starting from the background, this paper explains each important module of the Nacos configuration center one by one, so as to have a grasp of the configuration center of Nacos as a whole. The Nacos registry is expected to be analyzed and introduced in the future.

Search attention wechat public number “bug catching master”, back-end technology sharing, architecture design, performance optimization, source code reading, problem solving, practice.