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