基於ZooKeeper實現配置中心繫統

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/