历经1个多月的创作和总结,纵观博主微服务系列博文,大致脉络覆盖了以下几个方面:
显然,我们可以观察到,如果只有这些工具或组件,还不足以支撑一个中型微服务系统。
如此,今天博主继续拉新,谈一谈 ZooKeeper
是怎么回事,为什么我们有时候对它望而生畏而又难以割舍呢?
今天我们一起开启这个话题,请各位盆友紧随博主,以防迷路。
ZooKeeper
is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.
翻译成大白话:
ZooKeeper
是一个“中央处理器”
,主要面向配置管理与维护
、目录服务
、分布式集群服务
提供相关能力和支持。
提到Zookeeper
的配置管理,我们是不是立刻可以想到另外一个工具:Nacos
?对了,Nacos也可以管理配置,实现热部署。那么ZooKeeper 又是怎么回事?
首先这里的配置比较泛泛而谈,可以简单理解为一段文本或一个服务信息等等。比如我们常用的经典微服务框架dubbo,使用了ZooKeeper作为注册中心。其实也是利用了它的配置管理特点,充当了“配置或服务管理员”
的角色。
通过上图,我们可以这样理解,每个Client(客户端)初始化时,会向ZooKeeper注册一个Watcher
,通过它实现信息的监听与同步,最终完成配置或服务的一致性管理。
目录和命名服务又是什么?是否可以立刻联想到JNDI(Java Naming and Directory Interface,Java命名和目录接口)
?,当年大名鼎鼎的SUN提供的一整套命名服务API,为J2EE的建设立下了汗马功劳。
比如我们常见的datasource
,就是典型的JNDI服务:
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<local-tx-datasource>
<jndi-name>myds-msql</jndi-name>
<connection-url>jdbc:mysql://localhost:3306/test</connection-url>
<driver-class>com.mysql.jdbc.Driver</driver-class>
<user-name>root</user-name>
<password>123456</password>
</local-tx-datasource>
</datasources>
那么ZooKeeper又是怎么设计的呢?请转向下图:
ZooKeeper提供了一种 树形
结构的数据存储方式。这样做的好处是在分布式环境下,实现全局唯一性。
我们可以提前把各种服务、各种地址、各种目录,比如地址信息以数据存储于ZooKeeper中。在使用的时候,只需从中读取即可,原理与JNDI类似。
统一命名的含义,可以理解为服务的代称。比如我们经常使用的域名,其实就是对某个主机IP的“翻译”
。
我们实现微服务就是为了分布式部署和运行,完成应用拆分和解耦。ZooKeeper作为分布式的利器,主要体现在强大的集群运行和统一调度能力。
博主先带着各位盆友看一下,集群是如何运行的:
这是官方提供的ZooKeeper集群运行示意图。从上图我们可以看到,ZooKeeper集群并非采用Master-Slave
模式,而是采用了Leader-Follower
模式。上图中除了标识为“Leader(领袖)”
的Server节点外,其他Server均为“Follower(随从)”
。其中,还有另外一种角色是“Observer(观察员)”
,我们后面再讲它。
当然Zookeeper集群中,哪个节点应该做领袖,哪些节点应该是随从,说来话长,且听下回分解。
通过以上总结性叙述,博主简单介绍了ZooKeeper
具备的核心能力。当然它还具备一些非主打的特性,在这里就不再详细展开了。
此刻,博主不禁感慨:离开了ZooKeeper
,分布式将变的困难的多;离开了分布式,微服务也将黯然失色。
好了,ZooKeeper第一篇到此为止,希望对各位盆友有所帮助,GoodNight!