• 可用性(availability)是關(guān)于系統(tǒng)可供使用時間的表述，以不可用的時間為衡量指標(biāo)。不可用時間越短，可用性越高。通常用n個9來描述。比如4個9的可用性，則是指一年中不可用時間在52分鐘內(nèi)，平均每周不可用時間在1分鐘。
• 可靠性(reliablity)是關(guān)于系統(tǒng)無故障時間間隔的描述，以發(fā)生故障的次數(shù)為衡量指標(biāo)，故障次數(shù)越少，可靠性越高
• 可維護(hù)性(maintainability)系統(tǒng)發(fā)生故障后，恢復(fù)的時間來描述。時間越短，可維護(hù)性越高。

從上面三者關(guān)系看出，服務(wù)的可靠性、可維護(hù)性越高，可用性就越高。這就要求我們在服務(wù)開發(fā)和管理中做到：提高服務(wù)系統(tǒng)的穩(wěn)定性、改善軟件的可管理性和可維護(hù)性。

?

對于SAE云計算平臺而言，可用性包含三個方面：SAE自身服務(wù)可用性、網(wǎng)絡(luò)可用性、SAE平臺上數(shù)據(jù)可用性。

?

軟件是互聯(lián)網(wǎng)服務(wù)的載體。良好的軟件對于服務(wù)的可用性至關(guān)重要。從可用性定義來看，我們在軟件設(shè)計時，既要考慮可靠性，又要考慮可維護(hù)性。

?

可靠性：這主要體現(xiàn)在軟件本身的穩(wěn)定性和容錯性上。軟件的穩(wěn)定性很大程度上取決于代碼質(zhì)量，設(shè)計再優(yōu)良的系統(tǒng)都有可能在實(shí)現(xiàn)上質(zhì)量控制不好而導(dǎo)致失敗。軟件的容錯則主要體現(xiàn)在兩個方面：避免單點(diǎn)的高可用設(shè)計和自治獨(dú)立原則。軟件系統(tǒng)要做到足夠健壯,在發(fā)生一些硬件或網(wǎng)絡(luò)故障時就需要能夠做到冗余，繼續(xù)提供服務(wù)。即發(fā)生故障的次數(shù)足夠低

?

比如某個服務(wù)，可能有3個系統(tǒng)單元。每個單元都不應(yīng)該存在單點(diǎn)，某個服務(wù)器宕機(jī)不應(yīng)當(dāng)導(dǎo)致服務(wù)不可用。由于IDC故障的頻繁，現(xiàn)在越來越多的設(shè)計在考慮當(dāng)某個IDC不可用時，服務(wù)要能夠繼續(xù)提高服務(wù)，即跨IDC機(jī)房的高可用。另外軟件設(shè)計時要求足夠自治獨(dú)立，不可過多依賴網(wǎng)絡(luò)和其他服務(wù)單元，對于互聯(lián)網(wǎng)服務(wù)，阻塞是較大的敵人，在一個系統(tǒng)中由于一個微不足道的連接阻塞，而導(dǎo)致整個系統(tǒng)服務(wù)不可用，這樣的例子實(shí)在是太多，所以對于互聯(lián)網(wǎng)服務(wù)，需要牢記：服務(wù)要足夠自治獨(dú)立，避免阻塞。

?

下圖簡單說明了SAE平臺的負(fù)載均衡服務(wù)是如何避免單點(diǎn)故障的。

可維護(hù)性：軟件要易于管理維護(hù)，能夠和現(xiàn)有的運(yùn)維系統(tǒng)整合，比如說配置管理、日志管理等，避免自立規(guī)范。軟件的管理維護(hù)簡單，對于發(fā)生故障時縮短恢復(fù)時長是有重要幫助的。

?

好的軟件設(shè)計開發(fā)完成后，在部署環(huán)節(jié)，一定要實(shí)際測試在設(shè)計時定下來的目標(biāo)，比如說避免單點(diǎn)，就需要部署時，實(shí)際去破壞。對其他各種容錯的處理是否真的到位。我們常見的做法是關(guān)機(jī)測試、重啟檢驗(yàn)服務(wù)自恢復(fù)能力、拔網(wǎng)線等測試，同時觀察軟件系統(tǒng)是否運(yùn)行正常。這主要仍然是圍繞服務(wù)可靠性進(jìn)行測試。

?

一個服務(wù)，除了自身軟件外，還包含了監(jiān)控，監(jiān)控應(yīng)當(dāng)視為服務(wù)的一部分。服務(wù)上線一定是包含了監(jiān)控。監(jiān)控是較好的質(zhì)量保證措施。SAE平臺在Alpha版上線時就有了各種監(jiān)控，監(jiān)控是平臺不可分離的一部分。對于監(jiān)控，我們積累了一些經(jīng)驗(yàn).

?

實(shí)時：要能夠及時發(fā)現(xiàn)問題、搶在用戶的前面發(fā)現(xiàn)問題

