前言
Zookeeper实现服务注册与发现主要应用的是Zookeeper的Znode数据模型和Watcher机制。
Zookeeper的数据模型，有点类似咱们数据结构中的树形结构，也有点类似我们操作系统的目录结构。
树由节点组成，Zookeeper的数据存储也是基于节点，数据模型中的每一个节点，Zookeeper称之为Znode。但是与树的节点不同的是，Zookeeper中Znode的引用方式是路径引用，即是通过类似于目录文件访问的形式引用节点数据。
每当一个服务提供者部署后都要将自己的服务注册到zookeeper的某一路径上: /{service}/{version}/{ip:port}, 比如我们的HelloWorldService部署到两台机器，那么zookeeper上就会创建两条目录：分别为/HelloWorldService/1.0.0/100.19.20.01:16888 /HelloWorldService/1.0.0/100.19.20.02:16888。
在zookeeper中，进行服务注册，实际上就是在zookeeper中创建了一个znode节点，该节点存储了该服务的IP、端口、调用方式(协议、序列化方式)等。该节点承担着最重要的职责，它由服务提供者(发布服务时)创建，以供服务消费者获取节点中的信息，从而定位到服务提供者真正网络拓扑位置以及得知如何调用。
Zookeeper服务注册与服务发现
服务提供者：服务提供者（Provider）启动时，会向Zookeeper服务端注册服务信息，即会在Zookeeper服务器上创建一个服务节点，并在节点上存储服务的相关数据（如服务提供者的ip地址、端口等）。
服务消费者：服务消费者（Consumer）启动时，会根据本身依赖的服务信息，向Zookeeper服务端获取注册的服务信息并设置Watch，获取到注册的服务信息之后将服务提供者信息缓存在本地，当消费者调用服务时，不会再去请求注册中心，而是直接通过负载均衡算法从缓存信息中取一个服务提供者的服务器调用服务。
服务注册中心：当服务提供者因为某种原因宕机或不提供服务之后，Zookeeper服务注册中心的对应服务节点会被删除，因为服务消费者在获取服务信息的时候在对应节点上设置了Watch，因此节点删除之后会触发对应的Watcher，Zookeeper注册中心会异步向服务所关联的所有服务消费者发出节点删除的通知，服务消费者根据收到的通知更新缓存的服务列表。
关于watch工作原理
服务消费者向服务器获取某个Znode节点的数据时，设置watch为true。服务端接到请求后，返回节点的数据，并在维护的WatchTable中插入被Watch的Znode路径以及Watcher（watch该Znode的客户端）；
当被Watch的Znode被删除或者更新之后，Zookeeper服务器会查找Watch Table，找到在Znode上对应的所有Watcher，异步通知对应的客户端，并且删除Watch Table中对应的Key：Value；
感知服务的下线&上线
感知服务的下线
zookeeper提供了“心跳检测”功能，它会定时向各个服务提供者发送一个请求（实际上建立的是一个 socket 长连接），如果长期没有响应，服务中心就认为该服务提供者已经“挂了”，并将其剔除。比如100.100.0.237这台机器如果宕机了，那么zookeeper上的路径就会只剩/HelloWorldService/1.0.0/100.100.0.238:16888。
服务消费者会去监听相应路径（/HelloWorldService/1.0.0），一旦路径上的数据有任务变化（增加或减少），zookeeper都会通知服务消费方、服务提供者地址列表已经发生改变，从而进行更新。
当某个服务的所有服务器都下线了，那么这个服务也就下线了。
更为重要的是zookeeper 与生俱来的容错容灾能力（比如leader选举），可以确保服务注册表的高可用性。
感知服务的上线
使用 zookeeper 作为注册中心时，服务消费者订阅服务时会向 zookeeper 注册自身；主要是方便对调用方进行统计、管理。但订阅时是否注册 client 不是必要行为，和不同的注册中心实现有关，例如使用 consul 时便没有注册。
当服务提供者的某台服务器上线时，注册中心会将新的服务IP地址列表发送给服务消费者机器（根据服务注册中心记录的消费者地址），消费者再缓存在本机。
go使用Zookeeper实现服务发现
go-zookeeper
文档地址: http://godoc.org/github.com/samuel/go-zookeeper/zk
参考：