有“韌性”才能更“任性”|微軟云原生韌性設(shè)計(jì)指南

面對(duì)復(fù)雜多變的業(yè)務(wù)和運(yùn)維環(huán)境，很多人絞盡腦汁想要維持業(yè)務(wù)的持續(xù)運(yùn)轉(zhuǎn)。

然而很多時(shí)候，無(wú)論刪庫(kù)跑路導(dǎo)致企業(yè)丟失所有關(guān)鍵業(yè)務(wù)數(shù)據(jù)，或外部施工出錯(cuò)挖斷光纜電線，甚至某些內(nèi)部或外部基礎(chǔ)服務(wù)上一個(gè)小小的錯(cuò)誤配置導(dǎo)致半個(gè)地球范圍內(nèi)的服務(wù)中斷……所有這些或大或小的問(wèn)題，總會(huì)讓很多人手忙腳亂處理半天，還會(huì)讓業(yè)務(wù)甚至企業(yè)聲譽(yù)遭受不小的影響。

雖然那句話說(shuō)得好：破壞穩(wěn)態(tài)的難度越大，我們對(duì)系統(tǒng)行為的信心就越強(qiáng)；并且只要能發(fā)現(xiàn)某個(gè)弱點(diǎn)，我們就有了一個(gè)改進(jìn)目標(biāo)。

然而以往在本地部署和運(yùn)行關(guān)鍵應(yīng)用時(shí)，包括基礎(chǔ)架構(gòu)、底層硬件在內(nèi)的很多因素可由企業(yè)自行掌控，因此發(fā)現(xiàn)并解決弱點(diǎn)還是好處理的（也許需要投入大量資金和人力）。但當(dāng)企業(yè)開(kāi)始上云，通過(guò)云平臺(tái)運(yùn)行這些關(guān)鍵應(yīng)用時(shí)，底層基礎(chǔ)架構(gòu)的管理和維護(hù)是由云平臺(tái)承擔(dān)的，這時(shí)又該如何解決弱點(diǎn)，打造更穩(wěn)定、更有韌性的運(yùn)維環(huán)境和應(yīng)用程序？

本文將從設(shè)計(jì)思路角度出發(fā)，告訴你如何提高云原生應(yīng)用的韌性，確保在遇到事件后業(yè)務(wù)依然能夠穩(wěn)妥運(yùn)行。

與遠(yuǎn)程服務(wù)和資源通信的所有應(yīng)用程序必須對(duì)臨時(shí)性故障敏感。對(duì)于云中運(yùn)行的應(yīng)用程序尤其如此，因?yàn)槠洵h(huán)境的性質(zhì)與通過(guò)互聯(lián)網(wǎng)建立連接的特點(diǎn)，意味著更容易遇到此類問(wèn)題。臨時(shí)性故障包括客戶端和服務(wù)瞬間斷開(kāi)網(wǎng)絡(luò)連接、后臺(tái)服務(wù)暫時(shí)不可用，或者并發(fā)過(guò)大出現(xiàn)的超時(shí)等。這些錯(cuò)誤通常是可以自我修復(fù)的，如果能把故障影響控制在一定范圍內(nèi)，則可將對(duì)最終用戶的影響降至最低。

為什么云中會(huì)出現(xiàn)臨時(shí)性故障？

任何環(huán)境、任何平臺(tái)或操作系統(tǒng)以及任何類型的應(yīng)用程序都會(huì)發(fā)生臨時(shí)性故障。在本地基礎(chǔ)架構(gòu)上運(yùn)行的解決方案中，應(yīng)用程序及其組件的性能和可用性通常由昂貴且利用率不足的冗余硬件來(lái)保證。雖然此方法使故障的可能性降低，但仍可能導(dǎo)致臨時(shí)性故障，甚至因外部電源/網(wǎng)絡(luò)問(wèn)題或其他災(zāi)難情況等不可預(yù)測(cè)的事件而中斷。

托管型云服務(wù)（PaaS）可以跨多個(gè)計(jì)算節(jié)點(diǎn)使用共享資源、冗余、自動(dòng)故障轉(zhuǎn)移和動(dòng)態(tài)資源分配，實(shí)現(xiàn)更高的整體可用性。但是這些環(huán)境的性質(zhì)意味著更可能發(fā)生臨時(shí)性故障，原因包括：

