據報道，近日，由于中國聯(lián)通整治違規互聯(lián)網(wǎng)接入及大帶寬業(yè)務(wù)，某CDN/IDC服務(wù)商業(yè)務(wù)中斷，華為云故障一整天，導致生意幫一整天當機，脈脈服務(wù)器掛了，失聯(lián)15個(gè)小時(shí)……
接著(zhù)整個(gè)經(jīng)歷就非常崩潰了：用戶(hù)不間斷的咨詢(xún)投訴，很多用戶(hù)幾百萬(wàn)的生意，重要的戰略合作受影響，重要數據和資料的無(wú)法調用，CDN直播叫停……都因為網(wǎng)絡(luò )故障而停擺，影響甚大。
意外在所難免。用戶(hù)和客戶(hù)是無(wú)辜的。如何保障自己的技術(shù)和服務(wù)的高可用性，做到即使在出現0.0001%的故障發(fā)生率的情況下，仍然可以給用戶(hù)和客戶(hù)提供高可用性，保證災難情況下網(wǎng)絡(luò )服務(wù)的及時(shí)恢復，是云技術(shù)服務(wù)商、提供商必須面對，又亟待解決的重要問(wèn)題。
什么是高可用性？
要了解高可用性對于服務(wù)提供商的必要性和重要性，首先我們要了解什么是高可用性。一般來(lái)講，一個(gè)靠譜的云服務(wù)一定是：
可用性非常高的，24*7隨時(shí)可以用。
可控性一定要好，非云服務(wù)你可以上個(gè)鎖，云服務(wù)沒(méi)法上鎖，如何能做到可控性很好是一個(gè)難點(diǎn)。
災難恢復，是軟件就會(huì )有問(wèn)題。怎么樣積極地面對這個(gè)問(wèn)題，多長(cháng)時(shí)間恢復，如何恢復，是否有成熟的預案這是任何一個(gè)云廠(chǎng)商都要誠實(shí)面對的問(wèn)題。
業(yè)界的高可用性標準
首先，我們來(lái)看一下可用性的評判標準，就是SLA，Service Level Agreement。一個(gè)東西是不是高可用，那么就問(wèn)他幾個(gè)九，敢不敢拿出來(lái)說(shuō)一下。
3個(gè)9基本上是國內云服務(wù)的基礎線(xiàn)。也就是說(shuō)云服務(wù)至少要做到3個(gè)9才稱(chēng)為基本上可用，是合格性產(chǎn)品。如果做不到這個(gè)，你的產(chǎn)品就連忽悠客戶(hù)都做不到了。回去重新開(kāi)發(fā)，重新裝備，刷到至少3個(gè)9再回來(lái)。
從3個(gè)9邁向4個(gè)9，也就是99.99%的可用性，每年只有52.6分鐘的時(shí)間是不可用的。以前谷歌搜索可用度大概是全球5個(gè)9到6個(gè)9之間，每一個(gè)小節點(diǎn)都是5個(gè)9不到6個(gè)9之間。其實(shí)這個(gè)是很可怕的一個(gè)概念，也就意味著(zhù)即使有不可抗力，發(fā)生了臺風(fēng)，洪水，地震等重大災害性事件，也只需要5分鐘內恢復服務(wù)。
相較而言，大部分國內的IDC機房都是按照99%設計的，一年至少3天是不可用的。這一標準，給了廠(chǎng)商一定的機動(dòng)時(shí)間，也提供了一定的靈活性。
所以說(shuō)，從3個(gè)9往上，每一次提升都是一次技術(shù)的挑戰。SLA直接反映一個(gè)云服務(wù)的靠譜程度：
從99%到3個(gè)9，是基本可以靠人力和運氣解決的；
從3個(gè)9到4個(gè)9，考驗的是運維自動(dòng)化的能力，災備的能力；
從4個(gè)9往上基本考驗的是服務(wù)基礎架構、業(yè)務(wù)設計的能力。
聲網(wǎng)Agora.io的高可用性
聲網(wǎng)Agora.io一直在4個(gè)9到5個(gè)9之間努力，這個(gè)目前還是很有難度的。為了保證高可用性，聲網(wǎng)Agora.io特意將核心機房分布在全球各地，以減少地區性的網(wǎng)絡(luò )故障對于通信的影響，同時(shí)，核心機房用了十幾家不同的IDC，即使某家的網(wǎng)絡(luò )故障了，也能最大限度上保障服務(wù)的穩定性。
聲網(wǎng)在全球部署了覆蓋四個(gè)大洲的虛擬實(shí)時(shí)通信網(wǎng)，100多個(gè)數據中心，近千臺服務(wù)器，每年為用戶(hù)提供數千億分鐘的網(wǎng)絡(luò )通話(huà)服務(wù)，這一系列的舉動(dòng)都是為了充分確保接入SDK的客戶(hù)隨時(shí)隨地獲得高質(zhì)量的通話(huà)服務(wù)。
我們認為，要提升高可用性，需要從方方面面整體布局。
從架構上，聲網(wǎng)的所有服務(wù)都有多點(diǎn)備份，并且所有備份節點(diǎn)都能夠獨立服務(wù)，不依賴(lài)其他節點(diǎn)。任何機房故障，甚至幾個(gè)機房同時(shí)故障都不會(huì )影響到整體服務(wù)，除非所有節點(diǎn)同時(shí)發(fā)生故障。
聲網(wǎng)的SDK也能夠快速切換，一旦檢測到某個(gè)服務(wù)節點(diǎn)不可用，可以快速切換到其他備份節點(diǎn)。
當然，武功再高，也怕菜刀。為了防范一些萬(wàn)一的故障導致服務(wù)不可用，聲網(wǎng)還有一系列措施應對故障。
首先聲網(wǎng)部署了實(shí)時(shí)故障檢測系統。在服務(wù)用戶(hù)的同時(shí)，該系統收集整個(gè)系統服務(wù)狀態(tài)，并實(shí)時(shí)分析。如果遇到服務(wù)數據異常立即報警。
接下來(lái)，聲網(wǎng)的數據分析系統可以對服務(wù)數據進(jìn)行多個(gè)維度和層面的分析匯總。在故障發(fā)生時(shí)，可以快速判斷是哪個(gè)模塊或者機房出現問(wèn)題。有了這個(gè)系統，聲網(wǎng)就可以快速定位故障。比如常見(jiàn)的數據庫故障，進(jìn)程崩潰，遇到性能瓶頸，還有此次事件的主角——機房故障。
在定位了問(wèn)題之后，聲網(wǎng)還有一套工具能夠實(shí)時(shí)調整線(xiàn)上系統，進(jìn)行故障隔離。比如遇到某些數據庫瓶頸時(shí)，能夠暫時(shí)關(guān)閉某些數據庫的寫(xiě)服務(wù)，不影響讀數據。能夠暫停某個(gè)機房的服務(wù)，避免用戶(hù)受到影響。或者某些后臺服務(wù)故障，暫時(shí)禁用，不讓用戶(hù)的音視頻通信受到影響。
在進(jìn)行故障隔離后，或者遇到難以隔離的故障，就需要快速恢復了。對于常見(jiàn)的進(jìn)程崩潰，聲網(wǎng)有自動(dòng)化的包管理工具可以一鍵重啟，回滾到前一個(gè)穩定版本。對于數據庫故障，有數據庫工具可以快速重建數據庫，并恢復數據。即使遇到這次事件中的機房故障，除了架構設計能夠保證服務(wù)基本不受影響外，也有機房上架工具能夠快速上架，并使用部署工具重新部署一個(gè)新的機房。一般而言，聲網(wǎng)上架一個(gè)新機房?jì)H需幾十分鐘。
故障隔離處理后，聲網(wǎng)會(huì )盡快對故障的根本原因做一個(gè)徹底的調查。首先從系統中收集各種數據和日志，進(jìn)行分析，并嘗試建立測試環(huán)境以確認故障的根本原因。
最后，需要進(jìn)行服務(wù)改進(jìn)。改進(jìn)主要從幾個(gè)方面著(zhù)手：第一，修復問(wèn)題。直接修復bug，改進(jìn)算法性能等。第二，架構改進(jìn)。下一次這個(gè)模塊再出問(wèn)題，怎么樣設計系統才能夠讓服務(wù)不受影響？如何設計多點(diǎn)備份？第三，工具改進(jìn)。下次再出現這些問(wèn)題，需要哪些工具可以幫助更快速的定位，對故障進(jìn)行隔離，更快速的恢復故障？
開(kāi)發(fā)者該如何甄別高可用性服務(wù)
面對市場(chǎng)上魚(yú)龍混雜的云服務(wù)提供商，開(kāi)發(fā)者應該如何正確地甄別和選擇高可用度的服務(wù)呢？三個(gè)層面：
觀(guān)察該服務(wù)商的架構是否符合高可用度，SLA一定要達到4個(gè)9；
是否具備完整的、實(shí)時(shí)的災難預案。從問(wèn)題發(fā)生的預警，到問(wèn)題定位分析，到問(wèn)題解決和服務(wù)恢復，是否能在最快的時(shí)間內完成，將用戶(hù)的損失降到最低，
是否把服務(wù)可用性當成生命線(xiàn)的信仰。
