[[149634]]

【引自Reboot運(yùn)維開發(fā)的博客】寫在前面

　　我從事運(yùn)維自動化相關(guān)的工作，也已經(jīng)8年了。當(dāng)初剛開始做的時候，運(yùn)維開發(fā)(devops)這詞還不火，很少人知道。國內(nèi)對運(yùn)維的理解，也就是機(jī)房、服務(wù)器、苦逼的7*24小時值班。甚至當(dāng)時還流傳著段子，招運(yùn)維要人高馬大，扛得動服務(wù)器。

　　很幸運(yùn)的主導(dǎo)了兩個一線互聯(lián)網(wǎng)公司的公司級的運(yùn)維自動化。這倆公司的服務(wù)器，都是幾十萬臺級的，IDC都是幾十個。很多事情都是摸索著來。一路走來也形成了一些對運(yùn)維自動化的理解。***家公司好容易做的七七八八的時候，到第二家實(shí)施發(fā)現(xiàn)原有的很多理解都被打爛了重新來。但這種經(jīng)歷反而凝練了一些經(jīng)驗(yàn)。我個人性格原因，不喜歡到外面去講。偶爾實(shí)在沒法推辭過去的，也誠惶誠恐的準(zhǔn)備，到***發(fā)現(xiàn)很多干貨還是沒辦法一言以蔽之。***留在外面的都是一些只言片語，不成系統(tǒng)，更不敢說能指導(dǎo)多少。

　　終于下定決心要把我個人的一些理解，通過系列文章來寫一寫。文筆有限，可能寫的不盡人意。也歡迎大家加入運(yùn)維開發(fā)討論交流群來交流，群號：365534424

　　廢話少說，直接上文。

　　庖丁解監(jiān)控(一)

　　我始終認(rèn)為監(jiān)控對于運(yùn)維來說，猶如眼睛對人來說一樣重要。不管說的多么高大上，運(yùn)維工作里面很大一部分還是響應(yīng)型的工作。來自于架構(gòu)調(diào)整、服務(wù)變更或者來自于監(jiān)控。說監(jiān)控是整個運(yùn)維或者服務(wù)生命周期里面最重要的一環(huán)都不為過。從事前發(fā)現(xiàn)，預(yù)警或者故障報警，到事后提供監(jiān)控現(xiàn)場供回溯追查，監(jiān)控系統(tǒng)貫穿了運(yùn)維整個環(huán)節(jié)。怎么才能有一副好視力，今天我們就來稍微談?wù)劇?/p>

　　正因?yàn)楸O(jiān)控系統(tǒng)如此重要和通用，所以業(yè)內(nèi)最成熟、最多的產(chǎn)品也是監(jiān)控系統(tǒng)。商用的、開源的監(jiān)控系統(tǒng)比比皆是。也有一些很優(yōu)秀的開源系統(tǒng)應(yīng)用很廣泛。比如Zabbix、cacti、nagios、ganglia等。對于使用開源系統(tǒng)，還是自己開發(fā)(相信看這個文章的，應(yīng)該都不會有購買監(jiān)控系統(tǒng)的打算)，是使用者自己決定的。業(yè)務(wù)和團(tuán)隊規(guī)模都不足夠的時候，直接拿來主義，開源的系統(tǒng)能解決基本問題，性價比高。業(yè)務(wù)如果后期發(fā)展的好，規(guī)?？焖贁U(kuò)大，復(fù)雜度迅速增加的情況下，開源系統(tǒng)就難以為繼了。具體表現(xiàn)在時效性、擴(kuò)展性、二次開發(fā)、支持的服務(wù)規(guī)模(或者叫系統(tǒng)容量)、良好的權(quán)限控制等各方面。

　　從上面幾點(diǎn)來看，一個監(jiān)控系統(tǒng)需要具備的是數(shù)據(jù)采集、擴(kuò)展性、告警管理、高可用、歷史數(shù)據(jù)存儲與展示、權(quán)限管理等幾個方面。

　　監(jiān)控本質(zhì)上就是對被監(jiān)控對象的狀態(tài)進(jìn)行判定。這個監(jiān)控對象可以是服務(wù)器、交換機(jī)，也可以是一個幾千臺服務(wù)器的集群，還可以是帶寬、CPU利用率，甚至深入到服務(wù)內(nèi)部，監(jiān)控服務(wù)內(nèi)部的進(jìn)程、線程、cache***率等。

