The principle Seata Configuration Center

Seata can support multiple third party distribution center, then Seata how compatible you more configuration center of it? Now I give you details of implementation principle Seata distribution center under.

Configuration Center property loaded

In Seata distribution center, there are two default configuration file:

file.conf is the default configuration properties, third-party registration information registry.conf main storage center and distribution center, there are two blocks:

registry {
  # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
  # ...
}

config {
  # file、nacos 、apollo、zk、consul、etcd3
  type = "file"
  nacos {
    serverAddr = "localhost"
    namespace = ""
  }
  file {
    name = "file.conf"
  }
  # ...
}复制代码

Where the registry is a configuration property registry, here do not speak first, config is the configuration center of the property value, default file type, which loads the local file.conf inside the property, if the type is another type, it will from a third party load distribution center configuration attribute value.

In the core directory config module, there is a factory class ConfigurationFactory configuration, its structure is as follows:

We can see some constants are static configuration:

REGISTRY CONF PREFIX, REGISTRY CONF SUFFIX: profile name, the default configuration file type;

The SYSTEM PROPERTY SEATA CONFIG NAME, ENV SEATA CONFIG NAME, ENV the SYSTEM KEY, ENV PROPERTY_KEY: Custom configuration variable file names, file also shows that we can attribute to customize the configuration center.

ConfigurationFactory there are a static block of code, as follows:

io.seata.config.ConfigurationFactory

According to the custom configuration variable file name to identify the profile name and type, if not configured by default to use registry.conf, FileConfiguration is Seata default configuration implementation class, if the default value, registry.conf profile will generate more FileConfiguration the default configuration object, where you can also use SPI configuration mechanisms to support third-party extensions to achieve the specific implementation is inherited ExtConfigurationProvider interfaces, in META-INF/services/creating a file and fill in the full path name of the implementation class, as follows:

Implementation class to load third-party distribution center

After completion of the static code block logic load the configuration center property, Seata is how to select and configure a central distribution center and obtain the property value of it?

We just said the FileConfiguration is the default configuration Seata implementation class, it inherits AbstractConfiguration, its base class for Configuration, provides a method for obtaining the parameter values:

short getShort(String dataId, int defaultValue, long timeoutMills);
int getInt(String dataId, int defaultValue, long timeoutMills);
long getLong(String dataId, long defaultValue, long timeoutMills);
// ....复制代码

It means that only require third-party distribution center that implements this interface, you can integrate into Seata distribution center, here I get to do zk example:

First, the need to implement a third-party distribution center Provider class:

provider-implemented method as the name suggests, the main output is specific Configuration implementation class.

So how did we get to acquire third-party distribution center corresponding implementation classes depending on the configuration it?

In Seata project, obtain a third-party distribution center implementation classes usually do:

Configuration CONFIG = ConfigurationFactory.getInstance();复制代码

In getInstance () method is mainly used in single mode embodiment configured implementation class configuration, its specific implementation is configured as follows:

io.seata.config.ConfigurationFactory#buildConfiguration：

First, from ConfigurationFactory static code block according CURRENT registry.conf created FILE get INSTANCE current distribution center environments, the default is, we can also configure other third-party distribution center for the File type in registry.conf, here is the use of the SPI implementation class loading mechanism to the third party center configuration, specifically implemented as follows:

As above, that is just what I said ZookeeperConfigurationProvider configuration enables output class, let us look at this line of code:

EnhancedServiceLoader.load(ConfigurationProvider.class,Objects.requireNonNull(configType).name()).provide();复制代码

EnhancedServiceLoader is Seata SPI achieve core classes, this line of code loads META-INF/services/and META-INF/seata/files in a directory filled class name, so if there was more than one configuration center implementation classes are loaded how to do it?

We note that there is one annotation above ZookeeperConfigurationProvider class:

@LoadLevel(name = "ZK", order = 1)复制代码

When loading a plurality of distribution center implementation class will be sorted according to the order:

io.seata.common.loader.EnhancedServiceLoader#findAllExtensionClass：

io.seata.common.loader.EnhancedServiceLoader#loadFile：

In this way, it will not produce a conflict.

But we found Seata can also choose to use this method, Seata when you call the load method, also pass a parameter:

Objects.requireNonNull(configType).name()复制代码

ConfigType for the distribution center type, is an enumeration class:

public enum ConfigType {
  File, ZK, Nacos, Apollo, Consul, Etcd3, SpringCloudConfig, Custom;
}复制代码

We note that there is a comment on LoadLevel name attribute, when the implementation class during the screening, Seata also do this operation:

It determines whether the current configType equal LoadLevel name attribute, if equal, the configuration is the current configuration of the third party center implementation class.

Third-party distribution center implementation class

ZookeeperConfiguration inherited AbstractConfiguration, its structure is as follows:

Constructor creates a zkClient object here is what FILE_CONFIG it?

private static final Configuration FILE_CONFIG = ConfigurationFactory.CURRENT_FILE_INSTANCE;复制代码

But it was just static registry.conf block of code to create the implementation class configuration, the configuration from the implementation class to get the relevant attributes of third-party distribution center, distribution center construction third party client, then realized when Configuration Interface:

You can use a third party client configuration related method to obtain the values ​​corresponding to the parameters.

Third-party distribution center configuration synchronization script

Last weekend was written, has been submitted to PR up, still in review, the estimate will be available to everyone in Seata version 1.0, so stay tuned.

The specific location in the script directory Seata project:

config.txt configured as a local value, and then build a good third-party distribution center, run the script config.txt configuration will be synchronized to a third-party distribution center.

No public more exciting articles please pay attention to the maintenance of a "back-end Advanced", which is a focus on back-end technology-related public number.

No public attention and reply "back-end" to receive free e-books related to the back-end.

Welcome to share, reproduced Please keep the source.