[[339950]]

這些開源工具可以最大化延長運行時間并且在最大程度上減少問題。

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

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

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

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

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

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

故障停止行為

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

服務 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）來早早發現潛在問題以防止在轉移到生產環境之前出現潛在問題。