update sd

ch5-web/ch5-10-service-discovery.md

@@ -132,7 +132,7 @@ ls /platform/order-system/create-order-service-http
 
 当与 zk 断开连接时，注册在该节点下的临时节点也会消失，即实现了服务节点故障时的被动摘除。
 
-## 数据变化通知
+## 基于 zk 实现服务发现
 
 该事件也会通知 watch 该节点的所有监视方。
 
@@ -144,19 +144,3 @@ ls /platform/order-system/create-order-service-http
 有了临时节点、监视功能、故障时的自动摘除功能，我们实现一套服务发现以及故障节点摘除的基本元件也就齐全了。
 
 目前在企业级应用中，上述几种故障摘除方案都是存在的。读者朋友可以根据自己公司的发展阶段，灵活选用对应的方案。需要明白的一点是，并非一定要有 zk、etcd 这样的组件才能完成故障摘除。
-
-## 服务发现究竟应该是 CP 还是 AP 系统
-
-当前开源的服务发现系统中，使用 zk、etcd 或者 consul，无一例外地都是看中其强一致性的特性。也就是大部分人认为服务发现和分布式系统中的任务协调场景一致，是一个 CP 系统。我们来想想，如果放弃了可用性会导致什么样的结果。
-
-在上面提到的几个开源组件中使用的 paxos/zab/raft 协议，若因为网络分区等原因，导致集群节点数量 < n/2 时，会导致整个集群不能对外提供服务。网络分区是分布式系统中常见的错误。如果公司的服务部署在公有云、或者私有云的 docker 环境上，网络问题就更为常见了。一旦发生网络分区，就会导致类似下面这样的场景出现：
-
-TODO，网络分区示例图
-
-如果分区之后再分区，那我们可能都无法从注册中心拿到任何数据了，服务之间的连通性也就无从谈起了。
-
-当几千或者上万个服务同时依赖同一个下游服务时，这些服务对应的万级以上的机器实例都需要对服务注册中心的依赖服务的注册节点进行监视。该依赖服务一旦发生 endpoint 变动，就会产生广播风暴。
-
-## eureka 新时代的服务发现
-
-eureka 是大名鼎鼎的 Netflix 公司对服务发现场景重新思考的结果。和传统的服务发现工具相比，eureka 将 CP 改为了 AP。