[[149855]]

【引自Reboot運(yùn)維開發(fā)的博客】我借用一個(gè)高可用性的定義：高可用性H.A.(High Availability)指的是通過盡量縮短因日常維護(hù)操作(計(jì)劃)和突發(fā)的系統(tǒng)崩潰(非計(jì)劃)所導(dǎo)致的停機(jī)時(shí)間，以提高系統(tǒng)和應(yīng)用的可用性。它與被認(rèn)為是不間斷操作的容錯(cuò)技術(shù)有所不同。HA系統(tǒng)是目前企業(yè)防止核心計(jì)算機(jī)系統(tǒng)因故障停機(jī)的最有效手段。

那么高可用，就是高可用性良好的系統(tǒng)。多少算高呢？我以前待過的BAT某公司喜歡用小數(shù)點(diǎn)以后幾個(gè)9來衡量。當(dāng)然小數(shù)點(diǎn)前面默認(rèn)就是99。大家普遍認(rèn)為4個(gè)9是還不錯(cuò)的，5個(gè)9是核心業(yè)務(wù)應(yīng)該具備的。怎么計(jì)算呢？這個(gè)我后面也可以說一說算法。

對于運(yùn)維工程師來說，要是能運(yùn)維一個(gè)可用性非常高的系統(tǒng)，我想是一件幸事。系統(tǒng)能高可用，運(yùn)維處理報(bào)警的優(yōu)先級就不用那么高了。大冬天晚上收個(gè)報(bào)警，也不用立刻從被窩里面爬起來連VPN處理了。可用性越高，運(yùn)維工程師睡覺越安心。

影響高可用的因素與計(jì)算方式

影響可用性的因素都有哪些?讓我們來捋捋。一個(gè)服務(wù)分為軟件、硬件。拿一個(gè)網(wǎng)站來講解。

假設(shè)有個(gè)網(wǎng)站，域名是www.51reboot.com。部署了一個(gè)nginx，部署在一臺(tái)服務(wù)器上，這臺(tái)服務(wù)器在一個(gè)叫做zw的電信機(jī)房。

用戶從瀏覽器輸入www.51reboot.com開始，直到他在瀏覽器上能打開這個(gè)網(wǎng)頁內(nèi)容為止，有哪些步驟?

第一步，域名解析

第二步，向著服務(wù)器發(fā)起HTTP請求

第三步，請求走網(wǎng)絡(luò)，到達(dá)服務(wù)器所在機(jī)房的交換機(jī)

第四步，數(shù)據(jù)走幾層交換機(jī)之后，到達(dá)服務(wù)器網(wǎng)卡

第五步，網(wǎng)卡數(shù)據(jù)經(jīng)過OS，到達(dá)Nginx

第六步，Nginx收到HTTP請求

第七步，Nginx調(diào)用ThinkPHP框架(這里假定是這個(gè)框架)

第八步，PHP連接Mysql數(shù)據(jù)庫獲取數(shù)據(jù)

第九步，PHP處理數(shù)據(jù)

第十步，Nginx返回?cái)?shù)據(jù)到用戶端

第十一步，用戶端瀏覽器完整接收數(shù)據(jù)之后，渲染完畢

粗略的分為11個(gè)步驟。這里涉及：DNS、服務(wù)器、交換機(jī)、OS、Nginx、ThinkPHP、PHP、Mysql

服務(wù)器又可以分為：磁盤，以及其它部件如CPU、內(nèi)存。之所以這樣分，是因?yàn)榇疟P作為存儲(chǔ)部件是最容易壞的一個(gè)部件。

好了，我們接下來算一算，51reboot這個(gè)網(wǎng)站的可用性是多少。一次可用，相當(dāng)于上面的十一個(gè)步驟都得正常才叫可用。那么就要考慮了，DNS的可用性是多少，服務(wù)器不宕機(jī)(可用性)是多少、Nginx之類的軟件的可用性是多少、Mysql、磁盤的可用性是多少、網(wǎng)絡(luò)的可用性是多少等等。這些可用性的乘積，就是該網(wǎng)站的可用性。

這里還沒有考慮更多實(shí)際情況。比如，Mysql如果和Web端不在同一臺(tái)機(jī)器上、甚至不在同一個(gè)機(jī)房，或者部署的Nginx實(shí)例不止1個(gè)，等等。

上面我們講了可用性怎么計(jì)算。下面我們來看看監(jiān)控系統(tǒng)的高可用。

先定性，再定量

這是我的原則，事情都是先定性，看是否有必要，再定量，看需要定到多少，具體量化。監(jiān)控系統(tǒng)本身是監(jiān)控別的服務(wù)和系統(tǒng)是否正常運(yùn)行的。如果監(jiān)控系統(tǒng)自身可用性不足，會(huì)嚴(yán)重影響監(jiān)控效果。甚至可以說就是沒有什么用處，有大隱患。

這里還涉及了另外一個(gè)問題，就是監(jiān)控系統(tǒng)自身的監(jiān)控。以后會(huì)開篇幅來講。

