diff --git a/docs/zh_CN/architecture-design.md b/docs/zh_CN/architecture-design.md
index 63d08d8ca451c1e80cd7a5314e81d8dd8393bdea..b5b2ccce615593bd475869abfce3bead97495f84 100644
--- a/docs/zh_CN/architecture-design.md
+++ b/docs/zh_CN/architecture-design.md
@@ -116,6 +116,7 @@
  <p align="center"
    <img src="https://analysys.github.io/EasyScheduler/zh_CN/images/decentralization.png" alt="去中心化"  width="50%" />
  </p>
+ 
 - 在去中心化设计里，通常没有Master/Slave的概念，所有的角色都是一样的，地位是平等的，全球互联网就是一个典型的去中心化的分布式系统，联网的任意节点设备down机，都只会影响很小范围的功能。
 - 去中心化设计的核心设计在于整个分布式系统中不存在一个区别于其他节点的”管理者”，因此不存在单点故障问题。但由于不存在” 管理者”节点所以每个节点都需要跟其他节点通信才得到必须要的机器信息，而分布式系统通信的不可靠行，则大大增加了上述功能的实现难度。
 - 实际上，真正去中心化的分布式系统并不多见。反而动态中心化分布式系统正在不断涌出。在这种架构下，集群中的管理者是被动态选择出来的，而不是预置的，并且集群在发生故障的时候，集群的节点会自发的举行"会议"来选举新的"管理者"去主持工作。最典型的案例就是ZooKeeper及Go语言实现的Etcd。
@@ -162,7 +163,7 @@ EasyScheduler使用ZooKeeper分布式锁来实现同一时刻只有一台Master
 ##### 四、容错设计
 容错分为服务宕机容错和任务重试，服务宕机容错又分为Master容错和Worker容错两种情况
 
-######1. 宕机容错
+###### 1. 宕机容错
 
 服务容错设计依赖于ZooKeeper的Watcher机制，实现原理如图：