From 8ea110260ff7b50b8b29a1c4b0d1ff428b5fe1fd Mon Sep 17 00:00:00 2001 From: Xargin Date: Sat, 2 Jun 2018 22:33:08 +0800 Subject: [PATCH] update sd --- ch6-web/ch6-11-service-discovery.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/ch6-web/ch6-11-service-discovery.md b/ch6-web/ch6-11-service-discovery.md index 4d424f7..c2d2b9d 100644 --- a/ch6-web/ch6-11-service-discovery.md +++ b/ch6-web/ch6-11-service-discovery.md @@ -53,4 +53,16 @@ redis-cli> sadd order_service.http 100.10.100.11:1002 上一小节讲的是存储的问题，在服务发现中，还有一个比较重要的命题，就是故障摘除。之所以开源界有很多服务发现的轮子，也正是因为这件事情并不是把 kv 映射存储下来这么简单。更重要的是我们能够在某个服务节点在宕机时，能够让依赖该节点的其它服务感知得到这个“宕机”的变化，从而不再向其发送任何请求。 -最早的解决方案是 zookeeper 的 ephemeral node，java 技术栈的服务发现框架很多是基于此来做故障服务节点摘除。 +故障摘除有两种思路: + +1. 客户端主动的故障摘除 +2. 客户端被动故障摘除。 + +主动的故障摘除是指，我作为依赖其它人的上游，在下游一台机器挂掉的时候，我可以自己主动把它从依赖的节点列表里摘掉。常见的手段也有两种，一种是靠应用层心跳，还有一种靠请求投票。 + +```go +``` + +被动故障摘除，顾名思义。依赖出问题了要别人通知我。这个通知一般通过服务注册中心发给我。 + +被动故障摘除，最早的解决方案是 zookeeper 的 ephemeral node，java 技术栈的服务发现框架很多是基于此来做故障服务节点摘除。