摘要：微服務(wù)架構(gòu)的風(fēng)險(xiǎn)微服務(wù)架構(gòu)將應(yīng)用程序邏輯移動(dòng)到服務(wù)，并使用網(wǎng)絡(luò)層在它們之間進(jìn)行通信。在微服務(wù)架構(gòu)中，服務(wù)依賴(lài)于彼此。您始終只能部署其中一個(gè)，并且在驗(yàn)證新版本是否符合預(yù)期之后才，將負(fù)載均衡器指向新的。

摘要：本文屬于原創(chuàng)，歡迎轉(zhuǎn)載，轉(zhuǎn)載請(qǐng)保留出處：https://github.com/jasonGeng88/blog

https://blog.risingstack.com/designing-microservices-architecture-for-failure/

微服務(wù)架構(gòu)使得可以通過(guò)明確定義的服務(wù)邊界來(lái)隔離故障。但是像在每個(gè)分布式系統(tǒng)中一樣，發(fā)生網(wǎng)絡(luò)、硬件、應(yīng)用級(jí)別的錯(cuò)誤都是很常見(jiàn)的。由于服務(wù)依賴(lài)關(guān)系，任何組件可能暫時(shí)無(wú)法提供服務(wù)。為了盡量減少部分中斷的影響，我們需要構(gòu)建容錯(cuò)服務(wù)，來(lái)優(yōu)雅地處理這些中斷的響應(yīng)結(jié)果。

本文介紹了基于RisingStack 的 Node.js 咨詢(xún)和開(kāi)發(fā)經(jīng)驗(yàn)構(gòu)建和操作高可用性微服務(wù)系統(tǒng)的最常見(jiàn)技術(shù)和架構(gòu)模式。

如果你不熟悉本文中的模式，那并不一定意味著你做錯(cuò)了。建立可靠的系統(tǒng)總是會(huì)帶來(lái)額外的成本。

微服務(wù)架構(gòu)將應(yīng)用程序邏輯移動(dòng)到服務(wù)，并使用網(wǎng)絡(luò)層在它們之間進(jìn)行通信。這種通過(guò)網(wǎng)絡(luò)間通信代替單應(yīng)用程序內(nèi)調(diào)用的做法，會(huì)帶來(lái)額外的延遲，以及需要協(xié)調(diào)多個(gè)物理和邏輯組件的系統(tǒng)復(fù)雜度。分布式系統(tǒng)的復(fù)雜性增加也將導(dǎo)致更高的網(wǎng)絡(luò)故障率。

微服務(wù)體系結(jié)構(gòu)的最大優(yōu)勢(shì)之一是，團(tuán)隊(duì)可以獨(dú)立設(shè)計(jì)，開(kāi)發(fā)和部署他們的服務(wù)。他們對(duì)服務(wù)的生命周期擁有完全的所有權(quán)。這也意味著團(tuán)隊(duì)無(wú)法控制他們依賴(lài)的服務(wù)，因?yàn)樗锌赡苡刹煌膱F(tuán)隊(duì)管理。使用微服務(wù)架構(gòu)，我們需要記住，提供者服務(wù)可能會(huì)臨時(shí)不可用，由于其他人員發(fā)行的錯(cuò)誤版本，配置以及其他更改等。

微服務(wù)架構(gòu)的最大優(yōu)點(diǎn)之一是您可以隔離故障，并在當(dāng)組件多帶帶故障時(shí)，進(jìn)行優(yōu)雅的服務(wù)降級(jí)。 例如，在中斷期間，照片共享應(yīng)用程序中的客戶(hù)可能無(wú)法上傳新圖片，但仍可以瀏覽，編輯和共享其現(xiàn)有照片。

微服務(wù)容錯(cuò)隔離

在大多數(shù)情況下，由于分布式系統(tǒng)中的應(yīng)用程序相互依賴(lài)，因此很難實(shí)現(xiàn)這種優(yōu)雅的服務(wù)降級(jí)，您需要應(yīng)用幾種故障轉(zhuǎn)移的邏輯（其中一些將在本文后面介紹），以為暫時(shí)的故障和中斷做準(zhǔn)備。

服務(wù)間彼此依賴(lài)，再?zèng)]有故障轉(zhuǎn)移邏輯下，服務(wù)全部失敗。

