九個用來構(gòu)建容錯系統(tǒng)的開源工具
這些開源工具可以最大化延長運行時間并且在最大程度上減少問題。
我一直對 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)。
雖然機器學習和智能算法是這些系統(tǒng)的基礎(chǔ),但它們實現(xiàn)持續(xù)的服務(wù)而不停機一分鐘的事實值得稱贊。它們昂貴的硬件設(shè)備和巨大的數(shù)據(jù)中心當然十分重要,但是支持服務(wù)的精密軟件設(shè)計也同樣重要。而且容錯系統(tǒng)是一個構(gòu)建如此精密系統(tǒng)的法則之一。
生產(chǎn)過程中導致錯誤的兩種行為
這是考慮容錯系統(tǒng)的另一種方法。當你在本地運行應(yīng)用程序服務(wù)時,每件事似乎都很完美。棒極了!但當你提升服務(wù)到生產(chǎn)環(huán)境時,一切都會變得一團糟。在這種情況下,容錯系統(tǒng)通過解決兩個問題來提供幫助:故障停止行為和拜占庭行為。
故障停止行為
故障停止行為是運行中系統(tǒng)突然停止運行或者系統(tǒng)中的某些部分發(fā)生了故障。服務(wù)器停機時間和數(shù)據(jù)庫不可訪問都屬于此種類型。舉個例子,在下圖中,由于服務(wù) 2 無法訪問,因此服務(wù) 1 無法與服務(wù) 2 進行通信。
服務(wù) 2 停機導致的故障停止行為
但是,如果服務(wù)之間存在網(wǎng)絡(luò)問題,也會出現(xiàn)此問題,如下圖所示:
網(wǎng)絡(luò)故障導致的故障停止行為
拜占庭行為
拜占庭行為是指系統(tǒng)在持續(xù)運行,但并沒有產(chǎn)生預(yù)期行為(例如:錯誤的數(shù)據(jù)或者無效的數(shù)據(jù))。
如果服務(wù) 2 的數(shù)據(jù)(值)已損壞則可能會發(fā)生拜占庭故障,即使服務(wù)看起來運行得很好,比如下面的例子:
因服務(wù)損壞而導致的拜占庭故障
或者,可能存在惡意的中間人在服務(wù)之間進行攔截,并注入了不需要的數(shù)據(jù):
惡意中間人導致的拜占庭故障
無論是故障停止和拜占庭行為,都不是理想的情況,因此我們需要一些預(yù)防或修復它們的手段。這里容錯系統(tǒng)就起作用了。以下是可以幫助你解決這些問題的 8 個開源工具。
構(gòu)建容錯系統(tǒng)的工具
盡管構(gòu)建一個真正實用的容錯系統(tǒng)涉及到深入的“分布式計算理論”和復雜的計算機科學原理,但有許多的軟件工具(其中許多是開源軟件)通過構(gòu)建容錯系統(tǒng)來減輕不良后果的影響。
斷路模式:Hystrix 和 Resilience4j
斷路模式是一種技術(shù),它有助于在服務(wù)失敗時返回準備好的虛擬回應(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è)備或者軟件。舉個例子,當數(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è)計模式,當作為基本計算單位的“參與者”接收到消息時,它會分派責任。一個參與者可以創(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 不得試圖啟動、停止、掛起或恢復線程,或者去更改線程的優(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)潛在問題。