監控平臺，服務治理，調用鏈跟蹤，數據收集中心，自動化測試… 很多公司在搞技術體系平臺化。可如果連第一步“集群信息集中管理”都沒做到，談平臺化為時尚早。

今天，和大家聊聊技術體系平臺化的基石，集群信息集中管理。

[[357741]]

什么是集群?

互聯網典型分層架構如下：

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

 

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

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

如上圖：

• web集群，由web.1和web.2兩個實例組成;
• service集群，由service.1/service.2/service.3三個實例組成;
• db集群，由mysql-M/mysql-S1/mysql-S2三個實例組成;
• cache集群，由cache-M/cache-S兩個實例組成;

 

與“集群”相對應的是“單機”。

畫外音：緩存如果沒有高可用要求，可以是單機架構，而不用非得是集群。

什么是集群信息?

一個集群，會包含若干信息(額，這算什么解釋)，例如：集群名稱，節點IP列表，二進制目錄，配置目錄，日志目錄，負責人列表等，這些就是集群信息。

畫外音：集群節點IP列表，往往不是內外IP列表，是內網域名列表。

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

很多場景，特別是線上操作，都會使用到各種集群信息，例如：自動化上線，監控，日志清理，二進制與配置的備份，下游的調用等，都會用到集群信息。

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

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

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

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 

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

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

畫外音：還沒有實現自動化腳本部署?趕緊照著這個流程，做自動化改造吧。

又例如，web-X調用下游的user服務，又有一個配置文件，web-X.config，其內容配置了：

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

web-X調用user服務的過程，則是：

• web-X啟動;
• web-X讀取user服務集群的IP列表與端口;
• web-X初始化user服務連接池;
• web-X拿取user服務的連接，通過RPC接口調用user服務;

日志清理，服務監控，二進制備份的過程，也都與上述類似。

上述方案存在什么問題?

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

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

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

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

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

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

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

畫外音：ca，誰痛誰知道。

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

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

如何集中化管理集群信息呢?

不同發展階段的公司，實現的方式不一樣。

早期方案：全局配置。通

過全局配置文件，實現集群信息集中管理，舉例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/ 
owner.list : shenjian, ku 
 
[passport.web] 
ip.list : ip11, ip22, ip33 
port : 80 
bin.path : /passport.web/bin/ 
log.path : /passport.web/log/ 
conf.path : /passport.web/conf/ 
owner.list : shenjian, shuai 

集中維護集群信息之后：

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

畫外音：信息太多的話，global.config也要垂直拆分。

中期方案：服務化。

隨著公司業務的發展，隨著技術團隊的擴充，隨著技術體系的完善，通過集群信息管理服務，來維護集群信息的訴求原來越強烈。

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

如上圖，建立集群信息管理服務：

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

 

服務的核心接口是：

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

然后，統一通過服務來獲取與修改集群信息：

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

長期方案：配置中心平臺化。

集群信息服務可以解決大部分的耦合問題，但仍然有一個不足：集群信息變更時，無法反向實時通知關注方，集群信息發生了改變。更長遠的，要引入配置中心來解決。

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

 

總結

集群信息管理，是架構設計中非常容易遺漏的一環，但又是非常基礎，非常重要的基礎設施，一定要在早期規劃好：

• 傳統的方式，分散化管理集群信息，容易導致耦合;
• 集中管理集群信息，有全局配置，信息服務，配置中心三個階段;

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文