?

立體：這要求我們的監(jiān)控是多層次的立體式的，立體監(jiān)控較大的好處是快速定位故障原因，有助于快速解決問題。畢竟同樣的現(xiàn)象，背后可能有很多種可能。我們的監(jiān)控包含：系統(tǒng)監(jiān)控(負(fù)載,磁盤IO等)、網(wǎng)絡(luò)TCP三次握手監(jiān)控(只要節(jié)點(diǎn)之間發(fā)生網(wǎng)絡(luò)關(guān)系的都需要監(jiān)控)、服務(wù)自身可用性監(jiān)控、錯誤日志趨勢監(jiān)控(當(dāng)服務(wù)的錯誤數(shù)量突然增加時可以捕捉到)

?

可視化：這是從監(jiān)控工具的易用性而言?？梢暬佑欣诎l(fā)現(xiàn)和分析問題。

?

自我恢復(fù)：這主要體現(xiàn)在服務(wù)監(jiān)控里。服務(wù)的監(jiān)控包含兩個部分，首先是根據(jù)服務(wù)所承諾的各項(xiàng)功能的黑盒測試，這主要是模擬用戶發(fā)起。其次是服務(wù)所在的節(jié)點(diǎn)上有部署自我檢查自我修復(fù)的程序，當(dāng)自我診斷認(rèn)為有故障時，程序會嘗試多種恢復(fù)方法。這極大降低了故障服務(wù)時長，有效提高了服務(wù)可用的時間。SAE平臺底層有這樣一套系統(tǒng)在不間斷地運(yùn)行。

?

報警：監(jiān)控是為了更快發(fā)現(xiàn)問題，能夠自動處理的讓機(jī)器自動完成，不能自動完成的就需要人工處理，這就需要有報警機(jī)制。SAE內(nèi)部開發(fā)了一個叫“報警網(wǎng)關(guān)”的系統(tǒng)，所有的監(jiān)控都是直接對接該報警網(wǎng)關(guān)。網(wǎng)關(guān)的優(yōu)點(diǎn)是可以做分析、排重，并且是有上下文的報警。我們報警的原則：過猶不及。當(dāng)運(yùn)維人員收到過多報警，并且包含了大量的誤報時，這樣的報警時沒有價值的，要堅決抵制。

?

故障響應(yīng)：相關(guān)人員接到報警后，根據(jù)故障級別進(jìn)行響應(yīng)。

?

嚴(yán)重故障，影響到平臺的穩(wěn)定運(yùn)行，白天要求5分鐘內(nèi)響應(yīng)，夜間15分鐘響應(yīng)。

?

次級故障，不影響應(yīng)用的運(yùn)行，但可能影響到用戶的管理和使用白天要求15分鐘響應(yīng)，夜間要求2小時響應(yīng)

?

警告級別故障，這種報警不影響服務(wù)，不影響使用，但需要提示有隱患。白天要求1小時，夜間不要求響應(yīng)，但要求早晨立刻處理，避免故障升級。

?

快速的故障發(fā)現(xiàn)、自我修復(fù)和故障響應(yīng)，是在故障一旦發(fā)生后，縮短服務(wù)恢復(fù)時長，提高服務(wù)的可維護(hù)性角度而言的，從而間接提高了服務(wù)的可用性。對于互聯(lián)網(wǎng)服務(wù)而言，強(qiáng)大的運(yùn)維團(tuán)隊(duì)是服務(wù)可用性的重要保障之一！

?

下圖是SAE平臺訪問量和訪問用戶的實(shí)時監(jiān)測圖表。

我們知道服務(wù)如果沒有變更，出問題的概率一般就很低。但是互聯(lián)網(wǎng)服務(wù)變更恰恰是很頻繁的，這恰好體現(xiàn)了她的生命力。所以如何在不斷變更升級的條件下保證平臺的穩(wěn)定可用顯得更為迫切。SAE每周的各種變更升級在十次以上。SAE為更好地保證平臺穩(wěn)定性，我們引入了旁路系統(tǒng)和灰度發(fā)布機(jī)制。

?

旁路系統(tǒng)：用戶的請求進(jìn)入負(fù)載均衡后，除了會走正常流程外，同時會引導(dǎo)到另外一個環(huán)境，該環(huán)境和生產(chǎn)環(huán)境非常相近，除了規(guī)模外。我們引入旁路系統(tǒng)的原因在于配置變更、軟件升級等很頻繁，在生產(chǎn)環(huán)節(jié)每一個變更不管多么簡單都是有風(fēng)險的。其次是系統(tǒng)級別的軟件更新升級等，為了盡可能多盡可能早地發(fā)現(xiàn)一些隱藏的很深的bug，旁路系統(tǒng)是一個不錯的方案。因?yàn)榕月废到y(tǒng)足夠真實(shí)。并且還可以在旁路環(huán)境進(jìn)行一些壓力測試，畢竟線上做壓力測試危險太大，線下做測試，測試數(shù)據(jù)不夠真實(shí)。在旁路系統(tǒng)變更完成后，如何判斷變更是安全的，是一件相對比較有挑戰(zhàn)的事情。我們的經(jīng)驗(yàn)往往是觀察變更涉及的服務(wù)，錯誤日志比例是不是有明顯上升。如果變更后服務(wù)無法使用或者掛了，問題就更加明顯。

