update sd

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

@@ -60,17 +60,27 @@ redis-cli> sadd order_service.http 100.10.100.11:1002
 1. 客户端主动的故障摘除
 2. 客户端被动故障摘除。
 
-主动的故障摘除是指，我作为依赖其它人的上游，在下游一台机器挂掉的时候，我可以自己主动把它从依赖的节点列表里摘掉。常见的手段也有两种，一种是靠应用层心跳，还有一种靠请求投票。
+主动的故障摘除是指，我作为依赖其它人的上游，在下游一台机器挂掉的时候，我可以自己主动把它从依赖的节点列表里摘掉。常见的手段也有两种，一种是靠应用层心跳，还有一种靠请求投票。下面是一种根据请求时是否出错，对相应的服务节点进行投票的一个例子：
 
 ```go
+// 对下游的请求正常返回时:
+node := getNodeFromPool()
+
+resp, err := remoteRPC(ctx, params)
+
+if err != nil {
+    node.Vote(status.Healthy)
+} else {
+    node.Vote(status.Unhealthy)
+}
 ```
 
+在节点管理时，会对 Unhealthy 过多的节点进行摘除，这个过程可以在 Unhealthy 的数量超过一定的阈值之后自动触发，也就是在 Vote 函数中实现即可。
+
 被动故障摘除，顾名思义。依赖出问题了要别人通知我。这个通知一般通过服务注册中心发给我。
 
 被动故障摘除，最早的解决方案是 zookeeper 的 ephemeral node，java 技术栈的服务发现框架很多是基于此来做故障服务节点摘除。
 
-TODO，这里是 go-zookeeper 的临时节点使用 demo。
-
 比如我们是电商的平台部的订单系统，那么可以建立类似这样的永久节点:
 
 ```shell
@@ -79,9 +89,27 @@ TODO，这里是 go-zookeeper 的临时节点使用 demo。
 
 然后把我们的 endpoints 作为临时节点，建立在上述节点之下:
 
-
 ```shell
 ls /platform/order-system/create-order-service-http
 
 []
 ```
+
+当与 zk 断开连接时，注册在该节点下的临时节点也会消失，即实现了服务节点故障时的被动摘除。该事件也会通知 watch 该节点的所有监视方。
+
+用代码来实现一下上面的几个逻辑：
+
+```go
+```
+
+有了临时节点、监视功能、故障时的自动摘除功能，我们实现一套服务发现的基本元件也就齐全了。
+
+## 服务发现究竟应该是 CP 还是 AP 系统
+
+当前开源的服务发现系统中，使用 zk、etcd 或者 consul，无一例外地都是看中其强一致性的特性。也就是大部分人认为服务发现和分布式系统中的任务协调场景一致，是一个 CP 系统。我们来想想，如果放弃了分区容错性会导致什么样的结果。
+
+在上面提到的几个开源组件中使用的 paxos/zab/raft 协议，若因为网络分区等原因，导致集群节点数量 < n/2 时，会导致整个集群不能对外提供服务。网络分区是分布式系统中常见的错误。如果公司的服务部署在公有云、或者私有云的 docker 环境上，网络问题就更为常见了。一旦发生网络分区，就会导致类型下面这样的场景出现：
+
+TODO，网络分区示例图
+
+当几千或者上万个服务同时依赖同一个下游服务时，这些服务对应的万级以上的机器实例都需要对服务注册中心的依赖服务的注册节点进行监视。该依赖服务一旦发生 endpoint 变动，就会产生广播风暴。