The core function of the configuration center is to serve as a Key-Value storage. The Dubbo framework informs the configuration center of the keys it is concerned about, and the configuration center returns the corresponding value for those keys.
Divided by application scenario, the configuration center primarily undertakes the following responsibilities in the Dubbo framework:
To further implement grouped management of key-values, Dubbo’s configuration center has also integrated the concepts of namespace and group, which are reflected in many professional third-party configuration centers. Generally, the namespace is used to isolate different tenants, while the group is used to group the collection of keys for the same tenant.
Currently, the Dubbo configuration center has implemented integration with Zookeeper, Nacos, Etcd, Consul, and Apollo. Next, let’s specifically look at how Dubbo’s abstract configuration center maps to specific third-party implementations.
org.apache.dubbo.configcenter.DynamicConfigurationFactory
org.apache.dubbo.configcenter.DynamicConfiguration
org.apache.dubbo.configcenter.support.zookeeper.ZookeeperDynamicConfigurationFactory
org.apache.dubbo.configcenter.support.nacos.NacosDynamicConfigurationFactory
org.apache.dubbo.configcenter.support.etcd.EtcdDynamicConfigurationFactory
org.apache.dubbo.configcenter.consul.ConsulDynamicConfigurationFactory
org.apache.dubbo.configcenter.support.apollo.ApolloDynamicConfigurationFactory
org.apache.dubbo.common.config.configcenter.file.FileSystemDynamicConfigurationFactory
Zookeeper provides a tree-like storage model, and its implementation principles are as follows:
The namespace, group, key, etc., correspond to different levels of ZNode nodes, while the value is stored as the value of the root ZNode.
Externalized Configuration Center dubbo.properties
The above figure shows the storage structure of two different scopes of dubbo.properties files in Zookeeper:
Single Configuration Item
Setting graceful shutdown event to 15000:
Service Governance Rules
The above figure shows an application-level conditional routing rule:
Note:
Dubbo supports two granularities of service governance rules: application and service. The key value rules for these two granularities are as follows:
- Application granularity {application name + rule suffix}. For example:
demo-application.configurators
,demo-application.tag-router
, etc.- Service granularity {service interface name:[service version]:[service group] + rule suffix}, where service version and service group are optional. If configured, they will be reflected in the key; if not, “:” will be used as a placeholder. For example,
org.apache.dubbo.demo.DemoService::.configurators
,org.apache.dubbo.demo.DemoService:1.0.0:group1.configurators
.
Etcd and Consul are essentially similar to Zookeeper in terms of tree-like storage structures. For implementation, please refer to Zookeeper.
As a professional third-party configuration center, Nacos has a storage structure designed specifically for configuration centers, including built-in concepts such as namespace, group, dataid, etc. These concepts correspond one-to-one with those abstracted by the Dubbo framework.
The correspondence with the Zookeeper implementation is as follows:
Refer to the Zookeeper implementation description mentioned above. The dataid here could be:
Apollo is similar to Nacos; please refer to the Apollo section in the dynamic configuration center usage documentation.