可用性質量屬性設計之系統設計

您可參考右側導航欄瞭解博文涉及內容。

1、故障，錯誤，BUG的區別

在瞭解一個系統的可用性能夠從瞭解系統故障開始。可是什麼是故障，錯誤，bug？

故障與錯誤是常常容易被混淆的兩個概念,故障、錯誤、BUG之間是有區別的。

• 軟件代碼因爲人爲因素寫錯了或者考慮不周全,成爲了錯誤。
• 有錯誤的軟件存在必定缺陷,該缺陷在某種狀況下能夠轉化爲故障。
• 產生了故障,人們就認爲系統出 BUG了。

錯誤是最原始的驅動力,一個錯誤不必定致使故障,所以錯誤不見得被人們察覺。可是,一旦錯誤變爲故障,人們是能夠經過軟件的外在表現而察覺。故障是系統出錯後致使系統不正常工做的結果,故障從某種意義上來講屬於現象。即經過故障這種現象,人們能夠知道軟件存在BUG,最終找到相關錯誤點,並對錯誤代碼進行修復。BUG 是被激發出來的錯誤,是故障的總稱，所以一個系統實際存在的錯誤數比BUG 數要多,由於只有被激發出來的錯誤才能成爲BUG。

那麼若是要設計一個可靠性很是高的系統，或者系統中的一個可用性很是高的模塊或者子系統該怎麼設計呢？圍繞如下如下幾個問題

• 如何檢測故障：系統出現故障時，能夠經過系統故障的外在可見性瞭解到系統出現BUG，也就是檢測系統的是否處於故障狀態；
• 故障發生會有什麼狀況：系統故障發生後，會對系統產生什麼樣的影響。怎麼讓故障被系統管理員所知道；
• 如何應對故障：系統故障後，可以自動化地改變策略，故障處理，維持系統的可用性。

2、故障檢測

要提高系統的可用性，就要先檢驗系統是否處於故障狀態。

一、ping與echo戰術

ping與echo戰術是錯誤檢測的經常使用方法。這裏的ping能夠對應着window或者linux的ping命令理解，檢查網絡是否連通，能夠很好地幫助咱們分析和斷定網絡故障。在錯誤檢測中，使用ping和echo就是外部模塊，向須要的模塊發送請求即ping消息，而後被檢測的模塊返回相應的狀態信息echo信息。經過信息瞭解到被檢測的模塊狀態。若是被監測方在預期的時間內沒法返回相應的消息，則在進行幾回ping消息發送（能儘可能避免因網絡問題誤判的狀況），若是仍沒法返回信息，便可確認爲出錯。

ping和echo示意圖

monitor向monitored組件發送ping命令，而後monitored返回echo信息（或沒法返回，直接認定monitored端所在的系統錯誤），monitor根據echo信息判斷monitored的系統是否正常運行。monitor與monitored不只能夠在不一樣系統，也能夠屬於同一系統的不一樣模塊。

二、Heartbeat戰術

在使用ping和echo做爲錯誤檢測戰術的系統中，老是由須要兩端即客戶端發送ping，服務端發送echo發送消息保障系統錯誤檢測的正常執行，那麼可否一端發送信息呢？那就是心跳戰術Heartbeats。
Heartbeat的發起者是被檢測者自身，按期發送Heartbeat消息向外界表示其自己正在處於正常運行的狀態。因爲信息的發送是每隔一段時間發送一次，相似人的心跳，因此被稱爲心跳戰術。

Heartbeat示意圖

須要注意的是：Timer的做用是記錄消息是否超時，因此在每一次接受Heartbeat消息以後，都須要當即中止一個定時器的工做，同時開啓新的計時器。若是Timer超過規定時間，則進行診斷。

右側Monitored向左側Monitor發送心跳信息，若是左端Timer即便測發現消息超時，甚至沒法收到消息則斷定Monitored端故障。僅僅使用Heartbeat極可能會形成誤判，也就是heartbeat由於某種傳輸緣由，沒能到達Monitor端，那麼Monitor就直接認定被檢測的系統是故障的嗎？顯然不合適，因此使用ping和heartbeat組合。

補充：除了ping和heartbeat經常使用的故障檢測還有在多數語言中都存在的異常捕獲——異常處理機制，異常出錯後，會上報信息，那麼異常處理程序會根據具體的出錯信息對其進行相應的處理，通常同屬於一個進程或一個線程。
常見如Python：

try:
    語句
except：
    出錯處理

三、ping與heartbeat組合使用

Heartbeat與Ping常常配合使用能提高錯誤檢測的效果。 在正常狀況下,經過Heartbeat 消息監測系統的狀態,當 Heartbeat 消息消失後,可利用 Ping消息作二次確認,若Ping消息也沒有獲得反饋,此時可斷定相關模塊出現故障。

HeartBeat與ping的混合使用示意圖

圖中增長了相應的 Ping和Echo 的支持模塊,這此模Heartbeat 消息超時時被調用,即當計時器超時,左側模塊將發送 Ping 消息,同時啓動新的計時器等待 Echo 的到來。若在超時前接收到了 Echo消息,則說明右側模塊並無失效,反之則判斷右側模塊失效。

流程圖：
Heartbeat發送端流程圖

Heartbeat接收端流程圖（監控端）

因爲系統多是分佈式的，或者監控和被監控的系統分屬於不一樣的系統，因此在流程圖中，能夠看到在消息的發送端，還須要獲取相應的IP地址和端口號。

3、如何處理網絡對消息的影響

