集羣信息管理，架構設計中最容易遺漏的一環

準備系統性介紹「技術體系規劃」了，這是第一篇。

監控平臺，服務治理，調用鏈跟蹤，數據收集中心，自動化運維，自動化測試… 不少要講，卻沒想好從哪裏入手。

講Z平臺，可能須要提早介紹Y服務；講Y服務，可能須要提早介紹X知識。

思來想去，準備從技術體系裏，最容易被遺漏，很是基礎，卻又很是重要的「集羣信息管理」開始介紹。

因爲基礎，可能部分同窗會以爲簡單；因爲你們所在公司處於不一樣階段，因此在實現上會介紹不一樣階段的公司應該如何來實現。

仍是一如既往的按照「架構師之路」的思路：

• 是什麼
• 什麼場景，爲何會用到，存在什麼問題
• 常見方案及痛點
• 不一樣階段公司，不一樣實現方案
  但願大夥有收穫。

1、啥是集羣？

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

• 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兩個實例組成

與「集羣」相對應的是「單機」。

畫外音：關於高可用架構，詳見文章《究竟啥纔是互聯網架構「高可用」》。
畫外音：緩存若是沒有高可用要求，多是單機架構，而不是集羣。

2、集羣信息

什麼是集羣信息？

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

• 集羣名稱
• IP列表
• 二進制目錄
• 配置目錄
• 日誌目錄
• 負責人列表
  畫外音：集羣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列表
• 讀取二進制應該部署的目錄
• 把二進制部署到線上
• 逐臺重啓
  畫外音：啥，尚未實現自動化腳本部署？還處在運維ssh到線上，手動執行命令，逐臺機器人肉部署的刀耕火種階段？趕忙照着這個方案，作自動化改造吧。

又例如，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服務

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

3、存在什麼問題？

上述業務場景，對於集羣信息的使用，有兩個最大的特色：

• 每一個應用場景，所需集羣信息都不同（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，誰痛誰知道

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

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

4、如何集中化管理集羣信息

如何集中化管理集羣配置信息，不一樣發展階段的公司，實現的方式不同。

早期方案

經過全局配置文件，實現集羣信息集中管理，舉例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來操做

長期方案

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

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

5、總結

集羣信息管理，是架構設計中很是容易遺漏的一環，但又是很是基礎，很是重要的基礎設施，必定要在早期規劃好：
傳統的方式，分散化管理集羣信息，容易致使耦合
集中管理集羣信息，有全局配置，信息服務，配置中心三個階段

6、調研

調研1、對於集羣信息管理，你的感覺是：

• ca，沒考慮過這個問題，一直是分散式管理
• 在使用全局配置文件
• 在使用信息管理服務
• 在使用配置中心

調研2、對於自動化運維，你的感覺是：

• ca，啥是運維，都是研發在線上亂搞
• 有專門的運維，但一直是人肉運維
• 運維在使用腳本，實現了自動化
• 運維都下崗了，在使用平臺，實現了平臺化

嗯，有道理，得轉發一下。

下期預告：監控平臺架構細節本期推薦：框架組件，究竟要不要自研？