1 背景

1.1 分布式技术的成熟，分布式的宽泛风行

分布式集群下的配置管理实现形式，在当下这个时代未然是分布式的时代，联合上国家提倡的新基建的大背景，云服务和虚拟化也曾经从高大上的名词变成了接地气的技术。
当初各个公司的服务，能用系统分布式的多台小型机器部署，就尽量不必大型计算机解决，一个十分经典的起因就是单点故障。

1.2 分布式集群上的配置文件须要对立治理

当初，咱们以JavaWeb为例，你有一个分布式部署的JavaWeb服务，这些服务执行最简略的CRUD工作，上面连贯的是MySQL，当初你须要在分布式部署的每台服务器上都写入同样的配置文件

jdbc.user=rootjdbc.password=123456jdbc.driver=com.mysql.cj.jdbc.Driverjdbc.url=jdbc:mysql://xxx.xxx.xxx.xxx:3306/database?useUnicode=true&characterEncoding=utf8

这时你面对几个问题：

  1. 哪里能够对立看到本人的集群配置
  2. 如果我须要批改连贯的DB（比方主从切换），难道要一台台ssh下来改吗？

简略的解决办法就是写一个脚本，批量上传配置文件到每台服务器上的相应地位，而后重启服务。然而这样的问题在于没有方法对立治理和查看配置，而且存在上传失败的问题

能够发现配置的属性比拟相似于dubbo的注册核心，保障配置文件在分布式服务下的一致性

1.3 配置管理文件的几种实现计划

Zookeeper
Eureka
git
redis

对于这几种配置存储形式的比拟，咱们会独自开一个坑去探讨。本次咱们先探讨ZooKeeper的个性如何保障并实现高可用的配置管理系统。

1.4 采纳ZooKeeper可能存在问题

因为ZooKeeper在CAP原理（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个个性在任何分布式系统中不能同时满足，最多同时满足两个）上只能满足CP（数据统一和分区故障容错），zk在master节点故障的时候整个zk服务选主过程不可用，因而会有稳定性问题。

解决的计划是在zk集群和使用者之间结构一层缓存层

2 总体构造

2.1 搭建一个zk集群

https://zookeeper.apache.org/
首先须要搭建一个zk的集群，能够参照官网上的教程执行，本文不再赘述

2.2 开发client端


针对不同的开发语言（Java，C++，python，go），不同的环境（Spring...），开发配置核心client端，cient端须要做到的事件：

  1. 封装zkClient操作，反对对于配置的文件缓存+内存缓存性能
  2. 通过zkClient的watcher订阅机制订阅监听zk节点变更事件，以便于及时刷新缓存
  3. 对于例如Spring的环境，须要反对#{property}或者对于SpringBoot反对@Value 等注解的配置注入性能

2.3 开发治理端

治理端的性能是封装对于zk文件的查看和批改逻辑，以便于对配置文件进行对立治理，这里能够反对的操作有：

  • 权限管制，通过CAS零碎建设账号体系，治理端保护<账户名-账户角色>的映射关系，对于不同角色的账户裸露不同的操作权限
  • 查看目录构造和查看文件，即zk的ls和get命令
  • 删除配置文件，即zk的delete命令
  • 公布配置（发送watcher事件到client端），即对zk指定地位的文件进行批改操作
  • 配置反对回滚操作，即zk的门路中反对版本号，公布操作时copy出一份原配置正本后再执行配置批改

reference

[1] 《从Paxos到ZooKeeper分布式一致性原理与实际》
[2] 服务注册核心，Eureka与Zookeeper比拟
[3] ZooKeeper官网文档[OL]. http://zookeeper.apache.org/doc/