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

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

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

可靠性

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

可用性

產品或服務在需要時的可用程度。這通常歸結為，在系統出現故障時，是否能夠提供足夠的資源冗余。

什么是容錯性?

容錯性是指系統的某些組件或子系統出現故障時，依然具備可用性和可靠性。

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

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

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

可用性、可靠性和狀態

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

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

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

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

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

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

容錯設計將故障視為常規

在大型系統中，必須假設組件故障遲早會發生，且有可能即將發生，并且預計組件故障將持續發生。

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

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

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

無狀態服務

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

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

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

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

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

由此產生的權衡如下：

• 實現用戶對于高可用性的需求
• 經營成本
• 現實世界中，使之成為可能的工程可行性

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

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

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

相反，我們使用一系列措施來確保客戶端請求在任何時候都可以被路由到一個被認為是健康的且具有可用服務的區域。

有狀態服務

在Ably，可靠性意味著有狀態服務的業務連續性，這是一個比可用性要復雜得多的問題。

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

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

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

在Ably，我們為無狀態服務提供足夠的計算能力，以支持我們所有客戶的可用性需求。然而，對于有狀態服務，我們不僅需要提供冗余服務，還需要有特定的機制來利用冗余，以支持我們的服務保證功能的連續性。

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

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

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

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

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

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

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

實現可靠性的架構方法

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

哈希一致性

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

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

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

消息持久化

當消息發布后，消息被處理，返回響應(成功或失敗)給調用方。可靠性意味著消息不能丟失。反過來意味著，只有將消息持久化下來，當服務器發生故障時，消息依然可以被找回，進行后續的處理。

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

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

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

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

容錯性的工程考慮

即使你有了實現容錯性的理論方法，仍然有許多實際的和系統工程方面的挑戰需要考慮。

分布式一致性

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

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

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

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

結論

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

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

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

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