?

灰度發(fā)布：旁路系統(tǒng)雖然足夠真實(shí)，但畢竟不是完全真實(shí)的生產(chǎn)環(huán)境，變更有沒有對應(yīng)用造成影響，有時需要用戶反饋來配合。盡管旁路系統(tǒng)可以發(fā)現(xiàn)99%的問題，但不可否認(rèn)仍然有可能有隱藏的很深的我們無法發(fā)現(xiàn)。這就需要引入灰度發(fā)布。所謂灰度發(fā)布，就是在升級時，只引導(dǎo)部分應(yīng)用來使用，通過逐步增加使用的應(yīng)用數(shù)量同時觀察用戶的反饋，來驗(yàn)證變更是否存在問題。但是對于有狀態(tài)的服務(wù)，灰度發(fā)布實(shí)施比較困難。

?

旁路系統(tǒng)和灰度發(fā)布都是從提高平臺服務(wù)可靠性角度出發(fā)，對變更做好風(fēng)險控制，盡量降低故障發(fā)生的次數(shù)。

?

數(shù)據(jù)可用性主要體現(xiàn)在數(shù)據(jù)冗余上。SAE平臺數(shù)據(jù)類的服務(wù)包括MySQL、KVDB和Storage，服務(wù)都提供有熱備和冷備，并可以從冷備中恢復(fù)14天內(nèi)的數(shù)據(jù)。數(shù)據(jù)自助恢復(fù)功能目前正在開發(fā)中，目前可以提供收費(fèi)的人工數(shù)據(jù)恢復(fù)服務(wù)。

?

由于南北電信互聯(lián)互通問題，用戶一旦跨網(wǎng)訪問，往往不可到達(dá)或由于電信運(yùn)營商網(wǎng)絡(luò)故障或IDC級別的故障，用戶到IDC之間的網(wǎng)絡(luò)不可到達(dá)，或丟包率很高。

?

網(wǎng)絡(luò)可用性更多的會依賴電信運(yùn)營商的服務(wù)能力。但對于互聯(lián)網(wǎng)服務(wù)而言，必須要解決這樣的困難才可以真正提供好的服務(wù)。

?

目前SAE網(wǎng)絡(luò)接入支持電信、聯(lián)通、教育、移動等，真正實(shí)現(xiàn)了國內(nèi)大的運(yùn)營商網(wǎng)絡(luò)的覆蓋，這在國內(nèi)是很罕見的。用戶不須操心網(wǎng)絡(luò)接入的復(fù)雜問題，并且在某些鏈路訪問質(zhì)量出現(xiàn)問題時，SAE平臺通過云監(jiān)控能夠及時發(fā)現(xiàn)，并會做出調(diào)整。較大限度保證全國范圍內(nèi)的用戶的網(wǎng)絡(luò)可到達(dá)。

?

下圖展示了SAE是如何保證多路訪問質(zhì)量的。

盡管國外云計算的使用已經(jīng)非常普及，但不可否認(rèn)，國內(nèi)的云計算市場尚處于起步階段。這固然和國內(nèi)企業(yè)和開發(fā)者的認(rèn)知和接受度有關(guān)，但也和國內(nèi)云計算發(fā)展不夠務(wù)實(shí)，不貼近用戶需求脫離不了干系。

?

客戶在選擇是否使用云計算時，往往有很多擔(dān)憂，總覺得沒有放在自己的手里放心。但我們從實(shí)踐中也發(fā)現(xiàn)，大部分企業(yè)的網(wǎng)站，其可用性可到達(dá)率都不算高，雖然沒有專業(yè)機(jī)構(gòu)提供的中國網(wǎng)站可用性這樣的報告。如果完全自己去實(shí)現(xiàn)自己的系統(tǒng)，上面遇到的大部分可用性挑戰(zhàn)，相信都會遇到，而且未必能做得更好。所以如果云計算足夠成熟，建議采用云計算，讓您的企業(yè)更“輕”點(diǎn)，服務(wù)更可靠點(diǎn)。

?

SAE平臺目前的可用性已經(jīng)可以達(dá)到99.95%，我們正在朝99.99%的目標(biāo)努力，SAE對于更高可用性的追求是沒有止境的。

?

云計算平臺的可用性，相比傳統(tǒng)互聯(lián)網(wǎng)服務(wù)而言，更加復(fù)雜和困難，也更具有挑戰(zhàn)性。以后有機(jī)會再談?wù)勗朴嬎憧捎眯栽O(shè)計有哪些特別的地方。