diff --git a/ch5-web/ch5-10-service-discovery.md b/ch5-web/ch5-10-service-discovery.md
index 788683f..ab444a4 100644
--- a/ch5-web/ch5-10-service-discovery.md
+++ b/ch5-web/ch5-10-service-discovery.md
@@ -6,7 +6,7 @@ ip+port 的组合往往被称为 endpoint。通过“订单服务”去找到这
 
 ## 为什么不把 ip+port 写死在自己的配置文件中
 
-在大型网站的语境下，为了高可用每一个服务都会一定会有多个节点来分担压力和风险，而现在随着 docker 之类的工具的盛行，依赖服务的节点是存在迁移的可能性的。所以对于依赖服务会慢慢不再将其 ip+port 写死在自己的服务的配置文件中。否则在依赖服务迁移时，就需要跟着依赖服务修改配置，耗时费力。
+在大型网站的语境下，为了高可用每一个服务都一定会有多个节点来分担压力和风险，而现在随着 docker 之类的工具的盛行，依赖服务的节点是存在迁移的可能性的。所以对于依赖服务会慢慢不再将其 ip+port 写死在自己的服务的配置文件中。否则在依赖服务迁移时，就需要跟着依赖服务修改配置，耗时费力。
 
 如果依赖服务所在的机器挂掉了，也就意味着那个 ip+port 不可用了。这时候上游还需要有某种反馈机制能够及时知晓，并且能够在知晓之后，不经过上线就能将已经失效的 ip+port 自动从依赖中摘除。
 
@@ -69,14 +69,14 @@ redis-cli> sadd order_service.http 100.10.100.11:1002
 
 ## 故障节点摘除
 
-上一小节讲的是存储的问题，在服务发现中，还有一个比较重要的命题，就是故障摘除。之所以开源界有很多服务发现的轮子，也正是因为这件事情并不是把 kv 映射存储下来这么简单。更重要的是我们能够在某个服务节点在宕机时，能够让依赖该节点的其它服务感知得到这个“宕机”的变化，从而不再向其发送任何请求。
+上一小节讲的是存储的问题，在服务发现中，还有一个比较重要的命题，就是故障摘除。之所以开源界有很多服务发现的轮子，也正是因为这件事情并不是把 kv 映射存储下来这么简单。更重要的是我们能够在某个服务节点宕机时，让依赖该节点的其它服务感知得到这个“宕机”的变化，从而不再向其发送任何请求。
 
 故障摘除有两种思路:
 
 1. 客户端主动的故障摘除
 2. 客户端被动故障摘除。
 
-主动的故障摘除是指，我作为依赖其它人的上游，在下游一台机器挂掉的时候，我可以自己主动把它从依赖的节点列表里摘掉。常见的手段也有两种，一种是靠应用层心跳，还有一种靠请求投票。下面是一种根据请求时是否出错，对相应的服务节点进行投票的一个例子：
+主动的故障摘除是指，我作为依赖其他人的上游，在下游一台机器挂掉的时候，我可以自己主动把它从依赖的节点列表里摘掉。常见的手段也有两种，一种是靠应用层心跳，还有一种靠请求投票。下面是一种根据请求时是否出错，对相应的服务节点进行投票的一个例子：
 
 ```go
 // 对下游的请求正常返回时: