乐趣区

关于java:基于ZooKeeper实现配置中心系统

jiezi

1 背景

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

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

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

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

jdbc.user=root
jdbc.password=123456
jdbc.driver=com.mysql.cj.jdbc.Driver
jdbc.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/

退出移动版