• 云環(huán)境中的許多資源是共享的，為了有效管理這些資源，云通常會(huì)嚴(yán)格管控對(duì)這些資源的訪問(wèn)。例如，某些服務(wù)在負(fù)載上升到特定級(jí)別，或到達(dá)吞吐量比率上限時(shí)，會(huì)拒絕額外連接以便處理現(xiàn)有請(qǐng)求，并為所有現(xiàn)存用戶維持服務(wù)性能。限制有助于為共享資源的鄰居與其他租戶維持服務(wù)質(zhì)量。

• 云環(huán)境是使用大量商用硬件單元構(gòu)建而成的。云環(huán)境將負(fù)載動(dòng)態(tài)分散到多個(gè)計(jì)算單元和基礎(chǔ)架構(gòu)組件上以獲得更多性能，并通過(guò)自動(dòng)回收或更換故障單元來(lái)提供可靠性。這種動(dòng)態(tài)性意味著可能偶爾會(huì)發(fā)生臨時(shí)性故障或暫時(shí)性連接失敗。

• 在應(yīng)用程序與資源及其使用的服務(wù)之間通常有多個(gè)硬件組件，包括網(wǎng)絡(luò)基礎(chǔ)架構(gòu)，例如路由器和負(fù)載均衡器。這些附加的組件偶爾會(huì)導(dǎo)致額外的連接延遲或臨時(shí)性連接故障。

• 客戶端與服務(wù)器之間的網(wǎng)絡(luò)狀況會(huì)不時(shí)改變，尤其是通過(guò)互聯(lián)網(wǎng)通信時(shí)。即使在本地位置，高流量負(fù)載也可能減慢通信速度，并造成間歇性的連接故障。

面臨的挑戰(zhàn)

臨時(shí)性故障可能會(huì)對(duì)用戶感知的可用性產(chǎn)生巨大影響，即使應(yīng)用程序已在所有可預(yù)見(jiàn)的情況下進(jìn)行了全面測(cè)試。若要確保云托管的應(yīng)用程序可靠運(yùn)行，應(yīng)用程序必須能夠應(yīng)對(duì)以下挑戰(zhàn)：

• 應(yīng)用程序必須能夠檢測(cè)到故障的發(fā)生，并確定這些故障可能是臨時(shí)性的、持久性的還是終端故障。發(fā)生故障時(shí)，不同資源可能返回不同響應(yīng)，這些響應(yīng)可能會(huì)根據(jù)不同操作而有所不同。例如，針對(duì)從存儲(chǔ)讀取時(shí)所發(fā)生錯(cuò)誤返回的響應(yīng)，與針對(duì)寫入存儲(chǔ)時(shí)所發(fā)生錯(cuò)誤返回的響應(yīng)不同。許多資源和服務(wù)都妥善制定了臨時(shí)性故障的策略。但是若不提供此類信息，則很難發(fā)現(xiàn)故障的性質(zhì)，以及故障是否是臨時(shí)性的。

• 如果確定故障可能是臨時(shí)性的，應(yīng)用程序必須能夠重試操作，并跟蹤操作重試的次數(shù)。

• 應(yīng)用程序必須使用適當(dāng)?shù)闹卦嚥呗?。此策略指定?yīng)用程序應(yīng)該重試的次數(shù)、每?jī)纱螄L試的延遲時(shí)間，以及嘗試失敗后執(zhí)行的操作。適當(dāng)?shù)膰L試次數(shù)以及每?jī)纱螄L試的延遲時(shí)間通常難以確定，會(huì)根據(jù)資源類型以及應(yīng)用程序本身的當(dāng)前操作條件而有所不同。

韌性設(shè)計(jì)指南

以下指南將幫助您為應(yīng)用程序設(shè)計(jì)合適的臨時(shí)性故障處理機(jī)制：

確定是否存在內(nèi)置重試機(jī)制 

• 許多服務(wù)提供SDK或包含臨時(shí)性故障處理機(jī)制的客戶端庫(kù)。服務(wù)使用的重試策略通常是根據(jù)目標(biāo)服務(wù)的性質(zhì)和要求定制的?；蛘邔?duì)于確定重試是否正確，以及在下一次嘗試重試之前要等待多長(zhǎng)時(shí)間方面，服務(wù)的REST接口可能會(huì)返回有用的信息。

• 如果可用，請(qǐng)使用內(nèi)置重試機(jī)制，除非有使不同重試行為更合適的具體且明確的要求。

