集群信息管理，架構設計中最容易遺漏的一環
準備系統性介紹「技術體系規劃」了，這是第一篇。
監控平台，服務治理，調用鏈跟蹤，數據收集中心，自動化運維，自動化測試… 很多要講，卻沒想好從哪裡入手。
講Z平台，可能需要提前介紹Y服務；講Y服務，可能需要提前介紹X知識。
思來想去，準備從技術體系里，最容易被遺漏，非常基礎，卻又非常重要的「集群信息管理」開始介紹。
由於基礎，可能部分同學會覺得簡單；由於大家所在公司處於不同階段，所以在實現上會介紹不同階段的公司應該如何來實現。
還是一如既往的按照「架構師之路」的思路：
是什麼
什麼場景，為什麼會用到，存在什麼問題
常見方案及痛點
不同階段公司，不同實現方案
希望大夥有收穫。
一、啥是集群？
互聯網典型分層架構如下：
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兩個實例組成
與「集群」相對應的是「單機」。
畫外音：關於高可用架構，詳見文章《究竟啥才是互聯網架構「高可用」》。
畫外音：緩存如果沒有高可用要求，可能是單機架構，而不是集群。
二、集群信息
什麼是集群信息？
一個集群，會包含若干信息（額，這tm算什麼解釋），例如：
集群名稱
IP列表
二進位目錄
配置目錄
日誌目錄
負責人列表
畫外音：集群IP列表不建議直接使用IP，而建議使用內網域名，詳見文章《小小的IP，大大的耦合》。
什麼時候會用到集群信息呢？
很多場景，特別是線上操作，都會使用到各種集群信息，例如：
自動化上線
監控
日誌清理
二進位與配置的備份
下游的調用（額，這個最典型）
這些場景，分別都是如何讀取集群信息的？
一般來說，早期會把集群信息寫在配置文件里。
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列表
讀取二進位應該部署的目錄
把二進位部署到線上
逐台重啟
畫外音：啥，還沒有實現自動化腳本部署？還處在運維ssh到線上，手動執行命令，逐台機器人肉部署的刀耕火種階段？趕緊照著這個方案，做自動化改造吧。
又例如，web-X調用下游的user服務，又有一個配置文件，web-X.config，其內容配置了：
service.name : user.service
service.port : 8080
web-X調用user服務的過程，則是：
web-X啟動
web-X讀取user服務集群的IP列表與埠
web-X初始化user服務連接池
web-X拿取user服務的連接，通過RPC介面調用user服務
日誌清理，服務監控，二進位備份的過程，也都與上述類似。
三、存在什麼問題？
上述業務場景，對於集群信息的使用，有兩個最大的特點：
每個應用場景，所需集群信息都不一樣（A場景需要集群abc信息，B場景需要集群def信息）
每個應用場景，集群信息都寫在「自己」的配置文件里
一句話總結：集群信息管理分散化。
這裡最大的問題，是耦合，當集群的信息發生變化的時候，有非常多的配置需要修改：
這些配置里，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/
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會部署到任何一台線上機器，維護和管理也很方便
畫外音：額，當然，信息太多的話，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來操作
長期方案
集群信息服務可以解決大部分的耦合問題，但仍然有一個不足：集群信息變更時，無法反向實時通知關注方，集群信息發生了改變。更長遠的，要引入配置中心來解決。
配置中心的細節，網上的分析很多，之前也撰文寫過，細節就不再本文展開。
五、總結
集群信息管理，是架構設計中非常容易遺漏的一環，但又是非常基礎，非常重要的基礎設施，一定要在早期規劃好：
傳統的方式，分散化管理集群信息，容易導致耦合
集中管理集群信息，有全局配置，信息服務，配置中心三個階段
六、調研
調研一、對於集群信息管理，你的感受是：
ca，沒考慮過這個問題，一直是分散式管理
在使用全局配置文件
在使用信息管理服務
在使用配置中心
調研二、對於自動化運維，你的感受是：
ca，啥是運維，都是研發在線上亂搞
有專門的運維，但一直是人肉運維
運維在使用腳本，實現了自動化
運維都下崗了，在使用平台，實現了平台化
嗯，有道理，得轉發一下。
TAG:架構師之路 |