Google的網(wǎng)站可靠性小組發(fā)現(xiàn)，大約70％的中斷是由現(xiàn)有系統(tǒng)的變化引起的。當(dāng)您更改服務(wù)中的某些內(nèi)容時(shí)，您將部署新版本的代碼或更改某些配置 - 這總有可能會(huì)造成故障，或者引入新的bug。

在微服務(wù)架構(gòu)中，服務(wù)依賴(lài)于彼此。這就是為什么你應(yīng)該盡量減少故障并限制它的負(fù)面影響。要處理變更中的問(wèn)題，您可以實(shí)施變更管理策略和自動(dòng)回滾機(jī)制。

例如，當(dāng)您部署新代碼或更改某些配置時(shí)，您應(yīng)該先小范圍的進(jìn)行部分的替換，以漸進(jìn)式的方式替換服務(wù)的全部實(shí)例。在這期間，需要監(jiān)視它們，如果您發(fā)現(xiàn)它們對(duì)您的關(guān)鍵指標(biāo)有負(fù)面影響，應(yīng)立即進(jìn)行服務(wù)回滾，這稱(chēng)為“金絲雀部署”。

變更管理 - 回滾部署

另一個(gè)解決方案可能是您運(yùn)行兩個(gè)生產(chǎn)環(huán)境。您始終只能部署其中一個(gè)，并且在驗(yàn)證新版本是否符合預(yù)期之后才，將負(fù)載均衡器指向新的。這稱(chēng)為藍(lán)綠或紅黑部署。

回滾代碼不是壞事。你不應(yīng)該在生產(chǎn)中遺留錯(cuò)誤的代碼，然后考慮出了什么問(wèn)題。如果必要，越早回滾你的代碼越好。

實(shí)例由于出現(xiàn)故障、部署或自動(dòng)縮放的情況，會(huì)進(jìn)行持續(xù)啟動(dòng)、重新啟動(dòng)或停止操作。它可能導(dǎo)致它們暫時(shí)或永久不可用。為避免問(wèn)題，您的負(fù)載均衡器應(yīng)該從路由中跳過(guò)不健康的實(shí)例，因?yàn)樗鼈儺?dāng)前無(wú)法為客戶(hù)或子系統(tǒng)提供服務(wù)。

應(yīng)用實(shí)例健康狀況可以通過(guò)外部觀察來(lái)確定。您可以通過(guò)重復(fù)調(diào)用GET /health端點(diǎn)或通過(guò)自我報(bào)告來(lái)實(shí)現(xiàn)?，F(xiàn)在主流的服務(wù)發(fā)現(xiàn)解決方案，會(huì)持續(xù)從實(shí)例中收集健康信息，并配置負(fù)載均衡器，將流量?jī)H路由到健康的組件上。

自我修復(fù)可以幫助應(yīng)用程序從錯(cuò)誤中恢復(fù)過(guò)來(lái)。當(dāng)應(yīng)用程序可以采取必要步驟從故障狀態(tài)恢復(fù)時(shí)，我們就可以說(shuō)它是可以實(shí)現(xiàn)自我修復(fù)的。在大多數(shù)情況下，它由外部系統(tǒng)實(shí)現(xiàn)，該系統(tǒng)會(huì)監(jiān)視實(shí)例運(yùn)行狀況，并在較長(zhǎng)時(shí)間內(nèi)處于故障狀態(tài)時(shí)重新啟動(dòng)它們。自我修復(fù)在大多數(shù)情況下是非常有用的。但是在某些情況下，持續(xù)地重啟應(yīng)用程序可能會(huì)導(dǎo)致麻煩。 當(dāng)您的應(yīng)用程序由于超負(fù)荷或其數(shù)據(jù)庫(kù)連接超時(shí)而無(wú)法給出健康的運(yùn)行狀況時(shí)，這種情況下的頻繁的重啟就可能就不太合適了。

對(duì)于這種特殊的場(chǎng)景（如丟失的數(shù)據(jù)庫(kù)連接），要實(shí)現(xiàn)滿足它的高級(jí)自我修復(fù)的解決方案可能很棘手。在這種情況下，您需要為應(yīng)用程序添加額外的邏輯來(lái)處理邊緣情況，并讓外部系統(tǒng)知道實(shí)例不需要立即重新啟動(dòng)。