　　監(jiān)控對象多種多樣，既有實(shí)體的，也有虛擬的。 對被監(jiān)控對象的狀態(tài)進(jìn)行判定，這句話里面有三個要素。被監(jiān)控對象、狀態(tài)、判定。所以監(jiān)控系統(tǒng)要能夠適配足夠多的監(jiān)控對象類型、收集并能轉(zhuǎn)換為可衡量的狀態(tài)值，才能支持下一步的判定動作。例如，一臺服務(wù)器上的nginx服務(wù)的連接數(shù)。服務(wù)器上的nginx服務(wù)，就是被監(jiān)控的對象;連接數(shù)就是被監(jiān)控對象的指標(biāo)，那么狀態(tài)呢?我們可以定義為，超過1萬就是不正常，否則是正常。

　　從這個角度做框，我們來看看監(jiān)控系統(tǒng)的核心指標(biāo)都有哪些。首先是能監(jiān)控的對象范圍要越多越好(當(dāng)然你可以說小而精的也挺美。但維護(hù)多套監(jiān)控系統(tǒng)也是代價)。也就是數(shù)據(jù)采集，能采集的渠道、支持的方式、采集的指標(biāo)越多越好。

　　關(guān)于擴(kuò)展性的定義

　　可伸縮性(可擴(kuò)展性)是一種對軟件系統(tǒng)計算處理能力的設(shè)計指標(biāo)，高可伸縮性代表一種彈性，在系統(tǒng)擴(kuò)展成長過程中，軟件能夠保證旺盛的生命力，通過很少的改動甚至只是硬件設(shè)備的添置，就能實(shí)現(xiàn)整個系統(tǒng)處理能力的線性增長，實(shí)現(xiàn)高吞吐量和低延遲高性能。

　　可伸縮性和純粹性能調(diào)優(yōu)有本質(zhì)區(qū)別， 可伸縮性是高性能、低成本和可維護(hù)性等諸多因素的綜合考量和平衡，可伸縮性講究平滑線性的性能提升，更側(cè)重于系統(tǒng)的水平伸縮，通過廉價的服務(wù)器實(shí)現(xiàn)分布式計算；而普通性能優(yōu)化只是單臺機(jī)器的性能指標(biāo)優(yōu)化。他們共同點(diǎn)都是根據(jù)應(yīng)用系統(tǒng)特點(diǎn)在吞吐量和延遲之間進(jìn)行一個側(cè)重選擇，當(dāng)然水平伸縮分區(qū)后會帶來CAP 定理約束。

　　可擴(kuò)展與過度設(shè)計的矛盾

　　具體討論到監(jiān)控系統(tǒng)的可擴(kuò)展性，我們這里特指系統(tǒng)可以隨著被監(jiān)控對象的規(guī)模擴(kuò)大而無需對架構(gòu)做大的變更修改。一千臺服務(wù)器的時候，是這個架構(gòu)，一萬臺服務(wù)器的時候還是這個架構(gòu)，***十萬臺的時候只需要增加服務(wù)器就可以，架構(gòu)還是那個架構(gòu)。聽起來很棒吧!這也是每個系統(tǒng)架構(gòu)設(shè)計者的夢想。但現(xiàn)實(shí)照進(jìn)理想的時候，發(fā)現(xiàn)理想很殘酷。首先是對于設(shè)計者來說，當(dāng)他在一家只有幾百臺服務(wù)器規(guī)模的公司時，很難去想到自己的系統(tǒng)可能有一天會在跑在幾萬臺的服務(wù)器規(guī)模上。這里面也有一個架構(gòu)設(shè)計的原則，就是要盡量避免過度設(shè)計。如果一個幾百臺服務(wù)器規(guī)模的公司的運(yùn)維開發(fā)，對他的老板說要做一個系統(tǒng)可以支撐幾萬臺服務(wù)器，但因此要多花了多少時間去架構(gòu)和重構(gòu)，我想老板會認(rèn)為自己的運(yùn)維開發(fā)一定是瘋了。架構(gòu)原則之一也是要盡量避免過度設(shè)計。

　　但軟件設(shè)計依然還是推崇良好的架構(gòu)、良好的可擴(kuò)展性。否則架構(gòu)設(shè)計的價值就會打很大的折扣，代碼復(fù)用和系統(tǒng)實(shí)現(xiàn)成本會隨著規(guī)模的擴(kuò)大而線性增長。良好的架構(gòu)可以通過迭代得出之后，反過來指導(dǎo)低階的系統(tǒng)設(shè)計。但低階的無法預(yù)測高階的。這就是架構(gòu)的用處之一。所以這里稍后我會介紹一下，我對于監(jiān)控系統(tǒng)架構(gòu)的一些經(jīng)驗(yàn)和心得。

　　一個稱職的設(shè)計者，是可以站在幾百臺服務(wù)器的規(guī)模時，考慮到幾千臺的情況的。但他考慮幾萬臺的話就有點(diǎn)過度了。這里并非說能支撐幾萬臺的系統(tǒng)架構(gòu)不優(yōu)秀。只是如果他不知道，那也沒必要過度考慮。如果能提前知道，甄嬛就會說，那顯然是極好的。

