对微服务稍有了解的小同伴应该都据说过 Zookeeper，我们来看看在官方上是如何引见的：
Zookeeper 是一个散布式的、开源的散布式运行程序协调服务。
作为一个协调服务，常罕用来配合其余两边件来用，比如：Dubbo + Zookeeper，Hadoop +Zookeeper等，Zookeeper可以成功：服务注册发现、散布式锁、性能中心等性能。
当天我们重点来学习一下 Zookeeper 是如何成功服务注册发现的。
散布式带来的疑问
先正式引见 Zookeeper 之前，我们先引入一个业务场景：订单服务要求调用用户服务的接口。
要成功这特性能十分便捷，我们只要求知道用户服务的 ip 和 port 就可以了。
突然有一天，用户数量激增，用户服务扛不住了，这个时刻只能启动扩容，多部署几个实例，这个时刻疑问就来了，订单服务该调用哪个用户服务的实例?
最便捷的方法就是在订单服务中性能一切的用户服务虚例，而后经常使用某种算法(比如说轮询)从性能列表当选用一个就可以了。
看似疑问处置了，其实隐患很大：
如何处置呢?往往处置这类散布式疑问都要求一块公共的区域来保留这些消息。
用 Redis 处置
要求一块公共的区域保留这些消息，那应用 Redis 能否可以成功?
每个服务虚例启动之后都向 Redis 注册消息，中止时也从 Redis 中删除数据。
寄存在 Redis 中的消息便捷来说就是服务虚例的 ip + port，订单服务要求调用用户服务时直接从 Redis 中失掉即可。
便捷流程如下图所示：
每次调用的时刻都去 Redis查问一次性，频繁的查问或许会造成性能瓶颈，为了处置这个疑问我们可以在查问之后在本地缓存一份数据，这样每次调用可以优先从本地失掉数据。
但这样又会出现新的疑问，本地缓存如何刷新呢，假设服务提供者某些实例 down 掉了或许扩容新增了一批实例，那服务生产者如何能力极速感知到呢?
要想处置这个疑问，最先想到的一个方法就是让服务生产者定时轮询Redis，发现有降级了就去降级本地缓存，看起来也能处置本地缓存刷新的疑问，然而多久轮询一次性呢，1 秒或许10 秒?
轮询期间太短依然有性能瓶颈疑问，这样本地缓存也没有存在的必要了;轮询期间太长，本地缓存来不迭降级，就会存在 "脏" 数据。
以上的打算都不完美，并且不优雅，关键有以下几点：
基于定时义务会造成很多有效的查问。
定时义务存在周期性，没法做到实时，这样就或许存在恳求意外。
假设服务被强行 kill，没法及时肃清 Redis，这样这个看似可用的服务将永远无法用!
所以我们要求一个愈加靠谱的处置打算。
用 Zookeeper 处置
用过 Dubbo 的小同伴对这张图必需很相熟，步骤 0 到 4 是服务注册发现的**流程。
这个流程与我们下面探讨的不约而同，那 Dubbo 是如何成功的呢?实践上 Dubbo作为一个通用的框架提供了多种处置打算，如：Zookeeper、Nacos等。
不论是哪种打算，总结起来都是一种套路，基本流程如下：
Zookeeper的重点特性
(1)树状目录结构
Zookeeper是一个树状的文件目录结构，与 Unix文件系统很相似。树中每个节点可以称作为一个ZNode，每一个ZNode都可以经过其门路惟一标识，最关键的是我们可以对每个 ZNode 启动增删改查。
(2)耐久节点(Persistent)
客户端与Zookeeper服务端断开衔接后，节点依然存在不会被删除，这样的节点就叫做耐久节点。
(3)耐久有序节点(Persistent_sequential)
耐久有序节点是在下面耐久节点的特性上加上了有序性，有序性的意思是服务向Zookeeper注册消息时，Zookeeper依据注册顺序给每个节点编号。
(4)暂季节点(Ephemeral)
客户端与Zookeeper服务端断开衔接后，该节点被删除。
留意:暂季节点下不存在子节点;耐久节点下可以存在暂季节点。
(5)暂时有序节点(Ephemeral_sequential)
暂时有序节点是在暂季节点的基础上再加上有序性，跟耐久有序节点相似。
(6)节点监听(Wacher)
节点监听是Zookeeper最关键的特性之一，客户端可以监听恣意节点，节点有任何变动 Zookeeper可以经过回调的形式通知给客户端，这样客户端不用轮询就可以及时感知节点变动。
如下图所示，客户端(client)开局监听暂季节点 1，因某种要素暂季节点 1 被删除了，Zookeeper 经过回调将变动通知给 client了。
Zookeeper 成功服务注册发现
了解了Zookeeper的一些关键特性，我们再来看下 Zookeeper 是如何成功服务注册和发现的。还是以订单服务、用户服务的场景为例。
服务提供方(用户服务)启动成功后将服务消息注册到Zookeeper，服务消息包括实例的 ip、端口等元消息。注册成功 Zookeeper还可以经过心跳监测来灵活感知实例变动，具体的环节这里不开展。
服务生产方(订单服务)要求调用用户服务的接口，但由于不知道实例的 ip、端口等消息，只能从 Zookeeper中失掉调用地址列表，而后启动调用，这个环节成为服务的订阅。
订阅成功后服务生产方可以将调用列表缓存在本地，这样不用每次都去调用 Zookeeper 失掉。一旦Zookeeper感知到用户服务虚例变动后就会通知给服务生产方，服务生产方拿到结果后就会降级本地缓存，这个环节称之为通知。
服务注册原理
服务启动后会智能向 Zookeeper 注册，注册的规定如下：
每个服务会创立一个耐久节点和若干个暂季节点。比如：用户服务首先创立一个耐久节点 user，而后每个服务虚例会在耐久节点下创立一个暂时有序节点。
服务灵活发现原理
由于订单服务要求调用用户服务的接口，所以订单服务会订阅 user 节点，一旦用户服务有变动(参与实例或许缩小实例)，Zookeeper都会将最新的列表消息推送给订单服务，这个环节就是服务灵活发现的基本原理。少用文字形容，大家直接看图：
小结
文章首先引入订单服务和用户服务的例子，说明了散布式场景下或许存在的疑问：服务提供者实例越多，保养的老本越高。
经过剖析，我们得出论断：要求经常使用一块公共的区域存储实例消息。
如何提供公共的区域?我们先想到了Redis。
经过通常发现 Redis 确实可以处置服务注册和服务发现的疑问，然而同时又引入了其余疑问：
当我们大刀阔斧的时刻，我们发现弱小的 Dubbo 框架经常使用了 Zookeeper 来成功服务注册和发现的性能。为了更好的学习 Zookeeper是如何成功服务注册和发现性能的，我们了解到 Zookeeper 的一些关键特性：
这些关键的特性为最后成功服务注册和灵活发现打下了松软的基础。
文章的最后，我们再次以订单服务和用户服务为例经过两张图活泼的诠释了服务注册和灵活发现的流程和原理。