由于網(wǎng)絡(luò)問(wèn)題和我們系統(tǒng)的變化，服務(wù)經(jīng)常會(huì)失敗。然而，由于自我修復(fù)和負(fù)載均衡的保障，它們中的大多數(shù)中斷是臨時(shí)的，我們應(yīng)該找到一個(gè)解決方案，使我們的服務(wù)在這些故障時(shí)服務(wù)仍就可以工作。這就是故障轉(zhuǎn)移緩存的作用，它可以幫助并為我們的應(yīng)用程序在服務(wù)故障時(shí)提供必要的數(shù)據(jù)。

故障轉(zhuǎn)移緩存通常使用兩個(gè)不同的到期日期; 較短的時(shí)間告訴您在正常情況下緩存可以使用的過(guò)期時(shí)間，而較長(zhǎng)的時(shí)間可以在服務(wù)故障時(shí)緩存依舊可用的過(guò)期時(shí)間。

故障轉(zhuǎn)移緩存

請(qǐng)務(wù)必提及，只有當(dāng)服務(wù)使用過(guò)時(shí)的數(shù)據(jù)比沒(méi)有數(shù)據(jù)更好時(shí)，才能使用故障轉(zhuǎn)移緩存。

要設(shè)置緩存和故障轉(zhuǎn)移緩存，可以在 HTTP 中使用標(biāo)準(zhǔn)響應(yīng)頭。

例如，使用 max-age 屬性可以指定資源被視為有效的最大時(shí)間。使用 stale-if-error 屬性，您可以明確在出現(xiàn)故障的情況下，依舊可以從緩存中獲取資源的最大時(shí)間。

現(xiàn)代的 CDN 和負(fù)載均衡器都提供各種緩存和故障轉(zhuǎn)移行為，但您也可以為擁有標(biāo)準(zhǔn)可靠性解決方案的公司創(chuàng)建一個(gè)共享庫(kù)。

在某些情況下，我們無(wú)法緩存數(shù)據(jù)，或者我們想對(duì)其進(jìn)行更改，但是我們的操作最終都失敗了。對(duì)于此，我們可以重試我們的操作，因?yàn)槲覀兛梢灶A(yù)期資源將在一段時(shí)間后恢復(fù)，或者我們的負(fù)載均衡器將請(qǐng)求發(fā)送到了健康的實(shí)例上。

您應(yīng)該小心地為您的應(yīng)用程序和客戶(hù)端添加重試邏輯，因?yàn)榇罅康闹卦嚳赡軙?huì)使事情更糟，甚至阻止應(yīng)用程序恢復(fù)，如當(dāng)服務(wù)超載時(shí)，大量的重試只能使?fàn)顩r更糟。

在分布式系統(tǒng)中，微服務(wù)系統(tǒng)重試可以觸發(fā)多個(gè)其他請(qǐng)求或重試，并啟動(dòng)級(jí)聯(lián)效應(yīng)。為了最小化重試的影響，您應(yīng)該限制它們的數(shù)量，并使用指數(shù)退避算法來(lái)持續(xù)增加重試之間的延遲，直到達(dá)到最大限制。

當(dāng)客戶(hù)端（瀏覽器，其他微服務(wù)等）發(fā)起重試，并且客戶(hù)端不知道在處理請(qǐng)求之前或之后操作失敗時(shí)，您應(yīng)該為你的應(yīng)用程序做好冪等處理的準(zhǔn)備。例如，當(dāng)您重試購(gòu)買(mǎi)操作時(shí)，您不應(yīng)該再次向客戶(hù)收取費(fèi)用。為每個(gè)交易使用唯一的冪等值鍵可以幫助處理重試。

流量限制是在一段時(shí)間內(nèi)定義特定客戶(hù)或應(yīng)用程序可以接收或處理多少個(gè)請(qǐng)求的技術(shù)。例如，通過(guò)流量限制，您可以過(guò)濾掉造成流量峰值的客戶(hù)和服務(wù)，或者您可以確保您的應(yīng)用程序在自動(dòng)縮放無(wú)法滿足時(shí)，依然不會(huì)超載。

您還可以阻止較低優(yōu)先級(jí)的流量，為關(guān)鍵事務(wù)提供足夠的資源。

