ZooKeeper作为一款分布式协调框架,被广泛应用在分布式,大数据开发领域,雅虎研究员设计Zookeeper的初衷,是想利用Zookeeper的临时顺序节点,轻松实现分布式锁,但随后Zookeeper被应用与服务注册发现中,最著名的应用莫过于阿里的分布式RPC框架Dubbo,那么ZooKeeper为什么能被阿里选中,成为服务的注册中心呐,今天我们就一起聊一聊这个话题。
ZooKeeper的数据模型
要想了解今天的问题,我们要从ZooKeeper的数据模型说起,它很像数据结构当中的树,树是由节点所组成,Zookeeper 的数据存储也同样是基于节点,这种节点叫做 Znode,但是,不同于树的节点,Znode 的引用方式是路径引用,类似于文件路径,要拿到节点中存放的数据,就要通过路径才能获取,也就是是说,它和文件系统和REST风格类似,是基于路径访问资源的。
由于ZooKeeper的数据模型非常像文件系统,所以这就允许我们通过访问对应路径下的Znode来获取其中的数据,当一个请求通过网关进入ZooKeeper时,ZooKeeper便可通过url中的路径匹配相应的服务,并进行调用。
ZooKeeper的事件通知
那么大量的服务注册到ZooKeeper集群上,当服务发生宕机,或故障时,ZooKeeper将如何处理呐?这里便用到了我们将要聊到的事件通知(Watch)。
我们可以把 Watch 理解成是注册在特定 Znode 上的触发器。当这个 Znode 发生改变,也就是发生写操作的时候,将会触发 Znode 上注册的对应事件,请求 Watch 的客户端会接收到异步通知。
具体的流程如下:
服务端接到请求后,会返回数据并且在对应的哈希表里插入被 Watch 的 Znode 路径以及Watcher列表(WatchTalbe)。
当被 Watch 的 Znode 已删除,服务端会查找哈希表,找到该 Znode 对应的所有 Watcher,异步通知客户端,并且删除哈希表中对应的 Key-Value。
服务注册与发现流程简单分析
当服务上线后,各个服务会注册到ZooKeeper,这时ZooKeeper通过写操作,将各个服务的ip等信息存储到Znode中
假设用户通过API网关调用A服务,API网关通过REST风格的接口路径即可得到访问从ZooKeeper客户端获取数据的Key
当ZooKeeper客户端调用读操作,并开启事件通知模式时,即可轻松的获取对应的数据,并将被Watch的服务写入哈希表,当注册到ZooKeeper的服务出现故障宕机时,即可通过异步通知ZooKeeper客户端,将相应的服务从哈希表中移除,这便实现了服务注册的基本功能。
当然,在实际的部署中,ZooKeeper及各个服务均会部署多个,以实现服务的高可用,但是将服务全部注册到ZooKeeper集群中,当ZooKeeper集群发生故障时,能否保障提供正常的服务注册发现服务呐,我们在下个文章一起聊聊吧。