前面說了，監(jiān)控系統(tǒng)本身必須高可用。那下面我們就看這個(gè)高可用需要怎么量化。讀者覺得應(yīng)該達(dá)到小數(shù)點(diǎn)之后幾個(gè)9?我個(gè)人覺得至少2個(gè)9。也就是 99.99%。否則業(yè)務(wù)部門的兄弟們急了，因?yàn)樗麄兊南到y(tǒng)如果要求是99.999%，沒人能證明啊！監(jiān)控系統(tǒng)本身才是99.99%。

如何達(dá)到高可用99.99%

這是今天這篇要討論的另外一個(gè)核心問題了。要達(dá)到高可用性，還要看系統(tǒng)的架構(gòu)。按照有沒有單點(diǎn)來區(qū)分，系統(tǒng)有兩類，一類是有單點(diǎn)的架構(gòu)，一類是沒有單點(diǎn)的架構(gòu)。講到這里我們有必要說一下什么叫做單點(diǎn)。單點(diǎn)簡單來說就是系統(tǒng)里面的某個(gè)部位，它在系統(tǒng)里面部署的時(shí)候，是一個(gè)唯一存在。這個(gè)唯一存在不能擴(kuò)展性的部署一個(gè)兄弟實(shí)例出來。這種唯一存在將來就最有可能是系統(tǒng)里面的老大難，因?yàn)樗隽藛栴}，沒有兄弟能頂上。

但，我又要說但是了。沒有單點(diǎn)，不代表說完全百分之百的沒有問題。例如，我們采用Hash的辦法，負(fù)載均衡的方式，部署了2個(gè)Nginx實(shí)例。當(dāng)其中一個(gè)實(shí)例掛掉的時(shí)候，僅影響了50%的請求。不能算整個(gè)系統(tǒng)掛掉了。但這個(gè)系統(tǒng)的穩(wěn)定性依然堪憂，我們不能說它的可用性有多高。 如果Hash計(jì)算能夠結(jié)合了實(shí)例的健康狀態(tài)，不健康的自動(dòng)從hash計(jì)算的池子里面摘掉，那可用性就大大提升了。

綜上，以及綜合我們上一篇，監(jiān)控系統(tǒng)要想達(dá)到高可用，必須要采用去中心化的架構(gòu)來做。就是讓整個(gè)系統(tǒng)里面沒有任何一個(gè)環(huán)節(jié)是單點(diǎn)。因?yàn)閱吸c(diǎn)就意味著瓶頸，意味著可用性提升很難很復(fù)雜，不容易做高。

具體說怎么才能去單點(diǎn)。我們從監(jiān)控系統(tǒng)本身的數(shù)據(jù)流來分析。

數(shù)據(jù)采集，這個(gè)要分類來說。一個(gè)是帶內(nèi)的，跑在OS上的代理Agent。這個(gè)的高可用，是另外一個(gè)領(lǐng)域的事情，就是怎么寫一個(gè)高可用的、魯棒性非常好的客戶端。我們以后分開篇幅說。

另外是帶外的。比如，HTTP或者端口監(jiān)控，或者存活監(jiān)控。我們拿存活監(jiān)控來舉例吧！比如說，我們通過ping的方式，來監(jiān)控服務(wù)器是否存活。那么，我們需要一個(gè)批量發(fā)ping包的探測器。這個(gè)也是一個(gè)數(shù)據(jù)采集端。只是沒有在OS上來采集。當(dāng)然它也存在魯棒性的問題，但這是另外一個(gè)領(lǐng)域的事情，我們這一篇不談。這個(gè)客戶端，如果它掛了，可想而知，被它監(jiān)控的服務(wù)器都失去監(jiān)控了。所以，我們要提高Ping監(jiān)控模塊或者叫環(huán)節(jié)的可用性。一個(gè)最簡單辦法，我們用兩個(gè)監(jiān)控點(diǎn)來監(jiān)控同一批服務(wù)器。但新的問題又來了，倆監(jiān)控點(diǎn)監(jiān)控同一臺(tái)服務(wù)器，什么情況下可以斷定這個(gè)服務(wù)器掛了呢？這個(gè)是另外一個(gè)監(jiān)控?cái)?shù)據(jù)合并的問題，我們也放到以后的篇章里面去討論。另外一個(gè)提高可用性的辦法，就是ping監(jiān)控點(diǎn)部署兩個(gè)，但兩個(gè)之間不要同時(shí)生效，但兩個(gè)節(jié)點(diǎn)之間有心跳，一個(gè)掛了，另外一個(gè)接管，也是一個(gè)辦法，但切換略復(fù)雜。

數(shù)據(jù)采集回來了，要做處理。這個(gè)處理或者叫計(jì)算環(huán)節(jié)的高可用，有不少現(xiàn)成的辦法。第一，部署兩個(gè)計(jì)算實(shí)例，但兩個(gè)實(shí)例需要能互備或者同時(shí)發(fā)揮作用。第二，純分布式辦法。

存儲(chǔ)和Web的分布式方案就更多了。

還有一個(gè)最關(guān)鍵的地方，如何實(shí)現(xiàn)無狀態(tài)。只有無狀態(tài)了，才能達(dá)到簡單的部署切換，就可以支撐高可用。這個(gè)問題我們留待之后來講。（未完待續(xù)）