Merge pull request #551 from zenlint/developer

Correct README.md and arch pic
diff --git a/syncer/README-ZH.md b/syncer/README-ZH.md
index 9e99212..f72a048 100644
--- a/syncer/README-ZH.md
+++ b/syncer/README-ZH.md
@@ -16,7 +16,7 @@
 ### 2. ServiceCenter Syncer架构
 Syncer的运行时架构图如下:  
 ![image](./images/SyncerArchitecture.png?raw=true)  
-如图所示,我们可以看到被标记为“A”、"B"、“C”的三个服务中心。  
+如图所示,  
 
 - 在每个服务中心内,均部署了一套服务注册中心(ServiceCenter、Eurake或者其他)集群,该集群管理其所属服务中心的所有微服务实例,并且是彼此隔离的。同时在每个服務中心里各自部署了一个Syncer集群,它负责从注册中心发现实例,并向服务中心注册来自其他服务中心的实例信息。  
 - 在多个服务中心间,多个Syncer组成对等网络,维持一个Gossip池。Gossip协议的使用主要带来了以下便捷:
@@ -67,16 +67,17 @@
 
 以下将启动两个Syncer来完成这两个服务中心之间的微服务数据同步:
 
-**在10.0.0.10的机器上执行以下命令启动ServiceCenter Syncer**
+**在10.0.0.10的机器上执行以下命令启动Syncer**
 
 ```bash
 $ ./syncer daemon --sc-addr http://10.0.0.10:30100 --bind 10.0.0.10:30190 --rpc-addr 10.0.0.10:30191
 ```
 
-**在10.0.0.10的机器上执行以下命令启动ServiceCenter Syncer,并加入10.0.0.10的gossip池**
+**在10.0.0.11的机器上执行以下命令启动Syncer,并加入10.0.0.10的gossip池**
+
 ```bash
 $ ./syncer daemon --sc-addr http://10.0.0.11:30100 --bind 10.0.0.11:30190 --rpc-addr 10.0.0.11:30191 --join 10.0.0.10:30191
 ```
 
 **结果验证**  
-将微服务实例注册到其中一个ServiceCener后30秒,可以从每个ServiceCenter获取有关该实例的信息。
+将微服务实例注册到其中一个ServiceCener后30秒,可以从每个ServiceCenter获取有关该实例的信息。
\ No newline at end of file
diff --git a/syncer/README.md b/syncer/README.md
index bbb4196..12e7b3b 100644
--- a/syncer/README.md
+++ b/syncer/README.md
@@ -16,7 +16,7 @@
 ### 2. ServiceCenter Syncer Architecture
 Syncer's runtime architecture diagram is as follows,
 ![image](./images/SyncerArchitecture.png?raw=true)  
-There are three service-centers, labeled "A" and "B" and "C". 
+There are three service-centers, 
 
 - Within each service center, a service registry (ServiceCenter, Eurake, or other) cluster is deployed that manages all microservice instances of the service center to which it belongs, and the service centers are isolated from each other. At the same time, a Syner cluster is deployed in each service center, which is responsible for discovering instances from the registry and registering instance information from other service centers to its own service centers.
 - Between multiple service centers, multiple Syncers form a peer-to-peer network that maintains a Gossip pool. The use of the Gossip protocol mainly brings the following conveniences, 
@@ -48,10 +48,10 @@
 
 ##### 3.3 Running ServiceCenter Syncer
 ###### Parameter Description
-- dc-addr 
+- sc-addr 
 
   Service center address, which is the service registry address. Cluster mode is supported, and multiple addresses are separated by commas.   
-  Example `--dc-addr http://10.0.0.10:30100,http://10.0.0.11:30100`
+  Example `--sc-addr http://10.0.0.10:30100,http://10.0.0.11:30100`
 
 - bind
 
@@ -79,16 +79,16 @@
 
 Start Service-center Syncer to enable communication between 2 service centers,
 
-**Start the ServiceCenter Syner by executing the following command on the 10.0.0.10 machine**
+**Start Sycner 10.0.0.10 host**
 
 ```bash
-$ ./syncer daemon --dc-addr http://10.0.0.10:30100 --bind 10.0.0.10:30190 --rpc-addr 10.0.0.10:30191
+$ ./syncer daemon --sc-addr http://10.0.0.10:30100 --bind 10.0.0.10:30190 --rpc-addr 10.0.0.10:30191
 ```
 
-**Start the ServiceCenter Syncer by executing the following command on the 10.0.0.10 machine and join the 10.0.0.10 gossip pool**
+**Start Syncer on 10.0.0.11 host and join into 10.0.0.10 gossip pool**
 
 ```bash
-$ ./syncer daemon --dc-addr http://10.0.0.11:30100 --bind 10.0.0.11:30190 --rpc-addr 10.0.0.11:30191 --join 10.0.0.10:30191
+$ ./syncer daemon --sc-addr http://10.0.0.11:30100 --bind 10.0.0.11:30190 --rpc-addr 10.0.0.11:30191 --join 10.0.0.10:30191
 ```
 
 **Verification**  
diff --git a/syncer/images/SyncerArchitecture.png b/syncer/images/SyncerArchitecture.png
index b65ce52..c9c8b88 100644
--- a/syncer/images/SyncerArchitecture.png
+++ b/syncer/images/SyncerArchitecture.png
Binary files differ