九個用來構建容錯系統的開源工具

我一直對 Web 開發和軟體體系結構很感興趣，因為我喜歡看到一個工作系統的宏觀視圖。無論是構建一個移動應用程序還是一個 Web 應用程序，都必須連接到互聯網，在不同的模塊中交換數據，這意味著你需要 Web 服務。

如果選擇雲系統作為應用程序的後端，則可以利用更強大的計算能力，因為後端服務將會在水平和垂直方向上進行擴展並編排不同的服務。但無論你是否使用雲後端，建造一個靈活、穩定、快速又安全的容錯系統是必不可少的。

要了解容錯系統，讓我們以臉書、亞馬遜、谷歌和奈飛為例。數以億計的用戶會同時接入這些平台並通過對等網路和用戶-伺服器網路傳輸大量數據，你可以肯定這其中還存在許多的帶有不法目的的惡意用戶，例如黑客攻擊和拒絕服務（DoS）攻擊。即使如此，這些平台無需停機也可以全年無休地運轉。

雖然機器學習和智能演算法是這些系統的基礎，但它們實現持續的服務而不停機一分鐘的事實值得稱讚。它們昂貴的硬體設備和巨大的數據中心當然十分重要，但是支持服務的精密軟體設計也同樣重要。而且容錯系統是一個構建如此精密系統的法則之一。

生產過程中導致錯誤的兩種行為

這是考慮容錯系統的另一種方法。當你在本地運行應用程序服務時，每件事似乎都很完美。棒極了！但當你提升服務到生產環境時，一切都會變得一團糟。在這種情況下，容錯系統通過解決兩個問題來提供幫助：故障停止行為和拜占庭行為。

故障停止行為

故障停止行為是運行中系統突然停止運行或者系統中的某些部分發生了故障。伺服器停機時間和資料庫不可訪問都屬於此種類型。舉個例子，在下圖中，由於服務 2 無法訪問，因此服務 1 無法與服務 2 進行通信。


但是，如果服務之間存在網路問題，也會出現此問題，如下圖所示：


拜占庭行為

拜占庭行為是指系統在持續運行，但並沒有產生預期行為（例如：錯誤的數據或者無效的數據）。

如果服務 2 的數據（值）已損壞則可能會發生拜占庭故障，即使服務看起來運行得很好，比如下面的例子:


或者，可能存在惡意的中間人在服務之間進行攔截，並注入了不需要的數據：


無論是故障停止和拜占庭行為，都不是理想的情況，因此我們需要一些預防或修復它們的手段。這裡容錯系統就起作用了。以下是可以幫助你解決這些問題的 8 個開源工具。

構建容錯系統的工具

儘管構建一個真正實用的容錯系統涉及到深入的「分散式計算理論」和複雜的計算機科學原理，但有許多的軟體工具（其中許多是開源軟體）通過構建容錯系統來減輕不良後果的影響。

斷路模式：Hystrix 和 Resilience4j

斷路模式是一種技術，它有助於在服務失敗時返回準備好的虛擬回應或者簡單回應。


奈飛開源的 Hystrix 是斷路模式中最流行的應用。

我之前工作過的很多家公司都在用這款出色的工具。令人意外的是，奈飛宣布將不再更新 Hystrix（是的，我知道了）。相反，奈飛建議使用另一種支持 Java 8 和函數式編程的 Resilence4j 之類的替代解決方案，或者類似於 Adaptive Concurrency Limit 的替代解決方案。

負載均衡：Nginx 和 HaProxy

負載均衡是分散式系統中最基本的概念之一，要想擁有一個生產質量的環境，必須有負載均衡的存在。要理解負載均衡器，首先我們需要明白冗餘的概念。每個生產級的 Web 服務都有多個伺服器在某個伺服器宕機時提供冗餘來接管和維持服務。


想想現代飛機：它們的雙引擎提供冗餘，使它們即使在一個引擎著火的情況下也能安全的著陸。（這也有助於大多數商用飛機擁有最先進的自動化系統）。但是，擁有多引擎（或者多伺服器）也意味著必須存在一些調度機制在故障發生時有效地對系統進行路由。

負載均衡器是一種通過平衡多個服務節點來優化大流量事務的設備或者軟體。舉個例子，當數以千計的請求湧入時，負載均衡器可以作為中間層在不同的伺服器間進行路由和平均分配流量。如果一台伺服器宕機，負載均衡器會將請求轉發給其它運行良好的伺服器。

有許多可用的負載均衡器，但其中最出名的兩個就是 Nginx 和 HaProxy。

Nginx 不僅僅是一個負載均衡器，它還是 HTTP 和反向代理伺服器、郵件代理伺服器和通用 TCP/UDP 代理伺服器。Groupon、Capital One、Adobe 和 NASA 等公司都在使用它。

HaProxy 也很受歡迎，因為它是一個免費的、非常快且可靠的解決方案，它為基於 TCP 和 HTTP 的應用程序提供高可用性、負載平衡和代理。許多大型網路公司，包括 Github、Reddit、Twitter 和 Stack Overflow 都使用 HaProxy。是的，Red Hat Enterprise Linux 同樣支持 HaProxy 設置。

參與者模型：Akka

參與者模型是一種並發設計模式，當作為基本計算單位的「參與者」接收到消息時，它會分派責任。一個參與者可以創建更多的參與者，並將消息委派給他們。

Akka 是最著名的參與者模型實現之一。該框架同時支持基於 JVM 的 Java 和 Scala。

使用消息隊列的非同步、非阻塞 I/O：Kafka 和 RabbitMQ

多線程開發在過去很流行，但是現在已經不鼓勵這種做法了，取而代之的是非同步的、非阻塞的 I/O 模式。對於 Java，這一點在 EnterpriseJavaBean（EJB）規範中得到了明確的規定：

「企業 bean 一定不能使用線程同步原語來同步多個實例的執行。」

「企業 bean 不得試圖去管理線程。企業 bean 不得試圖啟動、停止、掛起或恢複線程，或者去更改線程的優先順序或者名稱。企業 bean 不得試圖管理線程組。」

如今，雖然還有其他做法，如流 API 和參與者模型，但像 Kafka 和RabbitMQ 之類的消息隊列為非同步和非阻塞 I/O 功能提供了開箱即用的支持，同時它們也是功能強大的開源工具，通過處理並發進程可以替代線程。

其他的選擇：Eureka 和 Chaos Monkey

用於容錯系統其它有用的工具包括奈飛的 Eureka 之類的監控工具，以及像 Chaos Monkey 這樣的壓力測試工具。它們旨在通過在較低環境中的測試，如集成（INT）、質量保障（QA）和用戶接受測試（UAT）來早早發現潛在問題以防止在轉移到生產環境之前出現潛在問題。

你在使用什麼開源工具來構建一個容錯系統呢？請在評論中分享你的最愛。

via: https://opensource.com/article/19/3/tools-fault-tolerant-system

作者：Bryant Son 選題：lujun9972 譯者：chenmu-kk 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive