資訊專欄INFORMATION COLUMN
摘要：進(jìn)程間通過網(wǎng)絡(luò)組成拓?fù)溥@是進(jìn)程管理里最痛苦的部分。所以無論是不是有服務(wù)注冊(cè)和發(fā)現(xiàn)，對(duì)集群的拓?fù)浣＃F(xiàn)網(wǎng)狀態(tài)的可視化都是必不可少的。也就是說文章的標(biāo)題基礎(chǔ)設(shè)施服務(wù)化需要做哪些事情，我也不知道。
基礎(chǔ)設(shè)施服務(wù)化
所謂基礎(chǔ)設(shè)施服務(wù)化就是希望做到這個(gè)
當(dāng)用戶需要獲取某個(gè)基礎(chǔ)設(shè)施的時(shí)候，比如一個(gè)redis的集群，或者mysql的集群，可以無需在釘釘上找管理員，無需用郵件提申請(qǐng)。在web界面上自助就可以搞定。
為什么這個(gè)問題會(huì)特別？相比較一下這兩個(gè)場(chǎng)景：
1、segmentfault提供了一個(gè)寫博客的功能，我利用segmentfault開了一個(gè)自己的博客。
2、aws提供了一個(gè)mysql集群管理的功能，我在aws開了自己的mysql集群
從用戶體驗(yàn)來說有本質(zhì)區(qū)別嗎？不都是通過web界面申請(qǐng)，然后獲得了一個(gè)用tcp連接對(duì)外提供的服務(wù)嗎？兩者的區(qū)別在于
1、在segmentfault上申請(qǐng)博客是在已有的segmentfault的cpu和硬盤的資源池里切出來了一份屬于我的。這個(gè)過程不牽涉到新的進(jìn)程的啟動(dòng)。
2、而mysql集群的申請(qǐng)開通是需要新的機(jī)器，需要新的進(jìn)程。
“業(yè)務(wù)”和“運(yùn)維”的分野就在這里。業(yè)務(wù)就是在不啟動(dòng)新的進(jìn)程的情況下，用已有進(jìn)程切分資源給不同用戶使用。而運(yùn)維就是起停進(jìn)程，以達(dá)到擴(kuò)縮整個(gè)資源池大小，給用戶提供服務(wù)。只要我們做的事情里牽涉到了進(jìn)程的起停，我就認(rèn)為我們是在做運(yùn)維的工作，而不是在做業(yè)務(wù)邏輯。這些進(jìn)程管理相關(guān)的服務(wù)一般都會(huì)被羅列一下場(chǎng)景：
1、新版本發(fā)布，升級(jí)已有集群（停進(jìn)程，然后再起）
2、已有版本，部署新的集群（起進(jìn)程）
3、已有集群擴(kuò)容（起進(jìn)程）
4、已有集群縮容（停進(jìn)程）
5、已有集群的故障恢復(fù)（進(jìn)程死了，再拉新的）
所謂的“發(fā)布變更”，其實(shí)就是圍繞進(jìn)程管理組合出來的一堆服務(wù)。這些服務(wù)以http rest api之類的形式提供給用戶使用。
進(jìn)程管理的工作分解我們可以把所有的進(jìn)程管理工作按這個(gè)模型來理解
而且我絲毫不懷疑bash腳本套界面的有效性。它可以非常快地達(dá)到自助化管理的目的，極大提高用戶方的效率。從投入產(chǎn)出比的角度來說，我是支持這么來搞的。
但是運(yùn)維所有工作的考量應(yīng)該是有四方面的“效率”，“質(zhì)量”，“成本”，“安全” https://segmentfault.com/a/1190000002965517 。這種bash腳本套界面的做法就是典型的效率至上，其他都不管的做法。我相信這樣的做法是無法兼顧到質(zhì)量和安全。當(dāng)你看到一個(gè)系統(tǒng)里沉淀了幾千個(gè)bash腳本，被不同的web界面暴露出去了。你能保證這些bash腳本都是安全的？他們的組合使用的效率又是安全的？
假設(shè)我們放棄了直接把一個(gè)長長的bash腳本web化的想法。那么我們仔細(xì)來看看這些bash腳本都在干什么。概括起來可以分為四個(gè)部分
我們來分別看這四個(gè)組成部分都是在干什么。最佳的解決方案又是什么。
進(jìn)程鏡像的下發(fā)對(duì)于 golang 來說，進(jìn)程鏡像下發(fā)可能就是scp拷貝一個(gè)可執(zhí)行文件就行了。但是很多的進(jìn)程要能啟動(dòng)，需要本地有一對(duì)關(guān)聯(lián)的庫。
曾經(jīng)火過一段時(shí)間的 infrastructure as code，嘗試以描述依賴的方式把這個(gè)進(jìn)程鏡像下發(fā)和運(yùn)行時(shí)環(huán)境的問題描述清楚。但是構(gòu)建在os的包管理（apt-get，yum），各種語言的包管理（pip，npm）之上外加各種補(bǔ)丁的依賴管理系統(tǒng)到頭來還是浮沙之上筑高臺(tái)。
目前最流行的是docker。它確實(shí)根本上解決了單機(jī)的依賴管理問題。一個(gè)進(jìn)程該有一個(gè)什么樣的運(yùn)行時(shí)環(huán)境，一個(gè)docker鏡像就搞定了。
進(jìn)程拉起有標(biāo)配的god或者supervisord，絕對(duì)是一種福氣。沒有標(biāo)準(zhǔn)的進(jìn)程托管工具，需要自己寫各種拉起腳本的，非常低效，而且不容易做到健壯。這個(gè)方面還是首選 supervisord，把進(jìn)程的起停很容易就標(biāo)準(zhǔn)化了。
比進(jìn)程拉起這個(gè)動(dòng)作更復(fù)雜的一個(gè)問題是決定在哪里拉起這個(gè)進(jìn)程。所以有mesos，yarn這樣的資源管理工具。讓進(jìn)程在多個(gè)主機(jī)上更合理的分割資源。這個(gè)方面可以吹得很厲害，解決了很多成本云云。但是大部分情況下手工靜態(tài)分配進(jìn)程和主機(jī)的關(guān)系，足矣。省成本這個(gè)事情，行政命令比高科技管用多了。
進(jìn)程間通過網(wǎng)絡(luò)組成拓?fù)?/b>這是進(jìn)程管理里最痛苦的部分。當(dāng)我們啟動(dòng)了這些進(jìn)程之后，進(jìn)程之間是需要通過網(wǎng)絡(luò)互相通信的。如果兩個(gè)進(jìn)程是通過本地文件系統(tǒng)的ipc機(jī)制通信，我們可以建模地時(shí)候把兩個(gè)進(jìn)程變成一個(gè)進(jìn)程組，當(dāng)一個(gè)進(jìn)程看待。那么這個(gè)問題就是進(jìn)程A，要知道進(jìn)程B在哪里。進(jìn)程B又要知道進(jìn)程A在哪里。
傳統(tǒng)的做法是進(jìn)程A有自己的配置文件，這里要填進(jìn)程B的ip和端口。進(jìn)程B也有自己的配置文件，這里要填進(jìn)程A的ip和端口。所以就有一個(gè)很復(fù)雜的配置管理生成的問題。
更好的做法是讓進(jìn)程去做自動(dòng)的互相發(fā)現(xiàn)。無非就是進(jìn)程A把自己注冊(cè)到注冊(cè)表里，進(jìn)程B可以從注冊(cè)表里取到。無論是使用zookeeper，etcd還是consul，這個(gè)過程都是類似的。很多復(fù)雜一些的開源軟件，都會(huì)預(yù)設(shè)一個(gè)集群管理方式。比如kafka自己要求有一個(gè)zookeeper來管理其內(nèi)部的幾個(gè)節(jié)點(diǎn)。
即便是有了服務(wù)注冊(cè)和發(fā)現(xiàn)，也不是進(jìn)程隨便拉起就撒手不管了。服務(wù)注冊(cè)和發(fā)現(xiàn)可以減輕你管理整個(gè)網(wǎng)絡(luò)拓?fù)涞呢?fù)擔(dān)，但是不能代替你去規(guī)劃這個(gè)網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。進(jìn)程啟動(dòng)要加入到一個(gè)集群里做自發(fā)現(xiàn)，仍然需要知道兩個(gè)信息，我是什么角色的service，我在什么cluster里。把進(jìn)程劃分為不同的cluster，又分為不同類型的service仍然是要提前規(guī)劃的。而進(jìn)程都要掛在具體的cluster的具體的service下。只是說同類型的service啟動(dòng)多個(gè)進(jìn)程了，服務(wù)注冊(cè)和發(fā)現(xiàn)可以減輕一些這方面的管理負(fù)擔(dān)。
更復(fù)雜的集群可能要牽涉到跨cluster的互相訪問。也就是cluster組cluster。這個(gè)方面仍然是沒有最佳實(shí)踐的。比如codis集群內(nèi)，其實(shí)是由多個(gè)redis group組成。
當(dāng)我們面對(duì)這個(gè)一個(gè)網(wǎng)絡(luò)拓?fù)涞墓芾韱栴}的時(shí)候有兩個(gè)解法。進(jìn)程自身其實(shí)是有一個(gè)自身狀態(tài)描述了這個(gè)拓?fù)涞腶ctual state，另外還有一份存在于你的設(shè)計(jì)文檔也好，你的配置管理系統(tǒng)也好，是一個(gè) expected state。我們可以用腳本直接變更actual state，然后再去同步這些state回來到某個(gè)dashboard上。或者我們可以先改變dashboard上的expected state，然后再推倒出有哪些action需要做，去變更actual state。兩種方式都可以。但是不能只有腳本，而沒有任何的state的建模。如果只有腳本，我們對(duì)于集群狀態(tài)在變更之后實(shí)際上是什么情況是兩眼一抹黑的。我們認(rèn)為主從切換了，但是是不是主從切換了是不能有一個(gè)中心的dashboard可視的。這就很可怕了。
所以無論是不是有服務(wù)注冊(cè)和發(fā)現(xiàn)，對(duì)集群的拓?fù)浣＃F(xiàn)網(wǎng)狀態(tài)的可視化都是必不可少的。千萬不能只有一堆腳本，kuangkuangkuang執(zhí)行完了，實(shí)際線上是什么個(gè)狀態(tài)完全不知道。
更新與網(wǎng)絡(luò)拓?fù)湎嚓P(guān)的進(jìn)程狀態(tài)大部分的進(jìn)程狀態(tài)是不屬于運(yùn)維范疇的。比如安裝完了一個(gè)訂單管理系統(tǒng)，需要把城市列表導(dǎo)入到數(shù)據(jù)庫里。沒有人會(huì)認(rèn)為這個(gè)城市列表導(dǎo)入會(huì)是運(yùn)維工作的職責(zé)。但是安裝完了一個(gè)codis集群，需要把codis集群里的redis group與slot range對(duì)應(yīng)上，所有人都認(rèn)為這個(gè)應(yīng)該是運(yùn)維工作的一部分。為什么？根本原因是data partition的配置，與網(wǎng)絡(luò)拓?fù)涫窍嚓P(guān)的。因?yàn)榫W(wǎng)絡(luò)拓?fù)涫沁\(yùn)維來組的，所以凡是和網(wǎng)絡(luò)拓?fù)溆嘘P(guān)的配置，都和運(yùn)維有關(guān)系。
這個(gè)和前面的網(wǎng)絡(luò)相關(guān)的配置是類似的。只是在組網(wǎng)的時(shí)候，我們認(rèn)為一個(gè)service就是網(wǎng)絡(luò)的ip和端口兩個(gè)屬性是有價(jià)值的。在配置data partition的時(shí)候，我們還要知道service具體是負(fù)責(zé)了什么數(shù)據(jù)。是負(fù)責(zé)了熱數(shù)據(jù)還是冷數(shù)據(jù)。是負(fù)責(zé)哪個(gè)數(shù)據(jù)分片。如果我們的cluster和service建模得好，管理得好。這些屬性完全就是ip和端口之外擴(kuò)展的kv對(duì)而已。如果我們前一個(gè)工作做得不好，那么這些更復(fù)雜的狀態(tài)的管理就更加是一個(gè)災(zāi)難。
數(shù)據(jù)分片更復(fù)雜的一點(diǎn)是它是有狀態(tài)服務(wù)的狀態(tài)的體現(xiàn)。把一個(gè)group遷移一些slot到另外一個(gè)group，不僅僅是一個(gè)配置變換，不僅僅是進(jìn)程的起停，還包括這些配置對(duì)應(yīng)的實(shí)際數(shù)據(jù)的搬遷。
但這個(gè)問題仍然是一個(gè)狀態(tài)管理的問題。我們有一個(gè)注冊(cè)表登記了group對(duì)應(yīng)了哪些slot，這是一份登記的state。而這個(gè)group實(shí)際上是不是包含了這些slot，進(jìn)程自己心里有數(shù)，這是一份actual的state。本質(zhì)上還是state管理，actual state和expected state的同步問題。
總結(jié)現(xiàn)有的運(yùn)維的工具很好的解決了進(jìn)程管理中四個(gè)問題里最簡單的兩個(gè)問題，鏡像的下發(fā)（docker）和進(jìn)程拉起（supervisord）。但是對(duì)于組網(wǎng)和數(shù)據(jù)分片管理，這兩個(gè)state management問題，仍然有太多的open question。更多的解決方案是個(gè)例地，腳本化的解決一些問題。沒有一個(gè)framework來系統(tǒng)性地對(duì)集群狀態(tài)管理問題給一個(gè)解決方案。也就是說文章的標(biāo)題“基礎(chǔ)設(shè)施服務(wù)化需要做哪些事情”，我也不知道。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://m.specialneedsforspecialkids.com/yun/7974.html
摘要：云計(jì)算從概念萌芽期如今正在成為基礎(chǔ)設(shè)施的水和電。他們共同對(duì)云計(jì)算的下一步發(fā)展特點(diǎn)以及企業(yè)關(guān)注重點(diǎn)等問題進(jìn)行了討論。所以，在國內(nèi)說云計(jì)算發(fā)展的下一個(gè)階段似乎比下半場(chǎng)更加合適，那么下一個(gè)階段將有哪些新的特點(diǎn)呢各位嘉賓也提出了自己的看法。 云計(jì)算可以說是近幾年企業(yè)服務(wù)發(fā)展最快的領(lǐng)域之一，同時(shí)也是產(chǎn)業(yè)互聯(lián)網(wǎng)發(fā)展的基礎(chǔ)。云計(jì)算從概念萌芽期如今正在成為 IT 基礎(chǔ)設(shè)施的水和電。12 月 21 日，幾位云...
摘要：聯(lián)合創(chuàng)建青云后，林源承擔(dān)了數(shù)年首席架構(gòu)師的工作，目前擔(dān)任青云的產(chǎn)品總監(jiān)兼運(yùn)營副總裁。在未來，青云的客戶看不見青云，他們消費(fèi)的是我們合作伙伴提供的服務(wù)。 showImg(https://segmentfault.com/img/remote/1460000012292093?w=640&h=416); AI（人工智能）一詞，可能早已經(jīng)爛大街了，說起它，橋下貼膜的小哥也能和你說出個(gè)一二三來...
摘要：我們使用了很多的公共云資源，自己也建立了私有的云計(jì)算中心。那你們會(huì)給騰訊提供一些這方面的建議嗎會(huì)的，我們跟他們合作密切，我們之間的交流很頻繁。 Cadir Lee，現(xiàn)任Zynga CTO，統(tǒng)管公司的技術(shù)平臺(tái)和海量基礎(chǔ)架構(gòu)的研發(fā)和創(chuàng)新。他管理數(shù)據(jù)分析、網(wǎng)絡(luò)運(yùn)維、安全等方面的團(tuán)隊(duì)。在加入Zynga之前，他擔(dān)任Support.com的CTO11年之久，而Support.com也是他和Zynga創(chuàng)始...
摘要：摘要智能監(jiān)控是智能運(yùn)維的子領(lǐng)域，詳細(xì)分析。我和我的團(tuán)隊(duì)在阿里內(nèi)部的分工是橫向去看阿里巴巴業(yè)務(wù)指標(biāo)的監(jiān)控，我們就以這個(gè)話題展開。分享分為五個(gè)環(huán)節(jié)，從阿里巴巴不同的業(yè)態(tài)，特別是新的業(yè)態(tài)帶來的挑戰(zhàn)講起。 摘要：?智能監(jiān)控是智能運(yùn)維的子領(lǐng)域，詳細(xì)分析。 showImg(https://segmentfault.com/img/remote/1460000017348788); 作者簡介 王肇...
摘要：打好地基三年做架構(gòu)分析李寧沙爽盲目崇拜云計(jì)算有風(fēng)險(xiǎn)李寧沙爽盲目崇拜云計(jì)算有風(fēng)險(xiǎn)李寧沙爽年年末，沙爽離開聯(lián)想集團(tuán)來到李寧公司就任信息技術(shù)總監(jiān)一職，試用期滿后，代替轉(zhuǎn)正報(bào)告交上去的是他用三個(gè)月時(shí)間撰寫的頁李寧集團(tuán)未來三年組織業(yè)務(wù)規(guī)劃書。 提及家喻戶曉的李寧集團(tuán)，這家?guī)缀跻殉蔀閲蓑湴恋钠髽I(yè)目前正在將步伐邁向信息化道路。其中，信息技術(shù)系統(tǒng)部門功不可沒。李寧公司信息技術(shù)系統(tǒng)總監(jiān)沙爽表示，他的團(tuán)隊(duì)致力...
閱讀 2114·2021-11-05 09:42
閱讀 2858·2021-09-23 11:21
閱讀 2853·2019-08-30 14:00
閱讀 3319·2019-08-30 13:15
閱讀 470·2019-08-29 17:18
閱讀 3558·2019-08-29 16:29
閱讀 2756·2019-08-29 14:06
閱讀 2803·2019-08-23 14:41
