This is an automated email from the ASF dual-hosted git repository.
hyunkun pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/dubbo-website.git
The following commit(s) were added to refs/heads/master by this push:
new db097d3 translate config-center.md (#456)
db097d3 is described below
commit db097d3d517666500d743bc0c4eed78b42814477
Author: Junjian Peng <mzor...@gmail.com>
AuthorDate: Thu Aug 29 11:26:34 2019 +0800
translate config-center.md (#456)
* translate config-center.md
* fix typos
* Update docs.js
---
docs/en-us/dev/impls/config-center.md | 95 +++++++++++++++++++++++++++++++++++
site_config/docs.js | 4 ++
2 files changed, 99 insertions(+)
diff --git a/docs/en-us/dev/impls/config-center.md
b/docs/en-us/dev/impls/config-center.md
new file mode 100644
index 0000000..23e594b
--- /dev/null
+++ b/docs/en-us/dev/impls/config-center.md
@@ -0,0 +1,95 @@
+# Dubbo Configuration Center
+
+## Design Purpose
+
+The key function of CC(Configuration Center) is to act as a Key-Value store.
Dubbo Framework tells CC the key it care about, CC return the corresponding
value.
+
+Divided by application scenarios, CC mainly undertake the following
responsibilities in Dubbo Framework:
+
+- As a external configuration center, CC store configuration files like
dubbo.properties, where the key is usually file name like dubbo.properties, and
value is content of the file.
+- Store single configuration items, like all kinds of switchs, contants, etc.
+- Store service governance rules, where the key is usually formated like
"ServiceName+RuleType", while value is the specific governance rule.
+
+Dubbo CC also introduced concepts of `namespace` and `group` to better manage
Key-Value pairs by group, those concepts are already built-in in many
professional third-party configuration centers. In most cases, `namespace` is
used to isolate different tetants, while `group` is used to divid the key set
from one tetant into groups.
+
+Dubbo CC has currently supported Zookeeper, Nacos, Etcd, Consul, Apollo, next
we will see how Dubbo CC is mapped to a specific third-party implementation.
+
+## Extension Interface
+
+* `org.apache.dubbo.configcenter.DynamicConfigurationFactory`
+* `org.apache.dubbo.configcenter.DynamicConfiguration`
+
+## Existing Extension
+
+*
`org.apache.dubbo.configcenter.support.zookeeper.ZookeeperDynamicConfigurationFactory`
+*
`org.apache.dubbo.configcenter.support.zookeeper.NacosDynamicConfigurationFactory`
+*
`org.apache.dubbo.configcenter.support.zookeeper.EtcdDynamicConfigurationFactory`
+*
`org.apache.dubbo.configcenter.support.zookeeper.ConsulDynamicConfigurationFactory`
+*
`org.apache.dubbo.configcenter.support.zookeeper.ApolloDynamicConfigurationFactory`
+
+## Implementation
+
+### Zookeeper
+
+Zookeeper provided a tree-structure storage model, the implementation is as
follows:
+
+
+
+namespace, group, key are corresponded to different levels of ZNodes, while
value is content of the key ZNode.
+
+1. External configuration cetner dubbo.properties
+
+ 
+
+ The figure above shows the storage structure of the dubbo.properties file
in two different scopes in zookeeper:
+ - namespace: both are 'dubbo'
+ - group: 'dubbo' is globally shared by all applications; 'demo-provider' is
application level, only affect the specific application
+ - key: dubbo.properties
+
+2. Single configuration item
+
+ 
+
+ The figure above shows how we set the shutdown wait time to 15000:
+ - namespace: dubbo
+ - group: dubbo
+ - key: dubbo.service.shutdown.wait
+ - value: 15000
+
+3. Service governance rule
+
+ 
+
+ The figure above shows an application-level conditional routing rule:
+
+ - namespace：dubbo
+ - group：dubbo
+ - key：governance-conditionrouter-consumer.condition-router, in wich
governance-conditionrouter-consumer is application name, condition-router
represents condition router.
+
+
+ > Notice:
+ >
+ > Dubbo support two level of governance rules: application, service. The
key format are as follows:
+ > * application level {application name + rule suffix}, such as:
`demo-application.configurators`,`demo-application.tag-router`, etc.
+ > * service level {service interface name:[version]:[group] + rule
suffix}, in which version and group are optional, such as:
`org.apache.dubbo.demo.DemoService::.configurators`,`org.apache.dubbo.demo.DemoService:1.0.0:group1.configurators`,
etc.
+
+### Etcd & Consul
+
+Etcd and Consul are essencially tree-structure storage like Zookeeper, see
zookeeper for implementation.
+
+### Nacos
+
+Nacos is a professional third-party configuration center, it has a storage
structure designed specifically for the configuration center, including
built-in concepts like namespace, group, dataid, etc. And these concepts
basically correspond to the configuration center of the Dubbo framework
abstraction.
+
+The correspondence with the Zookeeper implementation is as follows：
+
+
+
+Refer to the example described in the zookeeper implementation above, where
dataid might be:
+* External configuration center: dubbo.properties
+* Single configuration item: dubbo.service.shutdown.wait
+* Service governance rule:
org.apache.dubbo.demo.DemoService:1.0.0:group1.configurators
+
+### Apollo
+
+Apollo is similar to Nacos. Please refer to the documentation on the Apollo
section.
diff --git a/site_config/docs.js b/site_config/docs.js
index 20b0cd2..d1971ff 100644
--- a/site_config/docs.js
+++ b/site_config/docs.js
@@ -554,6 +554,10 @@ export default {
{
title: 'LoggerAdapter',
link:
'/en-us/docs/dev/impls/logger-adapter.html'
+ },
+ {
+ title: 'ConfigCenter',
+ link:
'/en-us/docs/dev/impls/config-center.html'
}
]
},