確定操作是否適合重試 

• 應(yīng)該僅在暫時(shí)性故障，以及在重新嘗試時(shí)至少有一定成功的可能性之下才進(jìn)行重試操作。對(duì)于指示無(wú)效操作（如對(duì)不存在的項(xiàng)進(jìn)行數(shù)據(jù)庫(kù)更新，或?qū)Πl(fā)生致命錯(cuò)誤的服務(wù)或資源的請(qǐng)求）的操作，重新嘗試是沒(méi)有意義的。

• 一般而言，只有在能夠確定操作的全部影響并充分了解狀況并可進(jìn)行驗(yàn)證時(shí)，才建議實(shí)施重試。否則應(yīng)該由調(diào)用代碼來(lái)實(shí)施重試。請(qǐng)記住，從無(wú)法控制的資源與服務(wù)返回的錯(cuò)誤可能會(huì)隨著時(shí)間而演進(jìn)，可能需要重新建立訪問(wèn)臨時(shí)性故障的檢測(cè)邏輯。

• 創(chuàng)建服務(wù)或組件時(shí)，請(qǐng)考慮實(shí)現(xiàn)錯(cuò)誤檢查代碼和消息處理，以幫助客戶端確定是否應(yīng)該重試失敗的操作。特別是，指示客戶端是否應(yīng)該重試該操作，并在下一次重試嘗試之前建議一個(gè)適當(dāng)?shù)难舆t。如果構(gòu)建Web服務(wù)，請(qǐng)考慮返回在服務(wù)契約中定義的自定義錯(cuò)誤。即使通用客戶端可能無(wú)法讀取這些信息，但在構(gòu)建自定義客戶端時(shí)它們將非常有用。

確定適當(dāng)?shù)闹卦囉?jì)數(shù)與間隔 

• 優(yōu)化用例類型的重試計(jì)數(shù)和間隔是至關(guān)重要的。如果沒(méi)有重試足夠次數(shù)，應(yīng)用程序?qū)o(wú)法完成操作，并可能經(jīng)歷失?。蝗绻卦囘^(guò)多次，或者重試間隔過(guò)短，應(yīng)用程序可能會(huì)長(zhǎng)期占用線程、連接和內(nèi)存等資源，這將對(duì)應(yīng)用程序的運(yùn)行狀況產(chǎn)生不利影響。

• 時(shí)間間隔和重試次數(shù)的適當(dāng)值取決于正在嘗試的操作類型。例如，如果操作是用戶交互的一部分，那么間隔應(yīng)該很短，并且只嘗試幾次，以避免讓用戶等待響應(yīng)(這會(huì)保持打開(kāi)的連接并降低其他用戶的可用性；如果操作是長(zhǎng)時(shí)間運(yùn)行或關(guān)鍵工作流的一部分，其中取消和重新啟動(dòng)流程是費(fèi)時(shí)費(fèi)力的，那么在嘗試和重試之間等待更長(zhǎng)時(shí)間是合適的。

• 確定重試之間的適當(dāng)間隔是設(shè)計(jì)成功策略中最困難的部分。典型策略使用以下類型的重試間隔：

  （a）指數(shù)延遲：應(yīng)用程序在第一次重試之前短暫等待，每個(gè)后續(xù)重試的間隔時(shí)間呈指數(shù)增加。例如，在3秒、12秒、30秒后重試操作。

  （b）增量間隔：應(yīng)用程序在第一次重試之前短暫等待，每個(gè)后續(xù)重試的間隔時(shí)間增量遞增。例如，在3秒、7秒、13秒后重試操作。

  （c）固定間隔：應(yīng)用程序每次嘗試的間隔時(shí)間相同。例如，固定每3秒重試操作

  （d）立即重試：有時(shí)臨時(shí)性故障很短暫，可能是由于網(wǎng)絡(luò)數(shù)據(jù)包沖突或硬件組件出現(xiàn)峰值等事件。在此情況下，適合立即重試操作，因?yàn)槿绻收显诓僮髯寫?yīng)用程序組合并發(fā)送下一個(gè)請(qǐng)求時(shí)已清除，則操作可能會(huì)成功。但是不應(yīng)有多次立即重試嘗試，如果立即重試失敗，應(yīng)切換到備用策略，例如指數(shù)退讓或回退操作。

  （f）隨機(jī)化：上面列出的任何重試策略都可能包括隨機(jī)化，以防止客戶機(jī)的多個(gè)實(shí)例同時(shí)發(fā)送隨后的重試嘗試。例如，一個(gè)實(shí)例可能在3秒、11秒、28秒之后重試該操作，而另一個(gè)實(shí)例可能在4秒、12秒、26秒之后重試該操作。隨機(jī)化是一種有用的技術(shù)，可以與其他策略相結(jié)合。

