[[339950]]

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

我一直對 Web 開發(fā)和軟件體系結(jié)構(gòu)很感興趣，因為我喜歡看到一個工作系統(tǒng)的宏觀視圖。無論是構(gòu)建一個移動應(yīng)用程序還是一個 Web 應(yīng)用程序，都必須連接到互聯(lián)網(wǎng)，在不同的模塊中交換數(shù)據(jù)，這意味著你需要 Web 服務(wù)。

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

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

雖然機器學(xué)習(xí)和智能算法是這些系統(tǒng)的基礎(chǔ)，但它們實現(xiàn)持續(xù)的服務(wù)而不停機一分鐘的事實值得稱贊。它們昂貴的硬件設(shè)備和巨大的數(shù)據(jù)中心當(dāng)然十分重要，但是支持服務(wù)的精密軟件設(shè)計也同樣重要。而且容錯系統(tǒng)是一個構(gòu)建如此精密系統(tǒng)的法則之一。

生產(chǎn)過程中導(dǎo)致錯誤的兩種行為

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

故障停止行為

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

服務(wù) 2 停機導(dǎo)致的故障停止行為

但是，如果服務(wù)之間存在網(wǎng)絡(luò)問題，也會出現(xiàn)此問題，如下圖所示：

網(wǎng)絡(luò)故障導(dǎo)致的故障停止行為

拜占庭行為

拜占庭行為是指系統(tǒng)在持續(xù)運行，但并沒有產(chǎn)生預(yù)期行為（例如：錯誤的數(shù)據(jù)或者無效的數(shù)據(jù)）。

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

因服務(wù)損壞而導(dǎo)致的拜占庭故障

或者，可能存在惡意的中間人在服務(wù)之間進行攔截，并注入了不需要的數(shù)據(jù)：

惡意中間人導(dǎo)致的拜占庭故障

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

構(gòu)建容錯系統(tǒng)的工具

盡管構(gòu)建一個真正實用的容錯系統(tǒng)涉及到深入的“分布式計算理論”和復(fù)雜的計算機科學(xué)原理，但有許多的軟件工具（其中許多是開源軟件）通過構(gòu)建容錯系統(tǒng)來減輕不良后果的影響。

斷路模式：Hystrix 和 Resilience4j

斷路模式是一種技術(shù)，它有助于在服務(wù)失敗時返回準(zhǔn)備好的虛擬回應(yīng)或者簡單回應(yīng)。

斷路模式

奈飛開源的 Hystrix 是斷路模式中最流行的應(yīng)用。

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

負載均衡：Nginx 和 HaProxy

負載均衡是分布式系統(tǒng)中最基本的概念之一，要想擁有一個生產(chǎn)質(zhì)量的環(huán)境，必須有負載均衡的存在。要理解負載均衡器，首先我們需要明白冗余的概念。每個生產(chǎn)級的 Web 服務(wù)都有多個服務(wù)器在某個服務(wù)器宕機時提供冗余來接管和維持服務(wù)。

負載均衡

想想現(xiàn)代飛機：它們的雙引擎提供冗余，使它們即使在一個引擎著火的情況下也能安全的著陸。（這也有助于大多數(shù)商用飛機擁有最先進的自動化系統(tǒng)）。但是，擁有多引擎（或者多服務(wù)器）也意味著必須存在一些調(diào)度機制在故障發(fā)生時有效地對系統(tǒng)進行路由。

負載均衡器是一種通過平衡多個服務(wù)節(jié)點來優(yōu)化大流量事務(wù)的設(shè)備或者軟件。舉個例子，當(dāng)數(shù)以千計的請求涌入時，負載均衡器可以作為中間層在不同的服務(wù)器間進行路由和平均分配流量。如果一臺服務(wù)器宕機，負載均衡器會將請求轉(zhuǎn)發(fā)給其它運行良好的服務(wù)器。

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

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

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

參與者模型：Akka

參與者模型是一種并發(fā)設(shè)計模式，當(dāng)作為基本計算單位的“參與者”接收到消息時，它會分派責(zé)任。一個參與者可以創(chuàng)建更多的參與者，并將消息委派給他們。

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

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

多線程開發(fā)在過去很流行，但是現(xiàn)在已經(jīng)不鼓勵這種做法了，取而代之的是異步的、非阻塞的 I/O 模式。對于 Java，這一點在 EnterpriseJavaBean（EJB）規(guī)范中得到了明確的規(guī)定：

“企業(yè) bean 一定不能使用線程同步原語來同步多個實例的執(zhí)行。”

“企業(yè) bean 不得試圖去管理線程。企業(yè) bean 不得試圖啟動、停止、掛起或恢復(fù)線程，或者去更改線程的優(yōu)先級或者名稱。企業(yè) bean 不得試圖管理線程組。”

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

其他的選擇：Eureka 和 Chaos Monkey

用于容錯系統(tǒng)其它有用的工具包括奈飛的 Eureka 之類的監(jiān)控工具，以及像 Chaos Monkey 這樣的壓力測試工具。它們旨在通過在較低環(huán)境中的測試，如集成（INT）、質(zhì)量保障（QA）和用戶接受測試（UAT）來早早發(fā)現(xiàn)潛在問題以防止在轉(zhuǎn)移到生產(chǎn)環(huán)境之前出現(xiàn)潛在問題。