準備系統性介紹「技術體系規劃」了,這是第一篇。mysql
監控平臺,服務治理,調用鏈跟蹤,數據收集中心,自動化運維,自動化測試… 不少要講,卻沒想好從哪裏入手。web
講Z平臺,可能須要提早介紹Y服務;講Y服務,可能須要提早介紹X知識。sql
思來想去,準備從技術體系裏,最容易被遺漏,很是基礎,卻又很是重要的「集羣信息管理」開始介紹。數據庫
因爲基礎,可能部分同窗會以爲簡單;因爲你們所在公司處於不一樣階段,因此在實現上會介紹不一樣階段的公司應該如何來實現。緩存
仍是一如既往的按照「架構師之路」的思路:微信
是什麼架構
什麼場景,爲何會用到,存在什麼問題框架
常見方案及痛點運維
不一樣階段公司,不一樣實現方案ssh
但願大夥有收穫。
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、調研
調研一、對於集羣信息管理,你的感覺是:
ca,沒考慮過這個問題,一直是分散式管理
在使用全局配置文件
在使用信息管理服務
在使用配置中心
調研二、對於自動化運維,你的感覺是:
ca,啥是運維,都是研發在線上亂搞
有專門的運維,但一直是人肉運維
運維在使用腳本,實現了自動化
運維都下崗了,在使用平臺,實現了平臺化
嗯,有道理,得轉發一下。
下期預告:監控平臺架構細節
本期推薦:框架組件,究竟要不要自研?
本文分享自微信公衆號 - 架構師之路(road5858)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。