分布式系統(tǒng)中的工程可靠性和容錯性

作者：鐘濤翻譯 2022-01-12 09:01:24

前端
分布式 在本文中，我們將詳細討論什么是工程可靠性和容錯性，并解釋Ably平臺是如何設計的，已達到工程可靠性和容錯性。

用戶希望可以依賴提供給他們的服務。在實踐中，因為個別不可避免地的因素，可能會導致服務失敗，但即使如此，我們也要盡量避免服務失敗。

在本文中，我們將詳細討論什么是工程可靠性和容錯性，并解釋Ably平臺是如何設計的，已達到工程可靠性和容錯性。

作為討論的前提，首先是一些定義：

可靠性

用戶對產(chǎn)品或服務的可信賴程度。這意味著系統(tǒng)不僅可用，而且還設計了大量冗余措施，以繼續(xù)按照用戶的期望工作。

可用性

產(chǎn)品或服務在需要時的可用程度。這通常歸結為，在系統(tǒng)出現(xiàn)故障時，是否能夠提供足夠的資源冗余。

什么是容錯性?

容錯性是指系統(tǒng)的某些組件或子系統(tǒng)出現(xiàn)故障時，依然具備可用性和可靠性。

具備容錯性的系統(tǒng)可以容忍故障，它們旨在減輕不利因素對系統(tǒng)的影響，并確保系統(tǒng)對用戶保持始終可用。容錯技術可用于提高可用性和可靠性。

可用性可以粗略地認為是保證系統(tǒng)的正常運行;可靠性可以被認為是系統(tǒng)在運行期間提供服務的質量--也就是說，確保在系統(tǒng)故障中盡可能有效地維護功能和用戶體驗。

如果該服務無法提供使用，那就是可用性不足。如果服務可用，但在使用時偏離了用戶預期，那就是可靠性不足。容錯設計方法解決了這些不足，為業(yè)務和用戶體驗提供了連續(xù)性。

可用性、可靠性和狀態(tài)

在大多數(shù)情況下，容錯設計的主要基礎是：冗余。提供超過服務所需的最小組件數(shù)量或容量。關鍵問題是如何管理“冗余”。

在真實世界中，可用性和可靠性存在著區(qū)別：

• 可用性可以接受服務的短暫停止，好比更換汽車輪胎;
• 可靠性需要確保服務的連續(xù)性，那么“冗余”必不可少。比如飛機的發(fā)動機不止一個。
• 連續(xù)性的要求會影響冗余容量的提供方式。
• 在分布式系統(tǒng)中，我們可以將組件分為兩類，分別為"有狀態(tài)"和“無狀態(tài)”。

無狀態(tài)組件在不依賴于任何狀態(tài)的情況下就能實現(xiàn)功能。每次服務調用都可以獨立完成，不依賴于上一次服務調用。這些組件的容錯設計相對簡單：只需提供足夠的資源，即使某些資源出現(xiàn)故障，也可以由其他無狀態(tài)組件負責處理。

有狀態(tài)組件需要依賴于某個狀態(tài)才能提供服務。狀態(tài)隱式地將服務的調用鏈接到過去和將來的調用。這些組件的容錯本質，就像飛機的引擎一樣，是否能夠提供運行的連續(xù)性。具體來說，就是服務所依賴的狀態(tài)的連續(xù)性。

在本文的剩余部分中，我們將給出每種情況的示例，并解釋在實踐中實現(xiàn)容錯時遇到的工程挑戰(zhàn)。

容錯設計將故障視為常規(guī)

在大型系統(tǒng)中，必須假設組件故障遲早會發(fā)生，且有可能即將發(fā)生，并且預計組件故障將持續(xù)發(fā)生。

在大型系統(tǒng)中，故障通常是非二進制的，我們不能依賴于單個組件的可靠性，服務故障具有傳導作用。拜占庭故障就是一個很經(jīng)典的例子。

例如，某個組件間歇性的工作，或某個組件產(chǎn)生誤導性輸出，或者你依賴的外部組件出現(xiàn)故障。這都將影響你整個系統(tǒng)的可靠性，你的系統(tǒng)能否容忍這些錯誤。

容忍非二進制故障需要大量的思考、工程實踐，有時還需要人為干預。必須對每個潛在故障進行識別和分類，然后必須能夠快速補救，或通過廣泛的測試和穩(wěn)健的設計決策來避免。設計容錯系統(tǒng)的核心挑戰(zhàn)是了解故障的本質，以及如何檢測和補救故障，特別是在發(fā)生間歇性故障時，盡可能地持續(xù)為用戶提供服務。

無狀態(tài)服務

無狀態(tài)服務對單個組件的服務連續(xù)性沒有要求。資源的可用性直接轉換為組件的可用性。保證資源的可用性是保證無狀態(tài)服務可用性的關鍵。只要有可能，組件都應該被設計成無狀態(tài)，不僅便于提升可用性，也便于提升可伸縮性。