限流器可以阻止流量峰值產(chǎn)生

有一個(gè)不同類(lèi)型的限流器，叫做并發(fā)請(qǐng)求限制器。當(dāng)您有重要的端點(diǎn)，您不應(yīng)該被調(diào)用超過(guò)指定的次數(shù)，而您仍然想要能提供服務(wù)時(shí)，這將是有用的。

負(fù)載降級(jí)的一系列使用，可以確?？偸怯凶銐虻馁Y源來(lái)提供關(guān)鍵交易。它為高優(yōu)先級(jí)請(qǐng)求保留一些資源，不允許低優(yōu)先級(jí)的事務(wù)使用它們。負(fù)載降級(jí)開(kāi)關(guān)是根據(jù)系統(tǒng)的整體狀態(tài)做出決定，而不是基于單個(gè)用戶(hù)的請(qǐng)求量大小。負(fù)載降級(jí)有助于您的系統(tǒng)恢復(fù)，因?yàn)楫?dāng)你有一個(gè)偶發(fā)事件時(shí)（可能是一個(gè)熱點(diǎn)事件），您仍能保持核心功能的正常工作。

要了解有關(guān)限流器和負(fù)載降級(jí)的更多信息，我建議查看這篇Stripe的文章。

在微服務(wù)架構(gòu)中，我們想要做到讓我們的服務(wù)具備快速失敗與相互獨(dú)立的能力。為了在服務(wù)級(jí)別上進(jìn)行故障隔離，我們可以使用艙壁模式。你可以在本文的后面閱讀更多有關(guān)艙壁的內(nèi)容。

我們也希望我們的組件能夠快速失敗，因?yàn)槲覀儾幌Ｍ麑?duì)于有故障的服務(wù)，在請(qǐng)求超時(shí)后才斷開(kāi)。沒(méi)有什么比掛起的請(qǐng)求和無(wú)響應(yīng)的 UI 更令人失望。這不僅浪費(fèi)資源，而且還會(huì)影響用戶(hù)體驗(yàn)。我們的服務(wù)在調(diào)用鏈中是相互調(diào)用的，所以在這些延遲累加之前，我們應(yīng)該特別注意防止掛起操作。

你想到的第一個(gè)想法是對(duì)每個(gè)服務(wù)調(diào)用都設(shè)置明確的超時(shí)等級(jí)。這種方法的問(wèn)題是，您不能知道真正合理的超時(shí)值是多少，因?yàn)榫W(wǎng)絡(luò)故障和其他問(wèn)題發(fā)生的某些情況只會(huì)影響一兩次操作。在這種情況下，如果只有其中一些超時(shí)，您可能不想拒絕這些請(qǐng)求。

我們可以說(shuō)，在微服務(wù)種通過(guò)使用超時(shí)來(lái)達(dá)到快速失敗的效果是一種反模式的，你應(yīng)該避免使用它。取而代之，您可以應(yīng)用斷路器模式，依據(jù)操作的成功與失敗統(tǒng)計(jì)數(shù)據(jù)決定。

工業(yè)中使用艙壁將船舶劃分為幾個(gè)部分，以便在船體破壞的情況下，可以將船舶各個(gè)部件密封起來(lái)。

艙壁的概念在軟件開(kāi)發(fā)中可以被應(yīng)用在隔離資源上。

通過(guò)應(yīng)用艙壁模式，我們可以保護(hù)有限的資源不被耗盡。例如，對(duì)于一個(gè)有連接數(shù)限制的數(shù)據(jù)庫(kù)實(shí)例來(lái)說(shuō)，如果我們有兩種連接它的操作，我們采用可以采用兩個(gè)連接池的方式進(jìn)行連接，來(lái)代替僅采用一個(gè)共享連接池的方式。由于這種客戶(hù)端與資源進(jìn)行了隔離，超時(shí)或過(guò)度使用池的操作頁(yè)不會(huì)使其他操作失敗。

泰坦尼克號(hào)沉沒(méi)的主要原因之一是其艙壁設(shè)計(jì)失敗，水可以通過(guò)上面的甲板倒在艙壁的頂部，導(dǎo)致整個(gè)船體淹沒(méi)。

泰坦尼克號(hào)艙壁設(shè)計(jì)（無(wú)效的設(shè)計(jì)）

