“啥是集群信息管理？”有個架構(gòu)師反問我。我猜，她在架構(gòu)設(shè)計的過程中，可能壓根沒有考慮過這個問題。

啥是集群？

互聯(lián)網(wǎng)典型分層架構(gòu)如下：

• web-server層；
• service層；
• db層與cache層；

為了保證高可用，每一個站點、服務(wù)、數(shù)據(jù)庫、緩存都會冗余多個實例，組成一個分布式的系統(tǒng)，集群則是一個分布式的物理形態(tài)。

通俗的說，集群就是一堆機器，上面部署了提供相似功能的站點，服務(wù)，數(shù)據(jù)庫，或者緩存。

如上圖：

• web集群；
• service集群；
• db集群；
• cache集群；

與“集群”相對應(yīng)的是“單機”。

什么是集群信息？

一個集群，會包含若干信息（額，這tm算什么解釋），例如：

• 集群名稱
• IP列表
• 二進制目錄
• 配置目錄
• 日志目錄
• 負責(zé)人列表

畫外音：集群IP列表不建議直接使用IP，而建議使用內(nèi)網(wǎng)域名。

什么時候會用到集群信息呢？

很多場景，特別是線上操作，都會使用到各種集群信息，例如：

• 自動化上線
• 監(jiān)控
• 日志清理
• 二進制與配置的備份
• 下游的調(diào)用（額，這個最典型）

這些場景，分別都是如何讀取集群信息的？

一般來說，早期會把集群信息寫在配置文件里。

例如，自動化上線，有一個配置文件，deploy.user.service.config，其內(nèi)容是：

name : user.service
ip.list : ip1, ip2, ip3
bin.path : /user.service/bin/
ftp.path : ftp://192.168.0.1/USER_2_0_1_3/user.exe

自動化上線的過程，則是：

• 把可執(zhí)行文件從ftp拉下來；
• 讀取集群IP列表；
• 讀取二進制應(yīng)該部署的目錄；
• 把二進制部署到線上；
• 逐臺重啟；

又例如，web-X調(diào)用下游的user服務(wù)，又有一個配置文件，web-X.config，其內(nèi)容配置了：

service.name : user.service
service.ip.list : ip1, ip2, ip3
service.port : 8080

web-X調(diào)用user服務(wù)的過程，則是：

• web-X啟動；
• web-X讀取user服務(wù)集群的IP列表與端口；
• web-X初始化user服務(wù)連接池；
• web-X拿取user服務(wù)的連接，通過RPC接口調(diào)用user服務(wù)；

日志清理，服務(wù)監(jiān)控，二進制備份的過程，也都與上述類似。

上述方案存在什么問題？

上述業(yè)務(wù)場景，對于集群信息的使用，有兩個最大的特點：

• 每個應(yīng)用場景，所需集群信息都不一樣（A場景需要集群abc信息，B場景需要集群def信息）；
• 每個應(yīng)用場景，集群信息都寫在“自己”的配置文件里；

一句話總結(jié)：集群信息管理分散化。

這里最大的問題，是耦合，當(dāng)集群的信息發(fā)生變化的時候，有非常多的配置需要修改：

• deploy.user.service.config
• clean.log.user.service.config
• backup.bin.user.service.config
• monitor.config
• web-X.config
• …

這些配置里，user服務(wù)集群的信息都需要修改：

• 隨著研發(fā)、測試、運維人員的流動，很多配置放在哪里，逐步就被遺忘了；
• 隨著時間的推移，一些配置就被改漏了；
• 逐漸地，莫名其妙的問題出現(xiàn)了；

如何解決上述耦合的問題呢？

一句話回答：集群信息管理集中化。

如何集中化管理集群信息？

如何集中化管理集群配置信息，不同發(fā)展階段的公司，實現(xiàn)的方式不一樣。

早期方案

通過全局配置文件，實現(xiàn)集群信息集中管理，舉例global.config如下：

[user.service]
ip.list : ip1, ip2, ip3
port : 8080
bin.path : /user.service/bin/
log.path : /user.service/log/
conf.path : /user.service/conf/
ftp.path :ftp://192.168.0.1/USER_2_0_1_3/user.exe
owner.list : shenjian, zhangsan, lisi

[passport.web]
ip.list : ip11, ip22, ip33
port : 80
bin.path : /passport.web/bin/
log.path : /passport.web/log/
conf.path : /passport.web/conf/
ftp.path :ftp://192.168.0.1/PST_1_2_3_4/passport.jar
owner.list : shenjian, zui, shuaiqi

集中維護集群信息之后：

• 任何需要讀取集群信息的場景，都從global.config里讀??；
• 任何集群信息的修改，只需要修改global.config一處；
• global.config會部署到任何一臺線上機器，維護和管理也很方便；

畫外音：額，當(dāng)然，信息太多的話，global.config也要垂直拆分。

中期方案

隨著公司業(yè)務(wù)的發(fā)展，隨著技術(shù)團隊的擴充，隨著技術(shù)體系的完善，通過集群信息管理服務(wù)，來維護集群信息的訴求越來越強烈。

畫外音：慢慢的，配置太多了，通過global.config來修改配置太容易出錯了

如上圖，建立集群信息管理服務(wù)：

• info.db ：存儲集群信息；
• info.cache ：緩存集群信息；
• info.service ：提供集群信息訪問的RPC接口，以及HTTP接口；
• info.web ：集群信息維護后臺；

服務(wù)的核心接口是：

Info InfoService::getInfo(String ClusterName);
Bool InfoService::setInfo(String ClusterName, String key, String value);

然后，統(tǒng)一通過服務(wù)來獲取與修改集群信息：

• 所有需要獲取集群信息的場景，都通過info.service提供的接口來讀取集群信息；
• 所有需要修改集群信息的場景，都通過info.web來操作；

長期方案

集群信息服務(wù)可以解決大部分的耦合問題，但仍然有一個不足：集群信息變更時，無法反向?qū)崟r通知關(guān)注方，集群信息發(fā)生了改變。更長遠的，要引入配置中心來解決。

配置中心的細節(jié)，網(wǎng)上的分析很多，之前也撰文寫過，細節(jié)就不再本文展開。

稍作總結(jié)

集群信息管理，是架構(gòu)設(shè)計中非常容易遺漏的一環(huán)，但又是非?；A(chǔ)，非常重要的基礎(chǔ)設(shè)施，一定要在早期規(guī)劃好：

• 傳統(tǒng)的方式，分散化管理集群信息，容易導(dǎo)致耦合；
• 集中管理集群信息，有全局配置，信息服務(wù)，配置中心三個階段；

知其然，知其所以然。

思路比結(jié)論更重要。