• 一般指導(dǎo)原則是，為后臺(tái)操作使用指數(shù)退讓策略，為交互式操作使用立即或固定間隔重試策略。在上述兩種情況下，應(yīng)該選擇延遲與重試計(jì)數(shù)，使所有重試的延遲上限都在所需的端到端延遲要求范圍內(nèi)。

• 考慮影響重試操作的總的最大超時(shí)的所有因素的組合。這些因素包括失敗連接產(chǎn)生響應(yīng)所花費(fèi)的時(shí)間（通常由客戶端中的超時(shí)值設(shè)置）以及重試嘗試和最大重試次數(shù)之間的延遲。所有這些時(shí)間的總和可能會(huì)導(dǎo)致較長(zhǎng)的總體操作時(shí)間，特別是當(dāng)使用指數(shù)延遲策略時(shí)，其中重試間隔在每次失敗后迅速增長(zhǎng)。如果流程必須滿足特定的服務(wù)水平協(xié)議SLA，則整個(gè)操作時(shí)間（包括所有超時(shí)和延遲）必須在SLA定義的限制內(nèi)。

• 過(guò)于激進(jìn)的重試策略（間隔太短或重試太頻繁）可能會(huì)對(duì)目標(biāo)資源或服務(wù)產(chǎn)生不利影響。這可能會(huì)阻止資源或服務(wù)從其重載狀態(tài)中恢復(fù)，并且它將繼續(xù)阻塞或拒絕請(qǐng)求。這導(dǎo)致了一個(gè)惡性循環(huán)，越來(lái)越多的請(qǐng)求被發(fā)送到資源或服務(wù)，從而進(jìn)一步降低了其恢復(fù)能力。

• 在選擇重試間隔時(shí)，要考慮操作的超時(shí)時(shí)間，以避免立即啟動(dòng)后續(xù)的嘗試（例如，如果超時(shí)時(shí)間與重試間隔類似）。還要考慮是否需要將可能的總時(shí)間（超時(shí)加上重試間隔）保持在特定的總時(shí)間以下。超時(shí)時(shí)間異常短或異常長(zhǎng)的操作可能會(huì)影響等待多長(zhǎng)時(shí)間以及重試操作的頻率。

• 使用異常的類型和它包含的任何數(shù)據(jù)，或者從服務(wù)返回的錯(cuò)誤代碼和消息，來(lái)優(yōu)化重試的間隔和次數(shù)。例如，一些異常或錯(cuò)誤代碼（例如響應(yīng)中帶有Retry-After頭的HTTP代碼503 Service Unavailable）可能指示錯(cuò)誤可能持續(xù)多長(zhǎng)時(shí)間，或者服務(wù)已經(jīng)失敗，不會(huì)響應(yīng)任何后續(xù)的嘗試。

避免反模式 

• 在絕大多數(shù)情況下，應(yīng)該避免包含重復(fù)重試代碼層的實(shí)現(xiàn)。避免包含級(jí)聯(lián)重試機(jī)制的設(shè)計(jì)，或者在涉及請(qǐng)求層次結(jié)構(gòu)的操作的每個(gè)階段實(shí)現(xiàn)重試的設(shè)計(jì)，除非有要求這樣做的特定需求。在這些異常情況下，請(qǐng)使用防止過(guò)多重試次數(shù)和延遲時(shí)間的策略，并確保理解其后果。例如，如果某個(gè)組件對(duì)另一個(gè)組件發(fā)出請(qǐng)求，后者再訪問(wèn)目標(biāo)服務(wù)，并且要對(duì)這兩個(gè)調(diào)用各實(shí)施重試三次，則總共會(huì)對(duì)該服務(wù)重試九次。許多服務(wù)和資源實(shí)施內(nèi)置重試機(jī)制，如果需要在較高級(jí)別實(shí)施重試，應(yīng)調(diào)查如何禁用或修改此設(shè)置。