對于無狀態(tài)服務，有多個獨立可用的組件來持續(xù)提供服務就足夠了。因為沒有狀態(tài)，單個組件的耐久性就不值得關注。

然而，僅擁有足夠的資源是不夠的，你還必須有效地使用它們。你必須要有一種檢測資源可用性的方法，并在冗余資源之間實現(xiàn)負載均衡。

因此，你必須回答以下問題：

• 如何在各種各樣的失敗中生存?
• 什么級別的冗余是可能的?
• 維持這些冗余級別的資源，性能成本是多少?
• 管理這些冗余級別的資源，運營成本是多少?

由此產(chǎn)生的權衡如下：

• 實現(xiàn)用戶對于高可用性的需求
• 經(jīng)營成本
• 現(xiàn)實世界中，使之成為可能的工程可行性

冗余組件以及它們的依賴關系必須以獨立的方式進行設計、配置和操作。簡單的數(shù)學公式是：隨著冗余級別的增加，在統(tǒng)計學上，獨立組件的故障，使整個系統(tǒng)發(fā)生災難性故障的幾率將呈指數(shù)級降低。

在Ably，為了提高系統(tǒng)的可用性，我們將組件分配到多個可用性區(qū)域，以防止單個可用性區(qū)域出現(xiàn)故障。對于AWS服務來說，這很容易實現(xiàn)。有時多個可用性區(qū)域(AZ)也會同時出現(xiàn)故障;有時可能存在本地連接問題，無法訪問該區(qū)域;有時，某個地區(qū)可能存在容量限制，無法支持該地區(qū)的所有服務。因此，我們還通過在多個地區(qū)(region)提供服務來提高服務可用性。

建立跨多個地區(qū)的冗余并不像支持多個區(qū)域那么簡單。例如，簡單地用一個負載均衡器在各地區(qū)之間分配請求是沒有意義的，因為負載均衡器本身可能存在于某個區(qū)域內，它也可能變得不可用。

相反，我們使用一系列措施來確?？蛻舳苏埱笤谌魏螘r候都可以被路由到一個被認為是健康的且具有可用服務的區(qū)域。

有狀態(tài)服務

在Ably，可靠性意味著有狀態(tài)服務的業(yè)務連續(xù)性，這是一個比可用性要復雜得多的問題。

有狀態(tài)服務對狀態(tài)有內在的依賴關系，這種依賴關系在每次單獨的服務調用中都存在。該狀態(tài)的連續(xù)性轉化為服務的正確性。對連續(xù)性的要求意味著服務的容錯性，我們可以通過冗余，以保障在出現(xiàn)故障時狀態(tài)不會丟失。通過共識機制來解決可能的拜占庭故障。

最簡單的類比是飛機安全。一架飛機墜毀是災難性的，飛機必須提供持續(xù)的服務。如果沒有這樣做，狀態(tài)就會丟失，飛機就會墜毀。

對于任何依賴于狀態(tài)的服務，當選擇一個替代服務時，要求能夠在前一個服務中斷的地方繼續(xù)使用新服務。因此，保存狀態(tài)是必須的，在這些情況下，僅可用性是不夠的。

在Ably，我們?yōu)闊o狀態(tài)服務提供足夠的計算能力，以支持我們所有客戶的可用性需求。然而，對于有狀態(tài)服務，我們不僅需要提供冗余服務，還需要有特定的機制來利用冗余，以支持我們的服務保證功能的連續(xù)性。

例如，某個請求在集群中的某個實例上運行，而該實例恰巧遇到故障，迫使該請求轉移，則必須有適當?shù)臋C制來確保請求能夠繼續(xù)執(zhí)行。

為達到繼續(xù)執(zhí)行的目的，這是幾個層面配合作用的效果。在一個層面上，必須存在一種機制，以確保該請求被重新分配給一個健康的服務。在另一個層面上，需要確保重新分配的服務在前一個服務停止的地方繼續(xù)執(zhí)行。此外，每一種服務本身都是通過一定程度的冗余來實現(xiàn)和操作的，以保證服務的總體可靠性。

該機制的有效性直接轉化為服務的有效性。以一個場景為例：對于任何待處理的消息，你需要確切地知道該消息的處理結果，成功或失敗。

當客戶端將消息提交給Ably以進行發(fā)布時，服務接受該消息以進行發(fā)布，客戶端希望獲得消息的結果。此時，主要的可用性問題是：服務接受消息或者拒絕消息的時間分別是多少?

我們最低的可接受時間是4秒。

如果你想要發(fā)布消息，而我們卻告訴你我們做不到，那么這是一個可用性缺陷。這不是很好，但你至少知道當前我們的服務不可用。