為了限制操作的持續(xù)時(shí)間，我們可以使用超時(shí)。超時(shí)可以防止掛起操作并保持系統(tǒng)響應(yīng)。然而，在微服務(wù)中使用靜態(tài)、精細(xì)的超時(shí)是一種反模式，因?yàn)槲覀兲幱诟叨葎?dòng)態(tài)的環(huán)境中，幾乎不可能提出在每種情況下都能正常工作的正確的時(shí)間限制。

替代這種靜態(tài)超時(shí)的手段是，我們可以使用斷路器來(lái)處理錯(cuò)誤。斷路器以現(xiàn)實(shí)世界的電子元件命名，因?yàn)樗鼈兊淖饔檬窍嗤?。您可以保護(hù)資源，并幫助他們使用斷路器進(jìn)行恢復(fù)。它們?cè)诜植际较到y(tǒng)中非常有用，因?yàn)樵诜植际较到y(tǒng)中，重復(fù)故障可能導(dǎo)致雪球效應(yīng)并使整個(gè)系統(tǒng)癱瘓。

當(dāng)特定類(lèi)型的錯(cuò)誤在短時(shí)間內(nèi)多次發(fā)生時(shí)，斷路器會(huì)被斷開(kāi)。開(kāi)路的斷路器可以防止進(jìn)一步的請(qǐng)求 - 就像我們平時(shí)所說(shuō)的電路跳閘一樣。斷路器通常在一定時(shí)間后關(guān)閉，在這期間可以為底層服務(wù)提供足夠的空間來(lái)恢復(fù)。

請(qǐng)記住，并不是所有的錯(cuò)誤都應(yīng)該觸發(fā)斷路器。例如，您可能希望跳過(guò)客戶(hù)端問(wèn)題，例如具有4xx響應(yīng)代碼的請(qǐng)求，但不包括5xx服務(wù)器端故障。一些斷路器也具有半開(kāi)狀態(tài)。在這種狀態(tài)下，服務(wù)發(fā)送第一個(gè)請(qǐng)求以檢查系統(tǒng)可用性，同時(shí)讓其他請(qǐng)求失敗。如果這個(gè)第一個(gè)請(qǐng)求成功，它將使斷路器恢復(fù)到關(guān)閉狀態(tài)并使流量流動(dòng)。否則，它保持打開(kāi)。

斷路器

您應(yīng)該不斷測(cè)試您系統(tǒng)的常見(jiàn)問(wèn)題，以確保您的服務(wù)可以抵抗各種故障。您應(yīng)經(jīng)常測(cè)試故障，讓您的團(tuán)隊(duì)具備故障處理的能力。

對(duì)于測(cè)試，您可以使用外部服務(wù)來(lái)標(biāo)識(shí)實(shí)例組，并隨機(jī)終止此組中的一個(gè)實(shí)例。這樣，您可以準(zhǔn)備單個(gè)實(shí)例故障，但您甚至可以關(guān)閉整個(gè)區(qū)域來(lái)模擬云提供商的故障。

最流行的測(cè)試解決方案之一是 Netflix 的 ChaosMonkey 彈性工具。

實(shí)施和運(yùn)行可靠的服務(wù)并不容易。 您需要付出很多努力，同時(shí)公司也要有相應(yīng)的財(cái)力投入。

可靠性有很多層次和方面，因此找到最適合您團(tuán)隊(duì)的解決方案很重要。您應(yīng)該使可靠性成為您的業(yè)務(wù)決策流程中的一個(gè)因素，并為其分配足夠的預(yù)算和時(shí)間。

動(dòng)態(tài)環(huán)境和分布式系統(tǒng)（如微服務(wù)）會(huì)導(dǎo)致更高的故障機(jī)率；

服務(wù)應(yīng)該做到故障隔離，到達(dá)優(yōu)雅降級(jí)，來(lái)提升用戶(hù)體驗(yàn)；

70％的中斷是由變化引起的，代碼回滾不是一件壞事；

做到服務(wù)快速失敗與獨(dú)立性。團(tuán)隊(duì)是無(wú)法控制他們所依賴(lài)的服務(wù)情況；

緩存、艙壁、斷路器和限流器等架構(gòu)模式與技術(shù)有助于構(gòu)建可靠的微服務(wù)架構(gòu)。