• 永遠(yuǎn)不要實(shí)現(xiàn)無(wú)止境的重試機(jī)制。這可能會(huì)阻止資源或服務(wù)從過(guò)載情況中恢復(fù)，并導(dǎo)致節(jié)流和拒絕連接持續(xù)較長(zhǎng)時(shí)間。使用有限的次數(shù)或重試，或?qū)崿F(xiàn)一個(gè)模式（如斷路器），以允許服務(wù)恢復(fù)。

• 立即重試不要超過(guò)一次。

• 避免使用常規(guī)重試間隔，特別是當(dāng)訪問(wèn)Azure中的服務(wù)和資源時(shí)，有大量的重試嘗試時(shí)。在這種情況下，最優(yōu)的方法是采用具有斷路能力的指數(shù)后退策略。

• 防止同一客戶端的多個(gè)實(shí)例或不同客戶端的多個(gè)實(shí)例在同一時(shí)間發(fā)送重試。如果可能發(fā)生這種情況，請(qǐng)?jiān)谥卦囬g隔中引入隨機(jī)化。

測(cè)試重試策略與實(shí)施 

確保在盡可能廣泛的情況下全面測(cè)試重試策略實(shí)現(xiàn)，特別是當(dāng)應(yīng)用程序和它使用的目標(biāo)資源或服務(wù)都處于極端負(fù)載下時(shí)。要在測(cè)試期間檢查行為，可以：

• 將瞬態(tài)和非瞬態(tài)故障注入服務(wù)。例如，發(fā)送無(wú)效請(qǐng)求或添加檢測(cè)測(cè)試請(qǐng)求的代碼，并使用不同類型的錯(cuò)誤進(jìn)行響應(yīng)。

• 創(chuàng)建資源或服務(wù)的模擬，該模擬返回真實(shí)服務(wù)可能返回的一系列錯(cuò)誤。確保覆蓋了重試策略旨在檢測(cè)的所有類型的錯(cuò)誤。

• 如果是自己創(chuàng)建和部署的自定義服務(wù)，則通過(guò)臨時(shí)禁用或重載該服務(wù)來(lái)強(qiáng)制發(fā)生瞬態(tài)錯(cuò)誤(當(dāng)然，我們不應(yīng)該嘗試重載Azure中的任何共享資源或共享服務(wù))。

• 對(duì)于基于HTTP的API，可以考慮在自動(dòng)化測(cè)試中使用FiddlerCore庫(kù)，通過(guò)添加額外的往返時(shí)間或更改響應(yīng)（如HTTP狀態(tài)代碼、頭、正文或其他因素）來(lái)更改HTTP請(qǐng)求的結(jié)果。這樣就可以對(duì)故障條件的子集進(jìn)行確定性測(cè)試，無(wú)論是瞬時(shí)故障還是其他類型的故障。

• 執(zhí)行高負(fù)載系數(shù)和并發(fā)測(cè)試，以確保重試機(jī)制和策略在這些條件下正確工作，并且不會(huì)對(duì)客戶機(jī)的操作產(chǎn)生不利影響或?qū)е抡?qǐng)求之間的交叉污染。

管理重試策略配置 

• 重試策略是重試策略的所有元素的組合。它定義了確定故障是否可能是暫時(shí)的檢測(cè)機(jī)制、要使用的間隔類型（如常規(guī)、指數(shù)后退和隨機(jī)化）、實(shí)際間隔值和重試次數(shù)。

• 即使是最簡(jiǎn)單的應(yīng)用程序，也必須在許多地方實(shí)現(xiàn)重試，更復(fù)雜的應(yīng)用程序的每一層都必須實(shí)現(xiàn)重試?？紤]使用一個(gè)中心點(diǎn)來(lái)存儲(chǔ)所有策略，而不是在多個(gè)位置硬編碼每個(gè)策略的元素。例如，將間隔和重試計(jì)數(shù)等值存儲(chǔ)在應(yīng)用程序配置文件中，在運(yùn)行時(shí)讀取它們，并以編程方式構(gòu)建重試策略。這使得管理設(shè)置、修改和微調(diào)值以響應(yīng)不斷變化的需求和場(chǎng)景變得更加容易。但是，要設(shè)計(jì)系統(tǒng)來(lái)存儲(chǔ)這些值，而不是每次都重新讀取配置文件，并確保在無(wú)法從配置中獲得這些值時(shí)使用合適的默認(rèn)值。