然而，如果我們成功地回應，“是的，我們已經(jīng)收到了你的信息”，但我們卻沒有真正的繼續(xù)執(zhí)行下去，那就是另一種失敗。那這就是我們功能性的問題，是可靠性的缺陷。而且在分布式系統(tǒng)中要解決可靠性問題要復雜得多，需要花費大量的工程精力和復雜性來滿足可靠性要求。

實現(xiàn)可靠性的架構方法

下面闡述了我們在Ably采用的架構方法，如何利用冗余來處理消息。

哈希一致性

通常，水平伸縮性是通過分配可伸縮的資源來實現(xiàn)的。就無狀態(tài)服務而言，我們將服務部署在不同的地理位置，當請求來臨時，負載均衡器會根據(jù)地理位置分配鄰近的服務或其他優(yōu)化考慮因素來決定處理請求的服務。

同時，針對有狀態(tài)的服務，服務器的放置特別重要，當某一臺服務器發(fā)生故障時，不能影響其他服務器的正常操作，我們可以通過哈希一致性來達到目的。

一個具體的例子是，我們通過哈希一致性算法來決定消息由哪個服務器來處理，同時盡最大可能，將消息均勻的分配給不同的服務器進行處理。

消息持久化

當消息發(fā)布后，消息被處理，返回響應(成功或失敗)給調用方?？煽啃砸馕吨⒉荒軄G失。反過來意味著，只有將消息持久化下來，當服務器發(fā)生故障時，消息依然可以被找回，進行后續(xù)的處理。

首先，我們在至少兩個不同的可用性區(qū)域(AZs)中記錄消息的接收情況。這是Ably消息持久化的核心：將消息寫入多個位置，并且確保寫入消息的過程是事務性的。你總能知道消息要么成功寫入，要么失敗。有了這一點的保證，就可以保證消息的后續(xù)處理。

確保消息在多個可用性區(qū)域中被持久化，因此單個事件或原因不會導致數(shù)據(jù)丟失。確保多個位置的寫操作是事務性的，則需要消息持久層中的分布式一致性。

以這種方式構建的系統(tǒng)，只有在所有可用性區(qū)域同時發(fā)生故障時才會導致系統(tǒng)不可用，但這種概率是極低的。

在我們的數(shù)學模型中，當一個節(jié)點發(fā)生故障時，且我們已經(jīng)知道了修復故障所需的時間，再加上每個可用性區(qū)域的故障率，以及各個可用性區(qū)域連續(xù)發(fā)生故障的概率進行建模。最后我們得出我們需要8-9個可用性區(qū)域來最大化的保證可靠性。

容錯性的工程考慮

即使你有了實現(xiàn)容錯性的理論方法，仍然有許多實際的和系統(tǒng)工程方面的挑戰(zhàn)需要考慮。

分布式一致性

上述機制，例如哈希一致性，只有在所有服務器正常工作時才有效。

這是一個經(jīng)典的一致性問題，集群中的成員，對自己的身份(主從關系)達成一致性， Raft/Paxos是重要的理論保障，但在實際的網(wǎng)絡環(huán)境中，特別是，在跨多個區(qū)域的網(wǎng)絡中，如果各個服務器之間的網(wǎng)絡延遲過大，這些算法的有效性就會下降。

只有當所有參與實體對集群的拓撲以及每個節(jié)點的狀態(tài)和健康狀況達成一致時，上述機制(如角色放置算法)才能有效。

相反，我們同時使用Gossip協(xié)議，它是最終一致的、容錯的，并且可以跨區(qū)域工作。

結論

容錯性的目的是減輕故障對系統(tǒng)的影響，以便持續(xù)地為客戶提供服務。

在Ably中，我們將服務分為有狀態(tài)和無狀態(tài)兩類。無狀態(tài)服務的容錯性極強，而有狀態(tài)服務我們需要保證狀態(tài)的連續(xù)性，才能保證服務的連續(xù)性。協(xié)調

要實現(xiàn)容錯性系統(tǒng)，必須將故障視為常規(guī)事件，而不是異常事件。除了理論的支撐，設計容錯系統(tǒng)還涉及許多系統(tǒng)工程挑戰(zhàn)。這包括基礎設施可用性和可伸縮性問題，以及分布式一致性問題，如何協(xié)調全球所有節(jié)點的網(wǎng)絡拓撲結構，以及不可預測/難以檢測的節(jié)點健康狀態(tài)。

Ably平臺是根據(jù)這些原則從頭設計的，其目標是提供一流的企業(yè)解決方案。這就是為什么我們可以自信地提供可用性和可靠性服務的保證，同時保證容錯性。

文章名稱：分布式系統(tǒng)中的工程可靠性和容錯性
文章網(wǎng)址：http://uogjgqi.cn/article/dpichos.html