數據中心的可用性指標、數據中心的可用性指標有哪些

服務的質量最簡單的度量指標就是可用性，所謂的可用性有很多定義，例如來自百度、維基等的定義等，也有同學將這個定義為可靠性，相關定義如下：

https://baike.baidu.com/item/%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7/909038?fr=aladdin

https://en.jinzhao.wiki/wiki/Availability

https://wiki.mbalib.com/wiki/%E5%8F%AF%E9%9D%A0%E6%80%A7

這里使用這個公式來定義服務的可用性度量指標：

參考值表格

如何準確客觀的定義這兩個時間，并讓服務與使用者都接受，時常會有一些爭議，因為應該服務時間要不要直接按自然時間如年、季度、月，要不要排出一些非工作時間，法定可不服務時間，以及掛免戰牌的時間；實際可服務時間，要不要就按有無客戶反饋而來，還是應該有不間斷的巡查來保障，或者要不要增加一些權重，畢竟忙閑不一樣。

也正基于此，我們定義了一個簡單的模式，避免發散，其余結合業務再去組合。

觀察者模式用來評價服務可用性是成立的，所謂我見故我在，我之所見故而其在！當一物不為所有存在所感受到時，此物就不存在！有點啰嗦了，其實就是下圖標注【不對外服務的服務，不應該存在】

服務猶若星辰，不對外服務的就不應該存在

另外我們簡單抽象下模型，如下圖，調用者到服務者都可以簡單看作客戶與服務兩個角色，中間有連接通道。

基本調用關系模型

不管多么復雜的系統，最基本的組合單元就是Client-Cloud-Server。從Client調用Server，什么時間，調用耗時多少，成功與否......

基本的要素就是此五項，每一次調用都會生成此明細數據，然后基于此數據進行組合匯總，形成需要的報表。例如某服務的可用性，某調用關系的可用性，流量波動，調用鏈路錯誤原因匯總，故障服務錯誤原因匯總，耗時超過閥值的調用鏈路列表等。全景圖如下，結合閥值對鏈路標記出狀態，并結合鏈路對服務進行狀態標記。

基本模型調用組合集群

考慮到數據分析對業務的影響要小，并確保一定的準實時性（分鐘級別），所以每個節點會進行分鐘級別的統計，然后結合節點的多寡進行分級逐層統計。

Agent按照機器節點分層部署，對每分鐘產生的明細數據，做簡單的匯總，形成如下記錄：

黑體部分為索引，計算步驟如下：

GridV分為統計節點與中心，統計節點為分層計算提供分布式能力支持，中心進行數據的最后存儲。中心還會基于服務的屬性，進一步分發計算。隨著對服務單元本身的定義逐漸清晰（服務歸屬關系，服務所在機器等），關于服務的定義屬性會更多，更具體。數據也會按此進一步梳理匯總。

關于服務的定義如下：

動態的數據，動態的呈現，動態的策略，無為而為不為，迅乎其所不滯，天網恢恢！

方案的設計需要每個節點支持每秒幾十萬次的上報，并對這些上報數據按照時間維度進行統計，一種開源的解決方案如下，可以相對比較廣泛的支持各類終端的可用性上報，服務側的上報。內部系統使用日志記錄在本地，然后通過filebeat上報到kafka；遠程系統則使用http協議上報給nginx，nginx記錄日志，filebeat上報到kafka；然后kylin分析流式數據，按照設定的cube統計，最后通過superset呈現出報表。

一種開源實現