• 在Azure云原生應(yīng)用程序中，考慮將用于構(gòu)建運(yùn)行時(shí)重試策略的值存儲(chǔ)在服務(wù)配置文件中，這樣就可以在不重啟應(yīng)用程序的情況下更改它們。

• 利用客戶端API中提供的內(nèi)置或默認(rèn)重試策略，但只在它們適合的場(chǎng)景使用。這些策略通常是通用的。在某些場(chǎng)景中，它們可能是所有必需的，但在其他場(chǎng)景中，它們可能不會(huì)提供所有選項(xiàng)來(lái)滿足特定需求。通過(guò)測(cè)試確定最合適的值，我們必須了解設(shè)置將如何影響應(yīng)用程序。

記錄和跟蹤瞬態(tài)和非瞬態(tài)故障 

• 作為重試策略的一部分，包括異常處理和記錄重試嘗試時(shí)的其他檢測(cè)。雖然偶爾出現(xiàn)短暫的故障和重試是可以預(yù)期的，并且并不表明有問(wèn)題，但定期的和不斷增加的重試次數(shù)通常是一個(gè)可能導(dǎo)致故障的問(wèn)題的指示器，或者當(dāng)前正在降低應(yīng)用程序的性能和可用性。

• 將瞬態(tài)故障記錄為警告項(xiàng)而不是錯(cuò)誤項(xiàng)，以便監(jiān)控系統(tǒng)不會(huì)將它們檢測(cè)為可能觸發(fā)錯(cuò)誤警報(bào)的應(yīng)用程序錯(cuò)誤。

• 考慮在日志條目中存儲(chǔ)一個(gè)值，該值指示重試是由服務(wù)中的節(jié)流引起的，還是由其他類型的錯(cuò)誤（如連接失?。┮鸬?，以便在分析數(shù)據(jù)時(shí)對(duì)它們進(jìn)行區(qū)分。節(jié)流錯(cuò)誤數(shù)量的增加通常表明應(yīng)用程序存在設(shè)計(jì)缺陷，或者需要轉(zhuǎn)向提供專用硬件的優(yōu)質(zhì)服務(wù)。

• 考慮測(cè)量和記錄包含重試機(jī)制的操作所花費(fèi)的總時(shí)間。這是暫時(shí)性錯(cuò)誤對(duì)用戶響應(yīng)時(shí)間、處理延遲和應(yīng)用程序用例效率的總體影響的一個(gè)很好的指示器。還要記錄發(fā)生的重試次數(shù)，以便了解影響響應(yīng)時(shí)間的因素。

• 考慮實(shí)現(xiàn)一個(gè)遙測(cè)和監(jiān)控系統(tǒng)，當(dāng)失敗的數(shù)量和比率、平均重試次數(shù)或操作成功所需的總時(shí)間增加時(shí)，該系統(tǒng)可以發(fā)出警報(bào)。

管理持續(xù)失敗的操作 

• 在某些情況下，每次行動(dòng)都會(huì)失敗，考慮如何處理這種情況是至關(guān)重要的。

• 盡管重試策略將定義一個(gè)操作應(yīng)該重試的最大次數(shù)，但它不會(huì)阻止應(yīng)用程序以相同的重試次數(shù)再次重復(fù)該操作。例如，如果一個(gè)訂單處理服務(wù)由于一個(gè)致命錯(cuò)誤而失敗，使其永久停止操作，重試策略可能會(huì)檢測(cè)到連接超時(shí)，并認(rèn)為這是一個(gè)暫時(shí)的錯(cuò)誤。代碼將重試指定次數(shù)的操作，然后放棄。然而當(dāng)另一個(gè)客戶下訂單時(shí)，該操作將再次嘗試——即使每次都肯定會(huì)失敗。

• 為了防止對(duì)不斷失敗的操作進(jìn)行不斷重試，考慮實(shí)現(xiàn)斷路器模式。在此模式中，如果指定時(shí)間窗口內(nèi)的失敗次數(shù)超過(guò)閾值，則請(qǐng)求將立即作為錯(cuò)誤返回給調(diào)用者，而不嘗試訪問(wèn)失敗的資源或服務(wù)。

