處理瞬態失效的建議
適用於此 Power Platform Well-Architected 可靠性檢查表建議：
| 回復：05 | 透過執行錯誤處理和瞬態失效處理來增強工作負載的彈性。 在解決方案中建置功能以處理元件失效和瞬態錯誤。 |
|---|
本指南介紹了有關處理雲端應用程式中瞬態失效的建議。 所有與遠端服務和資源通訊的應用程式都必須對瞬態失效敏感。 對於在雲端中執行的應用程式來說尤其如此，由於環境的性質和網際網路連線的性質，可能會更頻繁地遇到這種類型的失效。 瞬態失效包括元件和服務的網路連線瞬態遺失、服務瞬態無法使用以及服務繁忙時發生的逾時。 這些失效通常可以自我糾正，因此，如果在適當的延遲後重複該動作，則很可能會成功。
關鍵設計原則
瞬態失效可能發生在任何環境、任何平台或作業系統，以及任何類型的應用程式中。
挑戰
即使應用程式在所有可預見的情況下經過了徹底的測試，瞬態失效也會對應用程式的感知可用性產生重大影響。 為了確保您的 Power Platform 工作負載能夠可靠地執行，您需要確保它能夠應對以下挑戰：
應用程式必須能夠在失效發生時偵測到失效，並確定失效是否可能是瞬態的、持久的還是最終失效。 當發生失效時，不同的資源可能會傳回不同的回應，而這些回應也可能根據作業的內容而有所不同。 例如，應用程式從自訂連接器擷取資料時的錯誤回應，可能與應用程式執行雲端流程並等待回應時的回應不同。
如果應用程式確定失效可能是瞬態，則它必須能夠重試該作業。
應用程式必須使用適當的重試原則。 該策略指定應用程式應重試的次數、每次嘗試之間的延遲，以及嘗試失敗後要執行的動作。 適當的嘗試次數和每次嘗試之間的延遲通常難以確定。 該策略因資源類型以及資源和應用程式的目前作業條件而異。
一般指導方針
以下指南可以幫助您為應用程式設計合適的瞬態失效處理機制。
確定是否有內建重試機制
您連接到的某些服務可能已經提供了瞬態失效處理機制。 它使用的重試原則通常是根據目標服務的性質和要求量身定制的。 或者，服務的 REST 介面可能會傳回訊息，幫助您確定重試是否合適以及在下次重試之前等待多長時間。
當內建重試機制可用時，您應該使用該機制，除非您有特定且易於理解的要求，使其他的重試行為更合適。
確定作業是否適合重試
只有當失效是瞬態的 (通常由錯誤的性質指示) 並且重試時作業至少有一定成功的可能性時，才執行重試作業。 重試嘗試無效作業的作業是沒有意義的，例如更新 Microsoft Dataverse 中不存在或使用者無權執行的資料列，或呼叫不存在的 API 端點。
只有當您可以確定重試的全部效果、充分理解並可以驗證條件時，才實施重試。 請記住，從您無法控制的資源和服務傳回的錯誤可能會隨著時間的推移而改變，您可能需要重新存取瞬態失效偵測邏輯。
當您開發從應用程式呼叫的單一元件或服務時，請確保傳回錯誤碼和訊息，以協助用戶端確定是否應該重試失敗的作業。 考慮指示用戶端是否應該重試該作業；例如，傳回 isTransient 值。 如果您建置 Web 服務，請考慮傳回服務合約中定義的自訂錯誤。
確定適當的重試計數和間隔
根據使用案例類型最佳化重試計數和間隔。 如果重試次數不夠，應用程式將無法完成作業並且可能失敗。 如果重試次數太多，或嘗試之間的間隔太短，應用程式可能會長時間佔用資源，這會對應用程式的運作狀況產生不利影響。
根據作業類型調整時間間隔和重試次數的值。 例如，如果作業是使用者互動的一部分，則間隔應該很短，並且只應嘗試幾次重試。 透過使用此方法，可以避免讓使用者等待回應。 如果該作業是長時間執行或關鍵工作流程的一部分，其中取消和重新啟動流程成本高昂或耗時，則最好在嘗試之間等待更長的時間並重試更多次。
請記住，確定重試之間的適當間隔是設計成功策略最困難的部分。 典型策略使用以下類型的重試間隔：
指數區間。 應用程式在第一次重試之前等待一小段時間，然後以指數方式增加每次後續重試之間的時間。 例如，它可能會在 3 秒、12 秒、30 秒等後重試該作業。
固定間隔。 應用程式在每次嘗試之間等待相同的時間。
立即重試。 有時瞬態失效很短暫，可以立即重試作業，因為如果在應用程式發送下一個要求時清除失效，則作業可能會成功。 但是，不應立即重試一次以上。 如果立即重試失敗，則應切換到替代策略，例如指數間隔或遞補動作。
做為一般準則，對背景作業使用指數間隔策略，對互動式作業使用立即或固定間隔重試原則。 在這兩種情況下，都應選擇延遲和重試計數，以便所有重試嘗試的最大延遲都在所需的端對端延遲要求範圍內。
請考慮影響重試作業的總體最大逾時的所有因素組合。 這些因素包括失敗的連線產生反應所需的時間、重試嘗試之間的延遲以及最大重試次數。 所有這些時間的總和可能會導致整體作業時間較長，尤其是當您使用指數延遲策略時，其中每次失敗後重試之間的間隔會快速增長。 如果流程必須滿足特定的服務等級協定 (SLA)，則總作業時間 (包括所有逾時和延遲) 必須在 SLA 中定義的限制內。
不要實施過於激進的重試原則。 這些策略的間隔太短或重試太頻繁。 它們可能會對目標資源或服務產生不利影響。 這些策略可能會阻止資源或服務從過載狀態恢復，並且它將繼續阻止或拒絕要求。 這種情況會導致惡性循環，越來越多的要求被發送到資源或服務。 因此，其恢復能力進一步降低。
選擇重試間隔時請考慮作業逾時，以避免立即啟動後續嘗試 (例如，如果逾時期限與重試間隔相似)。
使用錯誤類型或從服務傳回的錯誤碼和訊息，來最佳化重試次數和重試間隔。 例如，某些例外狀況或錯誤碼 (例如 HTTP 代碼 503、服務不可用、回應中帶有 Retry-After 標頭) 可能指示錯誤可能持續多長時間，或者服務失敗並且不會回應任何後續嘗試。
避免反模式
在大多數情況下，避免包含重複的重試程式碼層的實作。 避免包含級聯重試機制的設計，或在涉及要求層次結構的作業的每個階段實作重試的設計，除非您有這樣做的特定要求。 在這些特殊情況下，請使用防止過多重試和延遲時間的策略，並確保您了解後果。 例如，假設一個元件向另一個元件發出要求，然後該元件存取目標服務。 如果您對兩個呼叫執行的重試次數均為 3，則該服務總共會進行 9 次重試。 許多服務和資源都實現了內建的重試機制。 如果您需要在更高層級實作重試，您應該研究如何停用或修改這些機制。
永遠不要實施無止盡的重試機制。 這樣做可能會阻止資源或服務從過載情況中恢復，並導致限制和拒絕連線持續較長時間。
切勿多次執行立即重試。
存取 Azure 上的服務和資源時，避免使用固定重試間隔，尤其是重試嘗試次數較多時。 這種情況下的最佳方法是指數間隔策略。
測試重試原則和實作
在盡可能廣泛的情況下全面測試重試原則，尤其是當應用程式及其使用的目標資源或服務都處於極端負載時。 若要在測試期間檢查行為，您可以：
將瞬態和非瞬態失效注入服務。 例如，發送無效要求或新增偵測測試要求，並回應不同類型錯誤的程式碼。
建立資源或服務的模型，該模型傳回實際服務可能傳回的一系列錯誤。 涵蓋重試原則旨在偵測的所有類型的錯誤。
對於您建立和部署的自訂服務，透過瞬態停用服務或使服務過載來強制發生瞬態錯誤。 (請勿嘗試使 Azure 中的任何共用資源或共用服務過載。)
執行高負載因子和並行測試，以確保重試機制和策略在這些條件下正常運作。 這些測試還有助於確保重試不會對用戶端的作業產生不利影響，也不會在要求之間造成交叉污染。
管理重試原則設定
重試原則是重試原則所有元素的組合。 它定義了確定失效是否可能是瞬態的偵測機制、要使用的間隔類型 (如固定或指數)、實際間隔值以及重試次數。
只有當它們適合您的情境時，才利用內建或預設重試原則。 這些策略通常是通用的。 在某些情況下，它們可能滿足您的全部需求，但在其他情況下，它們提供的選項可能無法滿足您的特定要求。 要確定最合適的值，您需要執行測試以了解這些設定如何影響您的應用程式。
記錄和追蹤瞬態和非瞬態失效
做為重試原則的一部分，請加入例外狀況處理和其他記錄重試嘗試的工具。 偶爾出現瞬態失效和重試是正常現象，並不表示有問題。 然而，定期和不斷增加的重試次數通常表示存在的問題可能導致失效或降低應用程式效能和可用性。
將瞬態失效記錄為警告項目而不是錯誤項目，以便監控系統不會將其偵測為可能觸發錯誤警示的應用程式錯誤。
考慮在記錄項目中儲存一個值，該值指示重試是由服務中的限制還是由其他類型的失效 (例如連接失效) 引起的，以便您可以在資料分析期間區分它們。 限制錯誤數量的增加通常表示應用程式存在設計缺陷，或需要在環境中添加 Premium 容量。
考慮實作遙測和監控系統，該系統可以在失效數量和發生率、平均重試次數或作業成功之前經過的總時間增加時發出警示。
管理不斷失敗的作業
考慮如何處理每次嘗試都失敗的作業。 這樣的情況是不可避免的。
儘管重試原則定義了作業應重試的最大次數，但它並不能阻止應用程式以相同的重試次數重複該作業。 例如，在應用程式中提交表單可能會觸發流程。 重試原則可能會偵測到連線逾時，並將其視為瞬態失效。 該流程將重試該作業指定的次數，然後放棄。 但是，當同一使用者或新使用者嘗試再次提交表單時，即使可能繼續失敗，也會再次嘗試該作業。
應用程式可以間歇性地定期測試服務，並將要求之間的間隔拉長，以偵測服務何時可用。 適當的間隔取決於作業的重要性和服務的性質等因素。 其可能從幾分鐘到幾個小時之間。 當測試成功後，應用程式可以恢復正常作業，並將要求傳遞給新恢復的服務。
同時，您也許能執行一些替代作業，希望該服務將很快可用。 例如，也許可以將服務要求儲存在佇列或資料存放區中，稍後再重試。 或者您可能必須向使用者傳回一則訊息，以指示該應用程式不可用。
其他考量
當您決定策略的重試次數和重試間隔的值時，請考慮服務或資源的作業是否為長時間運作或多步驟作業的一部分。 當一個作業步驟失敗時，補償所有其他已經成功的作業步驟可能很困難或昂貴。 在這種情況下，只要該策略不會透過持有或鎖定稀缺資源來阻止其他作業，就可以接受較長的間隔和大量重試。
請考慮重試相同的作業是否會導致資料不一致。 如果重複多步驟過程的某些部分且作業不是冪等的，則可能會出現不一致。 例如，如果重複將記錄插入 Microsoft Dataverse 的作業，可能會導致資料表中的值不正確。 或者，如果您重複向使用者發送通知的作業，他們可能會收到重複的訊息。
考慮重試作業的範圍。 例如，在包含多個作業的層級實作重試程式碼並在其中一個作業失敗時，重試所有作業可能會更容易。 但是，這樣做可能會導致冪等性問題或不必要的復原作業。
如果您選擇包含多個作業的重試範圍，請在確定重試間隔、監視作業的運作時間，以及發出失效警示之前，考慮所有作業的總延遲。
Power Platform 簡易化
以下各節介紹可用於管理瞬態失效的機制。
Power Automate
Power Automate 包含一項功能，可在作業失敗時重試作業。 在每個動作層級上設定此功能。 瞭解如何降低風險和規劃專案中 Power Automate 的錯誤處理。 Power Automate 還提供將自訂錯誤和資料傳回呼叫應用程式或流程的動作。
某些瞬態流量可能是由輸送量和要求限制引起的。 了解自動化、排程和即時流程的限制，以及要求限制和分配。
使用範圍和運行后設置在雲端流 中配置錯誤和異常處理。
Power Apps
Power Apps 畫布應用程式提供檢查連接狀態的功能，從而允許它們在應用程式離線時表現不同。 瞭解如何開發支持離線的畫布應用。
您也可以在畫布應用程式中使用 Error、IfError、IsError 和 IsBlankOrError 函式來決定發生錯誤時，下一步要執行的作業。
了解有關 Power Apps 中的瞬態失效處理的更多資訊：
Azure 和自訂連接器
如果工作負載連接到 Azure 服務，請了解如何使用 Azure Well-Architected Framework 處理瞬態失效。
若要管理自訂連接器對錯誤的回應，請遵循編碼標準。
Application Insights
使用 Application Insights 整合來記錄 Power Automate 和 Power Apps 中的錯誤：
- 設定 Application Insights 方式 Power Automate （預覽版）
- 使用 analyze system-generated logs using Application Insights in Power Apps
相關資訊
Dynamics 365 SaaS 應用的業務連續性和災難恢復
可靠性檢查清單
請參閱完整的建議集。