這一步都沒做，還想搞自動(dòng)化運(yùn)維？
監(jiān)控平臺(tái)，服務(wù)治理，調(diào)用鏈跟蹤，數(shù)據(jù)收集中心，自動(dòng)化測(cè)試… 很多公司在搞技術(shù)體系平臺(tái)化。可如果連第一步“集群信息集中管理”都沒做到，談平臺(tái)化為時(shí)尚早。
今天，和大家聊聊技術(shù)體系平臺(tái)化的基石，集群信息集中管理。
什么是集群?
互聯(lián)網(wǎng)典型分層架構(gòu)如下：
- web-server層;
- service層;
- db層與cache層;
為了保證高可用，每一個(gè)站點(diǎn)、服務(wù)、數(shù)據(jù)庫、緩存都會(huì)冗余多個(gè)實(shí)例，組成一個(gè)分布式的系統(tǒng)，集群則是一個(gè)分布式的物理形態(tài)。
更通俗的說，集群就是一堆機(jī)器，上面部署了提供相似功能的站點(diǎn)，服務(wù)，數(shù)據(jù)庫，或者緩存。
如上圖：
- web集群，由web.1和web.2兩個(gè)實(shí)例組成;
- service集群，由service.1/service.2/service.3三個(gè)實(shí)例組成;
- db集群，由mysql-M/mysql-S1/mysql-S2三個(gè)實(shí)例組成;
- cache集群，由cache-M/cache-S兩個(gè)實(shí)例組成;
與“集群”相對(duì)應(yīng)的是“單機(jī)”。
畫外音：緩存如果沒有高可用要求，可以是單機(jī)架構(gòu)，而不用非得是集群。
什么是集群信息?
一個(gè)集群，會(huì)包含若干信息(額，這算什么解釋)，例如：集群名稱，節(jié)點(diǎn)IP列表，二進(jìn)制目錄，配置目錄，日志目錄，負(fù)責(zé)人列表等，這些就是集群信息。
畫外音：集群節(jié)點(diǎn)IP列表，往往不是內(nèi)外IP列表，是內(nèi)網(wǎng)域名列表。
什么時(shí)候會(huì)用到集群信息呢?
很多場(chǎng)景，特別是線上操作，都會(huì)使用到各種集群信息，例如：自動(dòng)化上線，監(jiān)控，日志清理，二進(jìn)制與配置的備份，下游的調(diào)用等，都會(huì)用到集群信息。
這些場(chǎng)景，分別都是如何讀取集群信息的?
一般來說，早期會(huì)把集群信息寫在配置文件里。
例如，自動(dòng)化上線，有一個(gè)配置文件，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
自動(dòng)化上線的過程，則是：
- 把可執(zhí)行文件從ftp拉下來;
- 讀取集群IP列表;
- 讀取二進(jìn)制應(yīng)該部署的目錄;
- 把二進(jìn)制部署到線上;
- 逐臺(tái)重啟;
畫外音：還沒有實(shí)現(xiàn)自動(dòng)化腳本部署?趕緊照著這個(gè)流程，做自動(dòng)化改造吧。
又例如，web-X調(diào)用下游的user服務(wù)，又有一個(gè)配置文件，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啟動(dòng);
- web-X讀取user服務(wù)集群的IP列表與端口;
- web-X初始化user服務(wù)連接池;
- web-X拿取user服務(wù)的連接，通過RPC接口調(diào)用user服務(wù);
日志清理，服務(wù)監(jiān)控，二進(jìn)制備份的過程，也都與上述類似。
上述方案存在什么問題?
上述業(yè)務(wù)場(chǎng)景，對(duì)于集群信息的使用，有兩個(gè)最大的特點(diǎn)：
- 每個(gè)應(yīng)用場(chǎng)景，所需集群信息都不一樣(A場(chǎng)景需要集群abc信息，B場(chǎng)景需要集群def信息);
- 每個(gè)應(yīng)用場(chǎng)景，集群信息都寫在“自己”的配置文件里;
一句話總結(jié)：集群信息管理分散化。
這里最大的問題，是耦合，當(dāng)集群的信息發(fā)生變化的時(shí)候，有非常多的配置需要修改：
- deploy.user.service.config
- clean.log.user.service.config
- backup.bin.user.service.config
- monitor.config
- web-X.config
- …
這些配置里，user服務(wù)集群的信息都需要修改：
- 隨著研發(fā)、測(cè)試、運(yùn)維人員的流動(dòng)，很多配置放在哪里，逐步就被遺忘了;
- 隨著時(shí)間的推移，一些配置就被改漏了;
- 逐漸的，莫名其妙的問題出現(xiàn)了;
畫外音：ca，誰痛誰知道。
如何解決上述耦合的問題呢?
一句話回答：集群信息管理集中化。
如何集中化管理集群信息呢?
不同發(fā)展階段的公司，實(shí)現(xiàn)的方式不一樣。
早期方案：全局配置。通
過全局配置文件，實(shí)現(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/
- 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
集中維護(hù)集群信息之后：
- 任何需要讀取集群信息的場(chǎng)景，都從global.config里讀取;
- 任何集群信息的修改，只需要修改global.config一處;
- global.config會(huì)部署到任何一臺(tái)線上機(jī)器，維護(hù)和管理也很方便;
畫外音：信息太多的話，global.config也要垂直拆分。
中期方案：服務(wù)化。
隨著公司業(yè)務(wù)的發(fā)展，隨著技術(shù)團(tuán)隊(duì)的擴(kuò)充，隨著技術(shù)體系的完善，通過集群信息管理服務(wù)，來維護(hù)集群信息的訴求原來越強(qiáng)烈。
畫外音：慢慢的，配置太多了，通過global.config來修改配置太容易出錯(cuò)了。
如上圖，建立集群信息管理服務(wù)：
- info.db ：存儲(chǔ)集群信息;
- info.cache ：緩存集群信息;
- info.service ：提供集群信息訪問的RPC接口，以及HTTP接口;
- info.web ：集群信息維護(hù)后臺(tái);
服務(wù)的核心接口是：
- Info InfoService::getInfo(String ClusterName);
- Bool InfoService::setInfo(String ClusterName, String key, String value);
然后，統(tǒng)一通過服務(wù)來獲取與修改集群信息：
- 所有需要獲取集群信息的場(chǎng)景，都通過info.service提供的接口來讀取集群信息;
- 所有需要修改集群信息的場(chǎng)景，都通過info.web來操作;
長(zhǎng)期方案：配置中心平臺(tái)化。
集群信息服務(wù)可以解決大部分的耦合問題，但仍然有一個(gè)不足：集群信息變更時(shí)，無法反向?qū)崟r(shí)通知關(guān)注方，集群信息發(fā)生了改變。更長(zhǎng)遠(yuǎn)的，要引入配置中心來解決。
配置中心的細(xì)節(jié)，網(wǎng)上的分析很多，之前也撰文寫過，細(xì)節(jié)就不再本文展開。
總結(jié)
集群信息管理，是架構(gòu)設(shè)計(jì)中非常容易遺漏的一環(huán)，但又是非?；A(chǔ)，非常重要的基礎(chǔ)設(shè)施，一定要在早期規(guī)劃好：
- 傳統(tǒng)的方式，分散化管理集群信息，容易導(dǎo)致耦合;
- 集中管理集群信息，有全局配置，信息服務(wù)，配置中心三個(gè)階段;
【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
