diff --git a/ch5-web/ch5-11-service-discovery.md b/ch5-web/ch5-11-service-discovery.md
index 36bd247..a34e0d9 100644
--- a/ch5-web/ch5-11-service-discovery.md
+++ b/ch5-web/ch5-11-service-discovery.md
@@ -127,7 +127,7 @@ ls /platform/order-system/create-order-service-http
 
 ## 服务发现究竟应该是 CP 还是 AP 系统
 
-当前开源的服务发现系统中，使用 zk、etcd 或者 consul，无一例外地都是看中其强一致性的特性。也就是大部分人认为服务发现和分布式系统中的任务协调场景一致，是一个 CP 系统。我们来想想，如果放弃了分区容错性会导致什么样的结果。
+当前开源的服务发现系统中，使用 zk、etcd 或者 consul，无一例外地都是看中其强一致性的特性。也就是大部分人认为服务发现和分布式系统中的任务协调场景一致，是一个 CP 系统。我们来想想，如果放弃了可用性会导致什么样的结果。
 
 在上面提到的几个开源组件中使用的 paxos/zab/raft 协议，若因为网络分区等原因，导致集群节点数量 < n/2 时，会导致整个集群不能对外提供服务。网络分区是分布式系统中常见的错误。如果公司的服务部署在公有云、或者私有云的 docker 环境上，网络问题就更为常见了。一旦发生网络分区，就会导致类型下面这样的场景出现：