不管是ping仍是heartbeat戰術都沒法避免一個問題：如何確認echo或者heartbeat消息是由於真正的系統故障仍是由於網絡傳輸過程當中失效。即如何避免誤判系統故障或者下降誤判的概率。
若是被檢測的系統沒有故障，而在向監測端發送消息的時候，因爲網絡故障問題，監測端沒有接受到信息，那麼監測端誤認爲系統故障，就會採起相應的故障處理策略，這種處理原本是沒有必要的，是消耗資源的。
網絡存在着必定的延時或其餘問題,並非全部的 Heartbeat消息都能準時、週期性的到達,實際系統不能簡單地以一個Heartbeat 消息超時或未到達爲依據作出系統失效的判斷。所以能夠採起兩種 Heartbeat 消息的斷定方法。

一、設置超時時間和最大超時次數

第一種斷定方法。設定一個超時時間 TIME OUT 與最大超時次數 MAX TIME OUT,建議MAX_TIME OUT=3.
斷定系失效方法:

• 在發送消息以後的3次超時計數過程當中,只要接收到迴應,就斷定系統未失效。
• 若是在發送消息以後的3次超時計數過程當中監聽組件都沒有收到迴應,斷定系統失效。

二、超時消息重傳

第二種斷定方法參考TCP 的超時重傳機制,讓監聽組件具備發送ACK消息的功能,ACK 消息帶有序號,監聽組件發送ACK消息以後,響應組件接收到 ACK 消息後才發回 Heartbeat消 息,Heartbeat 消息也帶有序號,且應與對應的 ACK 消息的序號相同。另外設定一個超時時間TIME OUT和一個最大無響應次數 MAX NO RESPONSE,建議 MAX NO RESPONSE=3.

斷定系統未失效方法:

• 連續3次發送ACK消息以後至少有1次獲得相同序號的 Heartbeat消息響應,斷定系統未失效。

斷定系統失效方法:

• 連續3 次發送 ACK 消息以後在 TIME OUT 時間內無相同序號的 Heartbeat消息響應,斷定系統失效。

** 注**：這裏並不能徹底解決系統故障誤判的問題，只是利用現有手段最大程度解決這一問題。

4、系統設計

解決了網絡對消息傳輸的做用對系統故障的影響，那麼如何使用Heartbeat與ping結合設計一個主備份的系統呢?更進一步即確認故障以後如何處理呢？

下面給出主從備份系統的示意圖

備份復件須要檢測主復件的狀態信息,因此主復件問備份復件定時發送 Heartbeat 消息用於告知備份復件相關狀態信息。備份復件在收到每一個Heartbeat 消息以後,啓動新的計時器,若計時器超時仍未收到下一個 Heartbeat 消息,則備份附件進人確認階段。備份復件發送 Ping 消息,而且啓動新的計時器,若在新的計時器超時仍未收到明主復件故障,而後備份復件代替主復件接管全部工做,全部的客戶主復件的 Echo 信息,則付與原來的備件復件進行通訊,此時 須要通知管理人員主備切換的消息,便於管理人員設置新的備件,以保障將來的正常切換。

所以以上分析知道，在確認被檢測系統出錯以後，爲保證系統的持續可用性（這也是本博重點討論的問題），接下來的處理是找到備份系統接管當前系統或模塊的全部工做，並自動化通知相關管理人員作進一步操做。
具體實現可使用主動冗餘這一錯誤恢復戰術。

5、主動冗餘

一、原理

主動冗餘中全部冗餘組件在啓動的時候同步,以並行的方式對時間做出響應,於是它們都處 在相同的狀態。一般,做出響應的第一個組件的結果被採用,其餘響應被丟棄。 組件間的同步是經過將傳遞給被冗餘組件的所有消息發送給全部冗餘組件。發生錯誤時,使用該戰術的系統停機時間一般是幾毫秒。恢復時間就是組件間的切換時間,由於冗餘組件間狀態一致,各組件接收到的都是最新的消息,而且擁有以前的全部狀態。此處的冗餘組件通常是指模塊,但實際還可能包括通訊鏈路。 在可用性要求很是高的分佈式系統中,如通訊核心網,冗餘組 件包括通訊路徑。這一極度契合了爲高可用系統設計的要求。

二、代價

主動冗餘是一種高可靠性的設計，由原理可知，冗餘中全部組件都處於並行運行狀態下，因此通常應用對系統可靠性要求很是高的狀況,且其工做代價也比較高。
從硬件成本上來看,須要雙份系統的硬件要求,從軟件上看,須要一套高效的心跳監測和倒換機制,以及狀態同步的機制。

三、示意圖

B與B'同時接收C的請求而且進行一樣的操做， 可是,只有B向A發送處理完的結果。至關於B'的處理結果在日常狀態下將被丟棄。此時， 若B出現故障,則B'將直接接替B的工做。因爲B'的運行情況與B幾乎一致,B'可快速接替B的工做。B和B'的這種工做模式就是一種主動冗餘的方式。

所以能夠看出：主動冗餘的優勢是切換時間很是短，數據和計算都是熱備份的。因此一旦系統出現錯誤，就能夠馬上切換，基本不會影響系統的正常運行。但缺點也十分明顯，全部的冗餘模塊都處於激活狀態，並指向相同的任務，即便在主系統沒有故障的狀況下仍須要對請求作一樣的處理，從而保障全部模塊的運行結果一致性。就形成了資源的成倍增長。

四、比較

主動冗餘，和被動冗餘和備份是不一樣的存在，被動冗餘不像主動冗餘同樣一直進行計算，實現也更簡單，於是也對系統的可用性保證更低。而備份則是更爲低級別的錯誤恢復方式。

• 實現容易程度：備份>被動冗餘>主動冗餘
• 資源消耗程度：主動冗餘>被動冗餘>備份
• 可用性保證程度：主動冗餘>被動冗餘>備份

具體怎麼選擇策略還須要具體狀況具體分析。