• 應(yīng)用程序可以周期性地測(cè)試服務(wù)（斷斷續(xù)續(xù)的，請(qǐng)求之間的間隔很長(zhǎng)），以檢測(cè)服務(wù)何時(shí)可用。適當(dāng)?shù)拈g隔取決于場(chǎng)景，例如操作的關(guān)鍵程度和服務(wù)的性質(zhì)，可能是幾分鐘到幾個(gè)小時(shí)之間的任何時(shí)間。在測(cè)試成功時(shí)，應(yīng)用程序可以恢復(fù)正常操作，并將請(qǐng)求傳遞給新恢復(fù)的服務(wù)。

• 與此同時(shí)，可以退回到服務(wù)的另一個(gè)實(shí)例（可能在不同的數(shù)據(jù)中心或應(yīng)用程序中），使用提供兼容（可能更簡(jiǎn)單）功能的類似服務(wù)，或者執(zhí)行一些替代操作，希望該服務(wù)很快可用。例如，可以將服務(wù)請(qǐng)求存儲(chǔ)在隊(duì)列或數(shù)據(jù)存儲(chǔ)中，稍后再重放它們。否則我們可能會(huì)將用戶重定向到應(yīng)用程序的另一個(gè)實(shí)例，降低應(yīng)用程序的性能，但仍然提供可接受的功能，或者只是向用戶返回一條消息，指示該應(yīng)用程序目前不可用。

其他的考慮 

• 在決定重試次數(shù)和策略重試間隔的值時(shí)，請(qǐng)考慮服務(wù)或資源上的操作是否是長(zhǎng)時(shí)間運(yùn)行或多步驟操作的一部分。當(dāng)一個(gè)操作步驟失敗時(shí)，補(bǔ)償所有其他已經(jīng)成功的操作步驟可能是困難的或昂貴的。在這種情況下，很長(zhǎng)的間隔和大量的重試是可以接受的，只要它不通過(guò)持有或鎖定稀缺資源來(lái)阻塞其他操作。

• 請(qǐng)考慮重試同一操作是否可能導(dǎo)致數(shù)據(jù)不一致。如果重復(fù)多步驟流程的某些部分，且操作不是冪等的，則可能導(dǎo)致不一致。例如，遞增值的操作如果重復(fù)，將產(chǎn)生無(wú)效的結(jié)果。如果無(wú)法檢測(cè)到重復(fù)的消息，重復(fù)將消息發(fā)送到隊(duì)列的操作可能會(huì)導(dǎo)致消息使用者中出現(xiàn)不一致。要防止這種情況，請(qǐng)確保將每個(gè)步驟設(shè)計(jì)為冪等操作。

• 考慮將要重試的操作的范圍。例如，在包含多個(gè)操作的級(jí)別上實(shí)現(xiàn)重試代碼可能更容易，如果其中一個(gè)操作失敗，則重試所有操作。但是，這樣做可能會(huì)導(dǎo)致冪等問(wèn)題或不必要的回滾操作。

• 如果選擇一個(gè)包含多個(gè)操作的重試范圍，那么在確定重試間隔、監(jiān)視所花費(fèi)的時(shí)間以及發(fā)出失敗警報(bào)之前，請(qǐng)考慮所有操作的總延遲。

在為云原生應(yīng)用考慮韌性設(shè)計(jì)時(shí)，請(qǐng)務(wù)必慎重思索重試策略可能會(huì)如何影響共享應(yīng)用程序中的鄰居和其他租戶。激進(jìn)的重試策略可能導(dǎo)致其他用戶以及共享資源和服務(wù)的應(yīng)用程序出現(xiàn)越來(lái)越多的瞬時(shí)錯(cuò)誤。

同樣，我們的應(yīng)用程序可能會(huì)受到資源和服務(wù)的其他用戶所實(shí)現(xiàn)的重試策略影響。對(duì)于關(guān)鍵任務(wù)應(yīng)用程序，我們可以決定使用不共享的高級(jí)服務(wù)。這為我們提供了更多的負(fù)載控制以及相應(yīng)資源和服務(wù)的節(jié)流，這有助于證明額外的成本是合理的。

遵循上述思路，并結(jié)合具體情況進(jìn)行調(diào)整，我們就可以順利設(shè)計(jì)出具備足夠韌性的云原生應(yīng)用架構(gòu)。

希望本文對(duì)你能有所幫助。如果對(duì)這個(gè)話題感興趣，那么敬請(qǐng)期待后續(xù)發(fā)布的更多系列文章，我們將繼續(xù)從重試模式、斷路器模式等角度深入探討相關(guān)機(jī)制的實(shí)現(xiàn)思路和方法。更多精彩敬請(qǐng)期待！