　　但很顯然需要考慮的內(nèi)容會越來越多。幾十臺的時候，你可能只需要考慮一個機(jī)房了，幾百臺的時候會有2、3個機(jī)房，當(dāng)幾千臺的時候可能依然在10個IDC以內(nèi)，但當(dāng)幾萬臺的時候很可能已經(jīng)超過15個IDC了。而且，地理位置的分布會更廣泛，由此而帶來的運(yùn)營商的覆蓋、網(wǎng)絡(luò)的復(fù)雜度、業(yè)務(wù)的復(fù)雜度也會完全不同。非逼著一個運(yùn)維開發(fā)去完全臆想著來做是不現(xiàn)實(shí)的。他沒有經(jīng)歷過實(shí)際的這種需求場景，是沒有辦法考慮到這樣那樣的各種問題的。所以我完全理解一些大公司對于開源項(xiàng)目的態(tài)度。好一點(diǎn)的可能拿來改改用，進(jìn)一步可能單獨(dú)拉一個分支開始改，更甚的就改的完全和主干不一樣了 ，其實(shí)還有就是自己造輪子的。但有時候就是這樣，自己不造輪子，開源的輪子用著的確不好使。

　　監(jiān)控的可擴(kuò)展性

　　具體到監(jiān)控系統(tǒng)，可擴(kuò)展性體現(xiàn)在哪些方面呢?我們從頭捋一下。監(jiān)控系統(tǒng)的輸入是監(jiān)控到的各項(xiàng)監(jiān)控數(shù)據(jù)。這些數(shù)據(jù)經(jīng)過一系列的處理，最終存儲下來用于事后分析和離線分析，同時更主要的作用是要實(shí)時的報警。整個過程我們可以視為是一個流式計算的過程。說到流式計算其實(shí)大家想到的是storm這些。這倒是另外一個我曾經(jīng)想過的思路，就是把所有處理過程放到strom上去。balabalabala.... 說遠(yuǎn)了。但我們仔細(xì)去看，strom也好，流式計算平臺也罷，都是分布式的。分布式架構(gòu)的一個特性就是良好的擴(kuò)展性。隨著服務(wù)器規(guī)模的擴(kuò)大，對于中間的數(shù)據(jù)處理層的可擴(kuò)展性要求，就是計算能力要能具備擴(kuò)展性。簡單來說就是數(shù)據(jù)多了，通過加服務(wù)器或者升級服務(wù)器就能搞定。

　　還有幾個邊界的地方需要把擴(kuò)展性支持好。***個就是入口。或者叫做數(shù)據(jù)的接收口。外面的數(shù)據(jù)源源不斷的進(jìn)入，如果要想做到擴(kuò)展性良好，***個需要考慮的就是接收環(huán)節(jié)。數(shù)據(jù)可以走TCP、UDP、SNMP、HTTP等多種協(xié)議進(jìn)入到監(jiān)控系統(tǒng)?？紤]到數(shù)萬服務(wù)器的規(guī)模，這個地方比較考驗(yàn)技術(shù)底子。如果走SNMP、HTTP當(dāng)然可以，但這兩個協(xié)議都走在應(yīng)用層，必然會帶來額外的開銷。拿HTTP舉例子，我們拿Nginx或者apache做server，其實(shí)天然帶有可擴(kuò)展性。數(shù)據(jù)收到以后，存到一個存儲即可(不管這個存儲是緩存還是***存儲)。這個過程，不帶有狀態(tài)，所以天然具有可擴(kuò)展性。一個Nginx 實(shí)例扛不住了，再來一個，再來一個，再來十個。這樣就解決了接口的可擴(kuò)展問題。

　　另外一個可擴(kuò)展是存儲環(huán)節(jié)。這個存儲主要是監(jiān)控數(shù)據(jù)的持久化存儲。前面我們說，數(shù)據(jù)接收、計算環(huán)節(jié)都可以通過一些方式支持可擴(kuò)展。那存儲必然會成為一個瓶頸。這個在很多系統(tǒng)里面都是這樣，前端可以通過Web Server實(shí)現(xiàn)可擴(kuò)展，但最終大家都跑到一個數(shù)據(jù)庫上讀寫。哪怕是讀寫分離的，還是一個主庫。主庫壓力山大。

　　這個地方我推薦用一些分布式存儲來解決這個問題。但不是很推薦mango這種比較奇葩的。因?yàn)閷懭氲哪芰Σ皇呛芎?。雖然它后來又有一些改進(jìn)方案來緩解這個問題，但注意，只是緩解。

　　綜上，對于可擴(kuò)展性，我們的思路是：分布式、無狀態(tài)。（未完待續(xù)）