You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shenyu.apache.org by de...@apache.org on 2021/07/21 11:59:58 UTC
[incubator-shenyu-website] branch main updated: update English
document of ShenYu Design (#136)
This is an automated email from the ASF dual-hosted git repository.
dengliming pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/incubator-shenyu-website.git
The following commit(s) were added to refs/heads/main by this push:
new e37510d update English document of ShenYu Design (#136)
e37510d is described below
commit e37510d4b476a82f849e947785265a13de52190a
Author: midnight2104 <33...@qq.com>
AuthorDate: Wed Jul 21 19:59:51 2021 +0800
update English document of ShenYu Design (#136)
---
content/en/projects/shenyu/_index.md | 4 +-
content/en/projects/shenyu/data-sync/index.md | 175 +++++++--------------
.../en/projects/shenyu/database-design/index.md | 39 ++++-
content/en/projects/shenyu/flow-control/index.md | 20 ++-
content/en/projects/shenyu/overview/index.md | 2 +-
.../shenyu/register-center-design/index.md | 77 ++++-----
.../zh/projects/shenyu/database-design/index.md | 8 +-
.../shenyu/register-center-design/index.md | 2 +-
static/img/shenyu/dataSync/data-sync-en-1.png | Bin 0 -> 48803 bytes
static/img/shenyu/dataSync/flow-control-1.png | Bin 0 -> 25266 bytes
.../register/application-client-access-en-1.png | Bin 0 -> 47315 bytes
11 files changed, 150 insertions(+), 177 deletions(-)
diff --git a/content/en/projects/shenyu/_index.md b/content/en/projects/shenyu/_index.md
index 63fd2b6..3a96c6c 100644
--- a/content/en/projects/shenyu/_index.md
+++ b/content/en/projects/shenyu/_index.md
@@ -30,13 +30,13 @@ weight: 1
showIntroduce: true
showFeature: true
sidebar:
- - title: 'overview'
+ - title: 'Overview'
link: 'overview'
- title: 'Design'
sub:
- title: 'ShenYu Admin Database Design'
link: 'database-design'
- - title: 'Data Sync'
+ - title: 'Data Synchronization'
link: 'data-sync'
- title: 'Application Client Access'
link: 'register-center-design'
diff --git a/content/en/projects/shenyu/data-sync/index.md b/content/en/projects/shenyu/data-sync/index.md
index fa1d4fe..e9d8872 100644
--- a/content/en/projects/shenyu/data-sync/index.md
+++ b/content/en/projects/shenyu/data-sync/index.md
@@ -4,93 +4,78 @@ keywords: shenyu
description: Data Synchronization Design
---
-## Description
+This document explains the principle of data synchronization. Data synchronization refers to the strategy used to synchronize data to ShenYu Gateway after shenyu-admin background operation data. ShenYu Gateway currently supports ZooKeeper, WebSocket, HTTP Long Polling, Nacos, Etcd and Consul for data synchronization.
+
+See [Data Synchronization Configuration](../use-data-sync) for configuration information about data synchronization.
+
+
+<img src="/img/shenyu/dataSync/data-sync-en-1.png" width="90%" height="80%" />
-This article mainly explains three ways of database synchronization and their principles.
## Preface
-Gateway is the entrance of request and it is a very important part in micro service architecture, therefore the importance of gateway high availability is self-evident. When we use gateway, we have to change configuration such as flow rule, route rule for satisfying business requirement. Therefore, the dynamic configuration of the gateway is an important factor to ensure the high availability of the gateway. Then, how does `ShenYu` support dynamic configuration?
+Gateway is the entrance of request and it is a very important part in micro service architecture, therefore the importance of gateway high availability is self-evident. When we use gateway, we have to change configuration such as flow rule, route rule for satisfying business requirement. Therefore, the dynamic configuration of the gateway is an important factor to ensure the high availability of the gateway.
+
+In the actual use of Shenyu Gateway, users also feedback some problems:
+
+* ShenYu depends on ZooKeeper, how to use Etcd, Consul, Nacos and other registry center?
+
+* ShenYu depends on Redis and InfluxDB, and do not use limiting plugins or monitoring plugins. Why need these?
-Anyone who has used `ShenYu` knows, `ShenYu` plugin are hot swap,and the selector, rule of all plugins are dynamic configured, they take effect immediately without restarting service.But during using `ShenYu` gateway, users also report many problems
+* Why not use configuration center for configuration synchronization?
-- Rely on `zookeeper`, this troubles users who use `etcd` `consul` and `nacos` registry
-- Rely on `redis`,`influxdb`, I have not used the limiting plugin, monitoring plugin, why do I need these
+* Why can't updates be configured dynamically?
-Therefore,we have done a partial reconstruction of `ShenYu`,after two months of version iteration,we released version `2.0`
+* Every time you want to query the database, Redis is a better way.
-- Data Synchronization removes the strong dependence on `zookeeper`,and we add `http long polling` and `websocket`
-- Limiting plugin and monitoring plugin realize real dynamic configuration,we use `shenyu-admin` backend for dynamic configuration instead of `yml` configuration before
+According to the feedback of users, we have also partially reconstructed ShenYu. The current data synchronization features are as follows:
-*Q: Someone may ask me,why don't you use configuration center for synchronization?*
-First of all, it will add extra costs, not only for maintenance, but also make `ShenYu` heavy; In addition, using configuration center, data format is uncontrollable and it is not convenient for `shenyu-admin` to do configuration management.
+- All configuration is cached in ShenYu gateway memory, each request uses local cache, which is very fast.
-*Q: Someone may also ask,dynamic configuration update?Every time I can get latest data from database or redis,why are you making it complicated?*
+- Users can modify any data in the background of shenyu-admin, and immediately synchronize to the gateway memory.
+
+- Support ShenYu plugin, selector, rule data, metadata, signature data and other data synchronization.
+
+- All plugin selectors and rules are configured dynamically and take effect immediately, no service restart required.
+
+- Data synchronization mode supports Zookeeper, HTTP long polling, Websocket, Nacos, Etcd and Consul.
-As a gateway, `ShenYu` cached all the configuration in the `HashMap` of JVM in order to provide higher response speed and we use local cache for every request, It's very fast. So this article can also be understood as three ways of memory synchronization in a distributed environment.
## Principle Analysis
-This is a HD uncoded image, it shows the flow of `ShenYu` data synchronization, when `ShenYu` gateway starts, it will synchronize configuration data from the configuration service and support push-pull mode to obtain configuration change information, and update the local cache.When administrator changes user,rule,plugin,flow configuration in the backend, modified information will synchronize to the `ShenYu` gateway through the push-pull mode,whether it is the push mode or the pull mode d [...]
+The following figure shows the process of data synchronization of ShenYu. ShenYu Gateway will synchronize configuration data from configuration service at startup, and support push-pull mode to get configuration change information, and then update local cache. The administrator can change the user permissions, rules, plugins and traffic configuration in the admin system(shenyu-admin), and synchronize the change information to ShenYu Gateway through the push-pull mode. Whether the mode is [...]
<img src="/img/shenyu/dataSync/shenyu-config-processor-en.png" width="90%" height="80%" />
-At version `1.x` ,configuration service depends on `zookeeper`,management backend `push` the modified information to gateway.But version `2.x` supports `webosocket`,`http`,`zookeeper`,it can specify the corresponding synchronization strategy through `shenyu.sync.strategy` and use `webosocket` synchronization strategy by default which can achieve second-level data synchronization.But,note that `shenyu-web` and `shenyu-admin` must use the same synchronization mechanism.
-As showing picture below,`shenyu-admin` will issue a configuration change notification through `EventPublisher` after users change configuration,`EventDispatcher` will handle this modification and send configuration to corresponding event handler according to configured synchronization strategy(http,websocket,zookeeper)
+In the original version, the configuration service relied on the Zookeeper implementation to manage the back-end push of changes to the gateway. Now, WebSocket, HTTP long polling, ZooKeeper, Nacos, Etcd, and Consul can now be supported by specifying the corresponding synchronization policy by setting `shenyu.sync.${strategy}` in the configuration file. The default WeboSocket synchronization policy can be used to achieve second level data synchronization. However, it is important to note [...]
+
+
+
+As showing picture below,`shenyu-admin` will issue a configuration change notification through `EventPublisher` after users change configuration,`EventDispatcher` will handle this modification and send configuration to corresponding event handler according to configured synchronization strategy.
- If it is a `websocket` synchronization strategy,it will push modified data to `shenyu-web`,and corresponding `WebsocketCacheHandler` handler will handle `shenyu-admin` data push at the gateway layer
- If it is a `zookeeper` synchronization strategy,it will push modified data to `zookeeper`,and the `ZookeeperSyncCache` will monitor the data changes of `zookeeper` and process them
-- If it is a `http` synchronization strategy,`shenyu-web` proactively initiates long polling requests,90 seconds timeout by default,if there is no modified data in `shenyu-admin`,http request will be blocked,if there is a data change, it will respond to the changed data information,if there is no data change after 60 seconds,then respond with empty data,gateway continue to make http request after getting response,this kind of request will repeat
+- If it is a `http` synchronization strategy,`shenyu-web` proactively initiates long polling requests,90 seconds timeout by default,if there is no modified data in `shenyu-admin`,http request will be blocked,if there is a data change, it will respond to the changed data information,if there is no data change after 60 seconds,then respond with empty data,gateway continue to make http request after getting response,this kind of request will repeat.
<img src="/img/shenyu/dataSync/config-strategy-processor-en.png" width="90%" height="80%" />
-## Zookeeper Synchronization
+
+### Zookeeper Synchronization
The zookeeper-based synchronization principle is very simple,it mainly depends on `zookeeper` watch mechanism,`shenyu-web` will monitor the configured node,when `shenyu-admin` starts,all the data will be written to `zookeeper`,it will incrementally update the nodes of `zookeeper` when data changes,at the same time, `shenyu-web` will monitor the node for configuration information, and update the local cache once the information changes
-`ShenYu` writes the configuration information to the zookeeper node,and it is meticulously designed.
+`ShenYu` writes the configuration information to the zookeeper node,and it is meticulously designed. If you want to learn more about the code implementation, refer to the source code `ZookeeperSyncDataService`.
-## WebSocket Synchronization
+### WebSocket Synchronization
The mechanism of `websocket` and `zookeeper` is similar,when the gateway and the `shenyu-admin` establish a `websocket` connection,`shenyu-admin` will push all data at once,it will automatically push incremental data to `shenyu-web` through `websocket` when configured data changes
-When we use websocket synchronization,pay attention to reconnect after disconnection,which also called keep heartbeat.`ShenYu` uses `java-websocket` ,a third-party library,to connect to `websocket`.
-
-```java
-public class WebsocketSyncCache extends WebsocketCacheHandler {
- /**
- * The Client.
- */
- private WebSocketClient client;
-
- public WebsocketSyncCache(final ShenyuConfig.WebsocketConfig websocketConfig) {
- ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(1,
- ShenyuThreadFactory.create("websocket-connect", true));
- client = new WebSocketClient(new URI(websocketConfig.getUrl())) {
- @Override
- public void onOpen(final ServerHandshake serverHandshake) {
- //....
- }
- @Override
- public void onMessage(final String result) {
- //....
- }
- };
- //connect
- client.connectBlocking();
- //reconnect after disconnection,using scheduling thread pool,execute every 30 seconds
- executor.scheduleAtFixedRate(() -> {
- if (client != null && client.isClosed()) {
- client.reconnectBlocking();
- }
- }, 10, 30, TimeUnit.SECONDS);
- }
-```
-
-## Http Long Polling
+When we use websocket synchronization,pay attention to reconnect after disconnection,which also called keep heartbeat.`ShenYu` uses `java-websocket` ,a third-party library,to connect to `websocket`. If you want to learn more about the code implementation, refer to the source code `WebsocketSyncDataService`.
+
+### Http Long Polling
The mechanism of zookeeper and websocket data synchronization is relatively simple,but http synchronization will be relatively complicated.ShenYu borrows the design ideas of `Apollo` and `Nacos` and realizes `http` long polling data synchronization using their advantages.Note that this is not traditional ajax long polling.
@@ -100,74 +85,36 @@ http long polling mechanism as above,shenyu-web gateway requests shenyu-admin co
After the http request reaches shenyu-admin, it does not respond immediately,but uses the asynchronous mechanism of Servlet3.0 to asynchronously respond to the data.First of all,put long polling request task `LongPollingClient` into `BlocingQueue`,and then start scheduling task,execute after 60 seconds,this aims to remove the long polling request from the queue after 60 seconds,even there is no configured data change.Because even if there is no configuration change,gateway also need to k [...]
-```java
-public void doLongPolling(final HttpServletRequest request, final HttpServletResponse response) {
- // since shenyu-web may not receive notification of a configuration change, MD5 value may be different,so respond immediately
- List<ConfigGroupEnum> changedGroup = compareMD5(request);
- String clientIp = getRemoteIp(request);
- if (CollectionUtils.isNotEmpty(changedGroup)) {
- this.generateResponse(response, changedGroup);
- return;
- }
-
- // Servlet3.0 asynchronously responds to http request
- final AsyncContext asyncContext = request.startAsync();
- asyncContext.setTimeout(0L);
- scheduler.execute(new LongPollingClient(asyncContext, clientIp, 60));
-}
-
-class LongPollingClient implements Runnable {
- LongPollingClient(final AsyncContext ac, final String ip, final long timeoutTime) {
- // omit......
- }
- @Override
- public void run() {
- // join a scheduled task, if there is no configuration change within 60 seconds, it will be executed after 60 seconds and respond to http requests
- this.asyncTimeoutFuture = scheduler.schedule(() -> {
- // clients are blocked queue,saved the request from shenyu-web
- clients.remove(LongPollingClient.this);
- List<ConfigGroupEnum> changedGroups = HttpLongPollingDataChangedListener.compareMD5((HttpServletRequest) asyncContext.getRequest());
- sendResponse(changedGroups);
- }, timeoutTime, TimeUnit.MILLISECONDS);
- clients.add(this);
- }
-}
-```
If the administrator changes the configuration data during this period,the long polling requests in the queue will be removed one by one, and respond which group’s data has changed(we distribute plugins, rules, flow configuration , user configuration data into different groups).After gateway receives response,it only knows which Group has changed its configuration,it need to request again to get group configuration data.Someone may ask,why don't you write out the changed data directly?We [...]
-```java
-// shenyu-admin configuration changed,remove the requests from the queue one by one and respond to them
-class DataChangeTask implements Runnable {
- DataChangeTask(final ConfigGroupEnum groupKey) {
- this.groupKey = groupKey;
- }
- @Override
- public void run() {
- try {
- for (Iterator<LongPollingClient> iter = clients.iterator(); iter.hasNext(); ) {
- LongPollingClient client = iter.next();
- iter.remove();
- client.sendResponse(Collections.singletonList(groupKey));
- }
- } catch (Throwable e) {
- LOGGER.error("data change error.", e);
- }
- }
-}
-```
-When `shenyu-web` gateway layer receives the http response information,pull modified information(if exists),and then request `shenyu-admin` configuration service again,this will repeatedly execute.
+When `shenyu-web` gateway layer receives the http response information,pull modified information(if exists),and then request `shenyu-admin` configuration service again,this will repeatedly execute. If you want to learn more about the code implementation, refer to the source code `HttpSyncDataService`.
+
+### Nacos Synchronization
+
+
+The synchronization principle of Nacos is basically similar to that of ZooKeeper, and it mainly depends on the configuration management of Nacos. The path of each configuration node is similar to that of ZooKeeper.
+
+ShenYu gateway will monitor the configured node. At startup, if there is no configuration node in Nacos, it will write the synchronous full amount of data into Nacos. When the sequential data send changes, it will update the configuration node in Nacos in full amount. The local cache is updated.
+
+If you want to learn more about the code implementation, please refer to the source code `NacosSyncDataService` and the official documentation for [Nacos](https://nacos.io/zh-cn/docs/sdk.html) .
+
+### Etcd Synchronization
+
+Etcd data synchronization principle is similar to Zookeeper, mainly relying on Etcd's watch mechanism, and each configuration node path is the same as that of Zookeeper.
+
+The native API for Etcd is a bit more complicated to use, so it's somewhat encapsulated.
+ShenYu gateway will listen to the configured node. When startup, if there is no configuration node in Etcd, it will write the synchronous full amount of data into Etcd. When the sequential data send changes, it will update the configuration node in Etcd incrementally.
-## Storage Address
+If you want to learn more about the code implementation, refer to the source `EtcdSyncDataService`.
-github: https://github.com/apache/incubator-shenyu
+### Consul Synchronization
-gitee: https://gitee.com/Apache-ShenYu/incubator-shenyu
-There also have video tutorials on the project homepage,you can go to watch it if needed.
+Consul data synchronization principle is that the gateway regularly polls Consul's configuration center to get the configuration version number for local comparison.
-## At Last
+ShenYu gateway will poll the configured nodes regularly, and the default interval is 1s. When startup, if there is no configuration node in Consul, write the synchronous full amount of data into Consul, then incrementally update the configuration node in Consul when the subsequent data is sent to change. At the same time, Shenyu Gateway will regularly polls the node of configuration information and pull the configuration version number for comparison with the local one. The local cache i [...]
-This article introduces that,in order to optimize the response speed, `ShenYu` as a highly available micro service gateway, its three ways to cache the configuration rule selector data locally.After learning this article,I believe you have a certain understanding of the popular configuration center,it may be easier to learn their codes,I believe you can also write a distributed configuration center.Version 3.0 is already under planning,and I believe it will definitely surprise you.
+If you want to learn more about the code implementation, refer to the source `ConsulsyncDataService`.
diff --git a/content/en/projects/shenyu/database-design/index.md b/content/en/projects/shenyu/database-design/index.md
index 1a22ef2..fce227f 100644
--- a/content/en/projects/shenyu/database-design/index.md
+++ b/content/en/projects/shenyu/database-design/index.md
@@ -1,13 +1,18 @@
---
-title: Database Design
+title: ShenYu Admin Database Design
keywords: db
description: Database Design
---
-## Plugin Design
-* Plugin use database to store plugin, selector, rule configuration data and relationship.
+Shenyu Admin is the management system of the gateway, which can manage all plugins, selectors and rules visually, set users, roles and resources.
+
+## Plugin, Selector And Rule
+* Plugin: ShenYu uses the plugin design idea to realize the hot plug of the plugin, which is easy to expand. Built-in rich plugins, including RPC proxy, circuit breaker and current limiting, authority and certification, monitoring, and more.
+* Selector: Each plugin can set multiple selectors to carry out preliminary filtering of traffic.
+* Rule: Multiple rules can be set per selector for more fine-grained control of flow.
* The Database Table UML Diagram:
+
* Detailed design:
@@ -18,7 +23,7 @@ description: Database Design
* Each rule handles differently in corresponding plugin according to field handler,field handler is a kind of data of JSON string type.You can view detail during the use of shenyu-admin.
-## Resource Permission Desgin
+## Resource Permission
* The resource are the menus and buttons in the shenyu-admin console.
* Resource Permission use database to store user name,role,resource data and relationship.
@@ -29,7 +34,7 @@ description: Database Design
* Detailed design:
- one user corresponds to multiple role,one role corresponds to multiple resources.
-## Data Permissin Design
+## Data Permissin
* Data Permission use database to store the relationship between users, selectors and rules.
* The Data Permission Table UML Diagram:
@@ -39,5 +44,27 @@ description: Database Design
* Detailed design:
* The most important table is `data_permission`, where a user corresponds to multiple data permissions.
* The field `data_type` distinguishes between different types of data, which corresponds to the following: 0 -> selector, 1 -> rule.
- * The field `data_id` holds the primary key id of the corresponding type.
+ * The field `data_id` holds the primary key id of the corresponding type.
+
+## Meta Data
+
+* Metadata is used for generic invoke by gateway.
+* For each interface method, there is one piece of metadata.
+* The Database Table UML Diagram:
+
+<img src="/img/shenyu/db/mata_data_table.png" width="30%" height="30%" />
+
+
+* Detailed design：
+ * `path`: When the gateway is requested, a piece of data will be matched according to `path`, and then the subsequent process will be carried out.
+
+ * `rpc_ext`: Used to hold extended information for the RPC proxy.。
+
+## Dictionary Management
+
+* Dictionary management is used to maintain and manage public data dictionaries.
+* The Database Table UML Diagram:
+
+<img src="/img/shenyu/db/shenyu_dict.png" width="30%" height="30%" />
+
diff --git a/content/en/projects/shenyu/flow-control/index.md b/content/en/projects/shenyu/flow-control/index.md
index aaf2a35..e98e6f4 100644
--- a/content/en/projects/shenyu/flow-control/index.md
+++ b/content/en/projects/shenyu/flow-control/index.md
@@ -1,8 +1,24 @@
---
-title: flow-control
+title: Flow Control
keywords: flow-control
description: flow-control
---
-to do.
+ShenYu gateway realizes flow control through plugins, selectors and rules. For related data structure, please refer to the previous [ShenYu Admin Database Design](../database-design) .
+
+### Plugin
+
+In ShenYu Admin System, each plugin uses Handle (JSON format) fields to represent different processing, and the plugin processing is used to manage and edit the custom processing fields in the JSON.
+
+The main purpose of this feature is to enable plugins to handle templated configurations.
+
+### Selector And Rule
+
+Selector and rule are the most soul of ShenYu Gateway. Master it and you can manage any traffic.
+
+A plugin has multiple selectors, and one selector corresponds to multiple rules. The selector is the first level filter of traffic, and the rule is the final filter. For a plugin, we want to meet the traffic criteria based on our configuration before the plugin will be executed. Selectors and rules are designed to allow traffic to perform what we want under certain conditions. The rules need to be understood first.
+
+The execution logic of plugin, selector and rule is as follows. When the traffic enters into ShenYu gateway, it will first judge whether there is a corresponding plugin and whether the plugin is turned on. Then determine whether the traffic matches the selector of the plugin. It then determines whether the traffic matches the rules of the selector. If the request traffic meets the matching criteria, the plugin will be executed. Otherwise, the plugin will not be executed. Process the next [...]
+
+<img src="/img/shenyu/dataSync/flow-control-1.png" width="40%" height="30%" />
diff --git a/content/en/projects/shenyu/overview/index.md b/content/en/projects/shenyu/overview/index.md
index d7baaf8..86304f7 100644
--- a/content/en/projects/shenyu/overview/index.md
+++ b/content/en/projects/shenyu/overview/index.md
@@ -11,7 +11,7 @@ This is an asynchronous, high-performance, cross-language, responsive API gatewa
## Features
-* Support various languages (http protocol), support Dubbo, Spring-Cloud, Grpc, Motan, Sofa, Tars and other protocols.
+* Support various languages (http protocol), support Dubbo, Spring Cloud, gRPC, Motan, Sofa, Tars and other protocols.
* Plugin design idea, plugin hot swap, easy to expand.
* Flexible flow filtering to meet various flow control.
* Built-in rich plugin support, authentication, limiting, fuse, firewall, etc.
diff --git a/content/en/projects/shenyu/register-center-design/index.md b/content/en/projects/shenyu/register-center-design/index.md
index e61fc29..4352d9d 100644
--- a/content/en/projects/shenyu/register-center-design/index.md
+++ b/content/en/projects/shenyu/register-center-design/index.md
@@ -1,45 +1,41 @@
---
-title: Register Center Design
+title: Application Client Access
keywords: shenyu
-description: register center design
+description: Application Client Access
---
-## Description
+Application client access means to access your micro service to Shenyu Gateway, currently supports HTTP, Dubbo, Spring Cloud, gRPC, Motan, Sofa, Tars and other protocols access.
-* This article mainly explains three ways of register center and their principles.
+Connecting the application client to ShenYu gateway is realized through the registration center, which involves the registration of the client and the synchronization of the server data. The registry supports HTTP, ZooKeeper, Etcd, Consul, and Nacos.
-#### Client
-
-
+Refer to the client access configuration in the user documentation for Application Client Config.
-When client server start, the register center client will be loaded by spi.
+<img src="/img/shenyu/register/application-client-access-en-1.png" width="70%" height="60%" />
-Put data to Disruptor when spring bean load.
-ShenYu register client get data from Disruptor, and it will send request to register server.
+## Design principle
-Disruptor can decouple data from operation and facilitate expansion.
+#### Client
-#### Server
+
-
+Declare the registry client type, such as HTTP or ZooKeeper, in your microservice configuration. Use SPI to load and initialize the corresponding registry client when the application starts, implement the post-processor interface associated with the Spring Bean, get the service interface information to register in it, and place the obtained information into Disruptor.
-When Shenyu-Admin server start, register center server will be loaded by spi. Meanwile Disruptor will be inited too.
+The Registry client reads data from the Disruptor and registers the interface information with shenyu-admin, where the Disruptor decouples data from operations for scaling.
-ShenYu register server get data from register client, and then put then to Disruptor.
+#### Server
-Shenyu-Admin Disruptor consumer get data from register server by Disruptor queue, then save them to database and publish data synchronize event.
+
-Disruptor can decouple data from operation and buffering.
+Declare the registry server type, such as HTTP or ZooKeeper, in the Shenyu-Admin configuration. When shenyu-admin is started, it will read the configuration type, load and initialize the corresponding registry server, and when the registry server receives the interface information registered by shenyu-client, it will put it into Disruptor, which will trigger the registration processing logic to update the interface information and publish a synchronous event.
+Disruptor provides data and operations decoupling for expansion. If there are too many registration requests, resulting in abnormal registration, there is also a data buffer role.
## Http Registry
-Principle of http register center is simple
-
-Call interface of register server when Shenyu-Client start.
+The principle of HTTP service registration is relatively simple. After Shenyu-Client is started, the relevant service registration interface of Shenyu-Admin will be called to upload data for registration.
-Shenyu-Admin accept request, then save to database and publish data synchronize event.
+After receiving the request, shenyu-admin will update the data and publish the data synchronization event to synchronize the interface information to ShenYu Gateway.
## Zookeeper Registry
@@ -59,13 +55,9 @@ shenyu
├ ├ ├ ├──${ip:prot}
```
-Zookeeper register client will save data to zookeeper when shenyu client is started.
+shenyu-client starts up, the service interface information (MetaDataRegisterDTO/URIRegisterDTO) wrote above the Zookeeper nodes.
-Zookeeper register server will keep watching the change of data node.
-
-Trigger selector and rule data update and event will be published, when metadata data node update.
-
-Trigger selector and upstream update and event will be published, when uri data node update.
+shenyu-admin uses the Watch mechanism of Zookeeper to monitor events such as data update and deletion, and triggers the corresponding registration processing logic after data changes. Upon receipt of a change to the MetadataregisterDTO node, the data change and data synchronization event publication of the selector and rule is triggered. Upon receipt of a UriRegisterDTO node change, the upstream of the selector is triggered to publish an update and data synchronization event.
## Etcd Registry
@@ -85,13 +77,9 @@ shenyu
├ ├ ├ ├──${ip:prot}
```
-Etcd register client will save data to etcd when shenyu client is started.
-
-Etcd register server will keep watching the change of data node.
+shenyu-client starts up, the service interface information (MetaDataRegisterDTO/URIRegisterDTO) wrote in Ephemeral way above Etcd of the node.
-Trigger selector and rule data update and event will be published, when metadata data node update.
-
-Trigger selector and upstream update and event will be published, when uri data node update.
+shenyu-admin uses Etcd's Watch mechanism to monitor events such as data update and deletion, and triggers the corresponding registration processing logic after data changes. Upon receipt of a change to the MetadataregisterDTO node, the data change and data synchronization event publication of the selector and rule is triggered. Upon receipt of a UriRegisterDTO node change, the upstream of the selector is triggered to publish an update and data synchronization event.
## Consul Registry
@@ -111,35 +99,30 @@ shenyu
```
-Consul register client will save data to consul when shenyu client is started.
-
-Consul register server will keep watching the change of data node.
+When shenyu-client is started, The service interface information (MetaDataRegisterDTO/URIRegisterDTO) on the Metadata of the ServiceInstance (URIRegisterDTO) and Key-Value (MetaDataRegisterDTO), Store as described above.
-Trigger selector and rule data update and event will be published, when metadata data node update.
-
-Trigger selector and upstream update and event will be published, when uri data node update.
+shenyu-admin senses the update and deletion of data by monitoring the change of index of Catalog and KeyValue, and triggers the corresponding registration processing logic after the change of data. Upon receipt of a change to the MetadataregisterDTO node, the data change and data synchronization event publication of the selector and rule is triggered. Upon receipt of a UriRegisterDTO node change, the upstream of the selector is triggered to publish an update and data synchronization event.
## Nacos Register
-Nacos register have two parts：URI and Metadata。
-
-URI is instance register. URI instance node will be deleted when server is down.
+Nacos registration is divided into two parts: URI and Metadata. URI is registered by instance. In case of service exception, the relevant URI data node will be deleted automatically and send events to the subscriber, and the subscriber will carry out relevant offline processing. Metadata is registered by configuration without any related up-down operation. When a URI instance is registered, the Metadata configuration will be published accordingly. The subscriber monitors data changes and [...]
-URI service's instance name will be named like below. Every URI instance has ip, port and contextPath as identifiers.
+The URI instance registration command rules are as follows:
```
shenyu.register.service.${rpcType}
```
-When URI instance up, it will publish metadata config. It's name like below.
+
+Listens on all RpcType nodes initially, and the `${contextPath}` instances registered under them are distinguished by IP and Port, and carry their corresponding contextPath information. After the URI instance is offline, it triggers the update and data synchronization event publication of the selector's upstream.
+
+When the URI instance goes online, the corresponding Metadata data will be published. The node name command rules are as follows:
```
shenyu.register.service.${rpcType}.${contextPath}
```
-Trigger selector and upstream update and event will be published, when URI service up or down.
-
-Trigger selector and rule data update and event will be published, when metadata config update.
+The subscriber side continues to listen for all Metadata configurations, triggering selector and rule data changes and data synchronization events after the initial subscription and configuration update.
## SPI
diff --git a/content/zh/projects/shenyu/database-design/index.md b/content/zh/projects/shenyu/database-design/index.md
index 627f067..34b7a58 100644
--- a/content/zh/projects/shenyu/database-design/index.md
+++ b/content/zh/projects/shenyu/database-design/index.md
@@ -49,17 +49,17 @@ description: ShenYu Admin数据结构
## 元数据
-* 元数据主要是用于网关对 `Dubbo` 的泛化调用。
-* 每个 `Dubbo` 接口方法，对应一条元数据。
+* 元数据主要是用于网关的泛化调用。
+* 每个接口方法，对应一条元数据。
* 数据库 `UML` 类图：
<img src="/img/shenyu/db/mata_data_table.png" width="30%" height="30%" />
* 设计详解：
- * `path` 字段，在请求网关的时候，会根据 `path` 来匹配到一条数据，然后进行后续的流程。
+ * `path`：在请求网关的时候，会根据 `path` 来匹配到一条数据，然后进行后续的流程。
- * `rpc_ext`字段，用于保存 `Dubbo` 类型的服务接口中 `group` 和 `version` 信息。
+ * `rpc_ext`：用于保存`RPC`代理中的扩展信息。
## 字典管理
diff --git a/content/zh/projects/shenyu/register-center-design/index.md b/content/zh/projects/shenyu/register-center-design/index.md
index 0ce4d77..286b8fc 100644
--- a/content/zh/projects/shenyu/register-center-design/index.md
+++ b/content/zh/projects/shenyu/register-center-design/index.md
@@ -114,7 +114,7 @@ shenyu
shenyu.register.service.${rpcType}
```
-初始监听所有的`RpcType`节点，其下的`{contextPath}`实例会对应注册到其下，根据`IP`和`Port`进行区分，并携带其对应的`contextPath`信息。`URI` 实例上下线之后，触发`selector`的`upstream`的更新和数据同步事件发布。
+初始监听所有的`RpcType`节点，其下的`${contextPath}`实例会对应注册到其下，根据`IP`和`Port`进行区分，并携带其对应的`contextPath`信息。`URI` 实例上下线之后，触发`selector`的`upstream`的更新和数据同步事件发布。
`URI` 实例上线时，会发布对应的 `Metadata` 数据，其节点名称命令规则如下：
diff --git a/static/img/shenyu/dataSync/data-sync-en-1.png b/static/img/shenyu/dataSync/data-sync-en-1.png
new file mode 100644
index 0000000..065c532
Binary files /dev/null and b/static/img/shenyu/dataSync/data-sync-en-1.png differ
diff --git a/static/img/shenyu/dataSync/flow-control-1.png b/static/img/shenyu/dataSync/flow-control-1.png
new file mode 100644
index 0000000..41843a8
Binary files /dev/null and b/static/img/shenyu/dataSync/flow-control-1.png differ
diff --git a/static/img/shenyu/register/application-client-access-en-1.png b/static/img/shenyu/register/application-client-access-en-1.png
new file mode 100644
index 0000000..72e6217
Binary files /dev/null and b/static/img/shenyu/register/application-client-access-en-1.png differ