微服务实战系列之ZooKeeper（上）

前言

历经1个多月的创作和总结，纵观博主微服务系列博文，大致脉络覆盖了以下几个方面：

数据方面（缓存&安全）
比如Redis、MemCache、Ehcache、J2cache（两级缓存框架）、RSA加密、Sign签名…
传输方面（消息系统）
MQ、通信基础
服务方面（支撑服务）
Feign、Token、Sentinel、Nacos、Gateway

显然，我们可以观察到，如果只有这些工具或组件，还不足以支撑一个中型微服务系统。

如此，今天博主继续拉新，谈一谈 ZooKeeper 是怎么回事，为什么我们有时候对它望而生畏而又难以割舍呢？
在这里插入图片描述
今天我们一起开启这个话题，请各位盆友紧随博主，以防迷路。

走进ZooKeeper

ZooKeeperis 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集群中，哪个节点应该做领袖，哪些节点应该是随从，说来话长，且听下回分解。