六大權(quán)益！華為8月服務(wù)日開啟：手機(jī)免費(fèi)貼膜、維修免人工費(fèi)
8月5日消息，一年一度的華為開發(fā)者大會2023（Together）日前在松山湖拉開帷幕，與此同時，華為8月服務(wù)日也式開啟，到店可享六大專屬權(quán)益。華為用戶可在華為商城Ap
我們所謂系統(tǒng)發(fā)生故障是指當(dāng)它無法再按照規(guī)格要求向用戶提供服務(wù)時。這種故障是由故障所引發(fā)的，即內(nèi)部組件或系統(tǒng)所依賴的外部組件發(fā)生故障。有一些故障是可以被容忍的，對用戶沒有明顯的影響，而另一些則會導(dǎo)致系統(tǒng)故障。
為了構(gòu)建具備容錯能力的應(yīng)用程序，首先需要了解可能出現(xiàn)哪些問題。在接下來的內(nèi)容中，我們將探討一些最常見的故障根本原因。到最后，您可能會思考如何應(yīng)對各種不同類型的故障。
在計算機(jī)系統(tǒng)中，任何物理組件都可能發(fā)生故障。硬盤驅(qū)動器、內(nèi)存模塊、電源供應(yīng)器、主板、固態(tài)硬盤、網(wǎng)絡(luò)接口卡以及中央處理器等，均可能因各種原因停止正常運(yùn)作。有時，硬件故障甚至可能導(dǎo)致數(shù)據(jù)損壞。更甚者，整個數(shù)據(jù)中心可能會因電力中斷或自然災(zāi)害而發(fā)生故障。不過，正如我們將在后文討論的那樣，通過引入冗余措施，許多這些基礎(chǔ)設(shè)施故障是可以應(yīng)對的。雖然你可能認(rèn)為這些硬件故障是導(dǎo)致分布式應(yīng)用程序失敗的主要原因，但實際上，它們往往因為一些非常普通的原因而出現(xiàn)問題。
在最近對五個流行的分布式數(shù)據(jù)存儲系統(tǒng)進(jìn)行的用戶報告研究中，發(fā)現(xiàn)了多數(shù)災(zāi)難性故障的根本原因是對非致命錯誤處理的不當(dāng)。在大多數(shù)情況下，這些錯誤處理中的問題本可以通過簡單的測試來檢測出來。例如，有些錯誤處理程序完全忽略了錯誤。其他則捕捉了過于通用的異常，比如Java中的Exception，然后出于毫無充分理由的原因終止整個進(jìn)程。還有一些錯誤處理程序只實施了部分功能，甚至包含了"FIXME"和"TODO"這樣的注釋。回過頭來看，這或許并不太令人意外，因為錯誤處理往往被視為次要問題。這也是Go語言如此重視錯誤處理的原因。在后續(xù)，我們將更加深入地探討測試大型分布式應(yīng)用程序的最佳實踐。
配置更改是導(dǎo)致災(zāi)難性故障的主要根本原因之一。問題不僅僅在于錯誤的配置可能會引發(fā)問題，還有一種情況是對于啟用了很少被使用的功能的有效配置更改不再按預(yù)期工作，或者從來沒有按預(yù)期工作。配置更改之所以特別危險，是因為它們的影響可能會拖延。如果一個應(yīng)用程序僅在真正需要配置值的時候才讀取它們，那么無效的配置更改可能會在幾小時甚至幾天后才顯現(xiàn)出問題，從而無法及早被發(fā)現(xiàn)。因此，配置更改應(yīng)該像代碼更改一樣受到版本控制，經(jīng)過測試，并在變更時采取預(yù)防性驗證措施。在持續(xù)部署的背景下，我們將探討代碼和配置更改的安全發(fā)布實踐。
單點(diǎn)故障（SPOF）是指當(dāng)某個組件故障時，整個系統(tǒng)都會崩潰的情況。實際上，系統(tǒng)可能存在多個單點(diǎn)故障。
通常情況下，人員往往成為關(guān)鍵的單點(diǎn)故障（SPOF），如果將他們置于可能獨(dú)立引發(fā)災(zāi)難性故障的位置，幾乎可以確定他們最終會引發(fā)這種故障。例如，人類故障經(jīng)常發(fā)生在某人需要按照特定順序手動執(zhí)行一系列操作步驟而不能犯任何錯誤的情況下。相比之下，計算機(jī)在執(zhí)行指令方面表現(xiàn)出色，因此自動化應(yīng)盡可能得到充分利用。
另一個常見的SPOF是DNS。如果客戶端無法解析應(yīng)用程序的域名，它們將無法連接到該應(yīng)用程序。造成這種情況的原因多種多樣，從域名到期到整個根級域名崩潰都有可能。
類似地，應(yīng)用程序用于其HTTP端點(diǎn)的TLS證書也是一個SPOF。如果證書過期，客戶端將無法與應(yīng)用程序建立安全連接。
理想情況下，在系統(tǒng)設(shè)計階段就應(yīng)該識別這些SPOF。檢測它們的最佳方法是審查每個系統(tǒng)組件，然后詢問如果其中任何一個出現(xiàn)故障會發(fā)生什么。有些SPOF可以通過引入冗余來解決，而其他一些則無法。在這種情況下，唯一的選擇就是減小SPOF的影響范圍，也就是在它們發(fā)生故障時對系統(tǒng)造成的損害。我們將在后續(xù)討論的許多彈性模式都旨在減小故障的影響范圍。
當(dāng)客戶端向服務(wù)器發(fā)送請求時，期望在不久后收到響應(yīng)。在最佳情況下，請求后很快就會收到響應(yīng)。如果出現(xiàn)了不同尋常的情況，客戶端有兩種選擇：要么繼續(xù)等待，要么因為超時異常或錯誤而取消請求。慢速的網(wǎng)絡(luò)調(diào)用是分布式系統(tǒng)的潛在隱患，因為客戶端無法確定響應(yīng)是否最終會到達(dá)，因此它可能會長時間等待，或者干脆不取消請求，從而導(dǎo)致性能下降，而這種問題很難調(diào)試。這種故障也被稱為"灰色故障"，它非常微妙，很難迅速或準(zhǔn)確地檢測到。由于其特性，灰色故障可能會輕松使整個系統(tǒng)崩潰。
當(dāng)引入故障檢測和超時的概念時，會有很多原因?qū)е挛茨塬@得及時響應(yīng)。舉例而言，服務(wù)器可能因在處理請求時速度極慢或崩潰而未能及時響應(yīng)；或者可能是網(wǎng)絡(luò)丟失了少量數(shù)據(jù)包，從而引發(fā)大量的重傳和延遲。
慢速網(wǎng)絡(luò)調(diào)用 是分布式系統(tǒng)的潛在殺手。由于客戶端不清楚響應(yīng)是否最終會抵達(dá)，因此它可能花費(fèi)大量時間等待，甚至可能不會放棄，這將導(dǎo)致性能下降，而問題難以調(diào)試。這種故障也被稱為 灰色故障，這是一種如此微妙以至于不能迅速或準(zhǔn)確檢測到的故障。由于其特性，灰色故障很容易將整個系統(tǒng)帶入崩潰的邊緣。
從觀察者的角度來看，一個非常慢的進(jìn)程與根本不運(yùn)行的進(jìn)程幾乎沒有什么不同，兩者都無法執(zhí)行有用的工作。資源泄漏是導(dǎo)致進(jìn)程變慢的最常見原因之一。
內(nèi)存可能是受泄漏影響最廣泛的資源之一。內(nèi)存泄漏會導(dǎo)致內(nèi)存消耗逐漸增加。即使是帶有垃圾回收功能的編程語言也容易受到泄漏的影響：如果對不再需要的對象保留了引用，垃圾回收器將無法刪除它。當(dāng)泄漏消耗了大量內(nèi)存以至于剩下很少時，操作系統(tǒng)將開始積極將內(nèi)存頁面交換到磁盤。此外，垃圾回收器將更頻繁地啟動，試圖釋放內(nèi)存。所有這些都會消耗CPU周期并使進(jìn)程變得更慢。最終，當(dāng)物理內(nèi)存不再可用，且交換文件空間耗盡時，進(jìn)程將無法分配內(nèi)存，導(dǎo)致大多數(shù)操作失敗。
內(nèi)存只是眾多可能泄漏的資源之一。以線程池為例：如果從線程池獲取的線程進(jìn)行同步阻塞的HTTP調(diào)用而沒有設(shè)置超時，并且該調(diào)用從未返回，線程將不會返回到線程池。由于線程池具有有限的最大大小，如果持續(xù)喪失線程，最終線程將耗盡。
或許你認(rèn)為在前述情況下，采用異步調(diào)用而不是同步調(diào)用會有所幫助。然而，現(xiàn)代HTTP客戶端使用套接字池以避免重復(fù)創(chuàng)建TCP連接并支付性能代價。如果請求未設(shè)置超時，連接將永遠(yuǎn)不會返回到池中。由于池的最大大小是有限的，最終將不再有可用的連接。
此外，你的代碼并不是唯一訪問內(nèi)存、線程和套接字的代碼。你的應(yīng)用程序所依賴的庫也會使用相同的資源，它們可能會遇到我們剛剛討論的相同問題。
每個系統(tǒng)都有其負(fù)載容量，也就是它可以承受的負(fù)載極限。因此，當(dāng)導(dǎo)向系統(tǒng)的負(fù)載持續(xù)增加時，它遲早會觸及到這個極限。
然而，有機(jī)會的負(fù)載增長為系統(tǒng)提供了逐漸擴(kuò)展和增加容量的時間，這是一種情況；而突然和意外的洪水是另一種情況。
例如，考慮應(yīng)用程序在一段時間內(nèi)收到的請求數(shù)量。傳入請求的速率和類型可能會隨時間變化，有時甚至?xí)蚋鞣N原因突然改變：
或許你認(rèn)為，如果一個系統(tǒng)有數(shù)百個進(jìn)程，那么如果其中一小部分進(jìn)程變得緩慢或無法訪問，這應(yīng)該不會有太大的影響。
故障的問題在于它們具有蔓延傳播的潛力，會從一個進(jìn)程傳播到另一個進(jìn)程，直到整個系統(tǒng)崩潰。這種情況發(fā)生在系統(tǒng)組件相互依賴的情況下，其中一個組件的故障會增加其他組件故障的概率。
通常需要采取足夠大的糾正措施來打破這個循環(huán)，比如暫時阻止流量到首次復(fù)制品。不幸的是，一旦這些故障開始，它們非常難以減輕，而預(yù)防故障從一個組件傳播到另一個組件是最佳方法。
本文鏈接：http://www.tebozhan.com/showinfo-26-14015-0.html分布式系統(tǒng)的挑戰(zhàn)：八個關(guān)鍵故障的解讀
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號