在一個分布式環(huán)境中，同類型的服務(wù)往往會部署很多實例。這些實例使用了一些配置，為了更好地維護(hù)這些配置就產(chǎn)生了配置管理服務(wù)。通過這個服務(wù)可以輕松地管理這些應(yīng)用服務(wù)的配置問題。應(yīng)用場景可概括為：
zookeeper的一種應(yīng)用就是分布式配置管理(基于ZooKeeper的配置信息存儲方案的設(shè)計與實現(xiàn))。百度也有類似的實現(xiàn)：disconf。
Diamond則是淘寶開源的一種分布式配置管理服務(wù)的實現(xiàn)。Diamond本質(zhì)上是一個Java寫的Web應(yīng)用，其對外提供接口都是基于HTTP協(xié)議的，在閱讀代碼時可以從實現(xiàn)各個接口的controller入手。
分布式配置管理
分布式配置管理的本質(zhì)基本上就是一種推送-訂閱模式的運用。配置的應(yīng)用方是訂閱者，配置管理服務(wù)則是推送方。概括為下圖：
其中，客戶端包括管理人員publish數(shù)據(jù)到配置管理服務(wù)，可以理解為添加/更新數(shù)據(jù)；配置管理服務(wù)notify數(shù)據(jù)到訂閱者，可以理解為推送。
配置管理服務(wù)往往會封裝一個客戶端庫，應(yīng)用方則是基于該庫與配置管理服務(wù)進(jìn)行交互。在實際實現(xiàn)時，客戶端庫可能是主動拉取(pull)數(shù)據(jù)，但對于應(yīng)用方而言，一般是一種事件通知方式。
Diamond中的數(shù)據(jù)是簡單的key-value結(jié)構(gòu)。應(yīng)用方訂閱數(shù)據(jù)則是基于key來訂閱，未訂閱的數(shù)據(jù)當(dāng)然不會被推送。數(shù)據(jù)從類型上又劃分為聚合和非聚合。因為數(shù)據(jù)推送者可能很多，在整個分布式環(huán)境中，可能有多個推送者在推送相同key的數(shù)據(jù)，這些數(shù)據(jù)如果是聚合的，那么所有這些推送者推送的數(shù)據(jù)會被合并在一起；反之如果是非聚合的，則會出現(xiàn)覆蓋。
數(shù)據(jù)的來源可能是人工通過管理端錄入，也可能是其他服務(wù)通過配置管理服務(wù)的推送接口自動錄入。
架構(gòu)及實現(xiàn)
Diamond服務(wù)是一個集群，是一個去除了單點的協(xié)作集群。如圖：
圖中可分為以下部分講解：
服務(wù)之間同步
Diamond服務(wù)集群每一個實例都可以對外完整地提供服務(wù)，那么意味著每個實例上都有整個集群維護(hù)的數(shù)據(jù)。Diamond有兩種方式保證這一點：
- 任何一個實例都有其他實例的地址；任何一個實例上的數(shù)據(jù)變更時，都會將改變的數(shù)據(jù)同步到mysql上，然后通知其他所有實例從mysql上進(jìn)行一次數(shù)據(jù)拉取(
DumpService::dump)，這個過程只拉取改變了的數(shù)據(jù)
- 任何一個實例啟動后都會以較長的時間間隔（幾小時），從mysql進(jìn)行一次全量的數(shù)據(jù)拉取(
DumpAllProcessor)
實現(xiàn)上為了一致性，通知其他實例實際上也包含自己。以服務(wù)器收到添加聚合數(shù)據(jù)為例，處理過程大致為：
DatumController::addDatum // /datum.do?method=addDatum
PersistService::addAggrConfigInfo
MergeDatumService::addMergeTask // 添加一個MergeDataTask，異步處理
MergeTaskProcessor::process
PersistService::insertOrUpdate
EventDispatcher.fireEvent(new ConfigDataChangeEvent // 派發(fā)一個ConfigDataChangeEvent事件
NotifyService::onEvent // 接收事件并處理
TaskManager::addTask(..., new NotifyTask // 由此，當(dāng)數(shù)據(jù)發(fā)生變動，則最終創(chuàng)建了一個NoticyTask
// NotifyTask同樣異步處理
NotifyTaskProcessor::process
foreach server in serverList // 包含自己
notifyToDump // 調(diào)用 /notify.do?method=notifyConfigInfo 從mysql更新變動的數(shù)據(jù)
雖然Diamond去除了單點問題，不過問題都下降到了mysql上。但由于其作為配置管理的定位，其數(shù)據(jù)量就mysql的應(yīng)用而言算小的了，所以可以一定程度上保證整個服務(wù)的可用性。
數(shù)據(jù)一致性
由于Diamond服務(wù)器沒有master，任何一個實例都可以讀寫數(shù)據(jù)，那么針對同一個key的數(shù)據(jù)則可能面臨沖突。這里應(yīng)該是通過mysql來保證數(shù)據(jù)的一致性。每一次客戶端請求寫數(shù)據(jù)時，Diamond都將寫請求投遞給mysql，然后通知集群內(nèi)所有Diamond實例（包括自己）從mysql拉取數(shù)據(jù)。當(dāng)然，拉取數(shù)據(jù)則可能不是每一次寫入都能拉出來，也就是最終一致性。
Diamond中沒有把數(shù)據(jù)放入內(nèi)存，但會放到本地文件。對于客戶端的讀操作而言，則是直接返回本地文件里的數(shù)據(jù)。
服務(wù)實例列表
Diamond服務(wù)實例列表是一份靜態(tài)數(shù)據(jù)，直接將每個實例的地址存放在一個web server上。無論是Diamond服務(wù)還是客戶端都從該web server上取出實例列表。
對于客戶端而言，當(dāng)其取出了該列表后，則是隨機(jī)選擇一個節(jié)點(ServerListManager.java)，以后的請求都會發(fā)往該節(jié)點。
數(shù)據(jù)同步
客戶端庫中以固定時間間隔從服務(wù)器拉取數(shù)據(jù)(ClientWorker::ClientWorker，ClientWorker::checkServerConfigInfo)。只有應(yīng)用方關(guān)心的數(shù)據(jù)才可能被拉取。另外，為了數(shù)據(jù)推送的及時，Diamond還使用了一種long polling的技術(shù)，其實也是為了突破HTTP協(xié)議的局限性。如果整個服務(wù)是基于TCP的自定義協(xié)議，客戶端與服務(wù)器保持長連接則沒有這些問題。
數(shù)據(jù)的變更
Diamond中很多操作都會檢查數(shù)據(jù)是否發(fā)生了變化。標(biāo)識數(shù)據(jù)變化則是基于數(shù)據(jù)對應(yīng)的MD5值來實現(xiàn)的。
容災(zāi)
在整個Diamond系統(tǒng)中，幾個角色為了提高容災(zāi)性，都有自己的緩存，概括為下圖：
每一個角色出問題時，都可以盡量保證客戶端對應(yīng)用層提供服務(wù)。
參考文檔