有关处理暂时性故障的建议
适用于此 Power Platform Well-Architected 可靠性检查表建议：
| 回复：05 | 通过实施错误处理和暂时性故障处理，增强工作负载的复原能力。 在解决方案中构建处理组件故障和暂时性错误的功能。 |
|---|
本指南介绍在云应用中处理暂时性故障的建议。 与远程服务和资源通信的所有应用程序必须对暂时性故障敏感。 对于云中运行的应用程序尤其如此，因为其环境的性质与通过 Internet 建立连接的特点，更容易遇到这种类型的故障。 暂时性故障包括组件和服务瞬间断开网络连接、服务暂时不可用，以及当服务繁忙时出现超时。 这些故障通常可自我纠正，因此，如果在适当的延迟后重复操作，则操作可能会成功。
关键设计策略
任何环境、任何平台或操作系统以及任何类型的应用程序都会发生暂时性故障。
挑战
暂时性故障可能会对应用程序的感知可用性产生重大影响，即使它在所有可预见的情况下都经过了全面测试。 为了确保 Power Platform 工作负载能够可靠地运行，需要确保能够应对以下挑战：
应用程序必须能够检测到故障的发生，并确定这些故障可能是暂时性的、持久性的还是终端故障。 发生故障时，不同的资源可能返回不同的响应，这些响应可能会根据操作上下文而有所不同。 例如，应用程序从自定义连接器检索数据时的错误响应可能与应用程序运行云端流并等待响应时的响应不同。
如果确定故障可能是暂时性的，应用程序必须能够重试操作。
应用程序必须使用适当的重试策略。 此策略指定应用程序应该重试的次数、每次尝试之间的延迟时间，以及尝试失败后执行的操作。 适当的尝试次数以及每次尝试之间的延迟时间通常难以确定。 策略因资源类型以及资源和应用程序的当前操作条件而异。
一般准则
以下准则有助于为应用程序设计合适的暂时性故障处理机制。
确定是否存在内置的重试机制
您正在连接的一些服务可能已经提供暂时性故障处理机制。 服务使用的重试策略通常是根据目标服务的性质和要求定制的。 或者，对于确定重试是否适当，以及在下一次尝试重试之前要等待多长时间方面，服务的 REST 接口可能会返回有用的信息。
除非有具体且明确的要求需要其他更适当的重试行为，否则应适时使用提供的内置重试机制。
确定操作是否适合重试
只在故障是暂时性（通常可由故障的性质来判断），以及在重试时操作至少有一定成功的可能性时，才执行重试操作。 如果操作是无效的操作，比如更新 Microsoft Dataverse 中不存在或用户无权更新的行，或者调用不存在的 API 端点，则重试操作没有意义。
只有在能够确定重试的全部影响，且充分了解状况并可验证这些状况时，才实施重试。 请记住，从无法控制的资源与服务返回的错误可能会随着时间而演进，可能需要重新访问暂时性故障检测逻辑。
您开发从应用程序调用的单个组件或服务时，请确保返回错误代码和消息，以帮助客户端确定是否应该重试失败的操作。 考虑指明客户端是否应重试操作；例如，通过返回 isTransient 值。 如果要构建 Web 服务，请考虑返回服务合约中定义的自定义错误。
确定适当的重试计数与间隔
优化用例类型的重试计数和间隔。 如果未重试足够的次数，应用程序可能无法完成该操作，并且可能会失败。 如果重试次数过多或间隔太短，应用程序可能会长期保留资源，这会对应用程序的运行状况造成不利影响。
根据操作类型调整时间间隔与重试次数值。 例如，如果操作是用户交互的一部分，则间隔应该较短，且只需重试几次。 使用此方法可以避免让用户等待响应。 如果操作是长时间运行或重要工作流的一部分，取消并重新启动过程代价高昂或耗时，则每次尝试后等待的时间应较长，并且应重试更多次。
请注意，确定适当的重试间隔是设计一个成功的策略时最困难的部分。 典型的策略会使用以下类型的重试间隔：
指数区间。 应用程序在第一次重试之前短暂地等待，然后每个后续重试的间隔时间会呈指数增加。 例如，在 3 秒、12 秒、30 秒后重试操作。
固定间隔。 应用程序每次尝试的间隔时间相同。
立即重试。 有时候暂时性故障很短暂，适合立即重试操作，因为如果故障在操作让应用程序组合并发送下一个请求时已清除，则操作可能会成功。 不过，立即重试次数不得超过一次。 如果立即重试失败，应改用备用策略，例如指数间隔或回退操作。
一般指导原则是，为后台操作使用指数间隔策略，为交互式操作使用立即或固定间隔重试策略。 在上述两种情况下，应该选择延迟与重试计数，使所有重试的延迟上限都在所需的端到端延迟要求范围内。
请考虑到所有会对重试操作的整体超时上限造成影响的因素组合。 这些因素包括失败连接生成响应所花费的时间，以及重试之间的延迟和重试次数上限。 所有这些时间的总和会导致整体操作时间变得漫长，尤其是在使用指数退让策略时，因为每次故障后重试的间隔时间会快速增加。 如果进程必须满足特定的服务级别协议 (SLA)，则总体操作时间（包括所有超时和延迟）必须在 SLA 中定义的限制范围内。
不要实施过于激进的重试策略。 这些策略的间隔过短或重试过于频繁， 可能会对目标资源或服务产生不利影响。 这些策略可能会造成资源或服务无法从过载状态恢复，并且会继续阻止或拒绝请求。 这种情况会导致恶性循环，越来越多的请求将发送到资源或服务。 因此造成其恢复能力进一步降低。
选择重试间隔时请考虑操作的超时，以避免立即启动后续尝试（例如当超时期限与重试间隔类似时）。
使用错误类型或服务返回的错误代码和消息，来优化重试次数及其间隔。 例如，某些异常或错误代码（如 HTTP 代码 503 - 服务不可用，以及响应中的 Retry-After 标头）会指示错误可能持续的时间，或服务失败且不会响应任何后续尝试。
避免反模式
在大多数情况下，避免使用包含重复重试代码层的实现。 避免使用包括级联重试机制的设计，或避免使用在涉及请求层次结构的操作的每个阶段实施重试的设计，除非有特定的要求需要这样做。 在这些例外的情况下，请使用策略避免过多的重试次数和延迟期间过长，并确保了解后果。 例如，假设某个组件对另一个组件发出请求，后者再访问目标服务。 如果要对这两个调用各实施重试三次，则总共会对该服务重试九次。 许多服务和资源实施内置重试机制。 如果需要在更高级别实施重试，应研究如何禁用或修改这些机制。
切勿实施永不结束的重试机制。 这样做可能会导致资源或服务无法从过载情况下恢复，并造成限制与遭到拒绝的连接持续更长时间。
切勿多次执行立即重试。
在访问 Azure 中的服务与资源时，避免使用固定重试间隔，尤其是要重试很多次时。 在这种情况下，最好的方法是指数区间策略。
测试重试策略与实现
在尽可能广泛的条件下全面测试重试策略，尤其是当使用的应用程序与目标资源或服务要承受极端负载时。 要检查测试期间的行为，可以：
将暂时性与非暂时性故障注入服务中。 例如，发送无效请求或添加代码用于检测包含不同错误类型的测试请求与响应。
创建资源或服务模型，用于返回真实服务可能返回的错误范围。 覆盖重试策略旨在检测的所有错误类型。
对于创建和部署的自定义服务，通过暂时禁用或重载该服务来强制发生暂时性错误。 （不应尝试使 Azure 中的任何共享资源或共享服务重载。）
执行高负载因子和并发测试，确保重试机制与策略在这些条件下能正常工作。 这些测试还有助于确保重试不会对客户端的操作产生不利影响，也不会在请求之间造成交叉污染。
管理重试策略配置
重试策略是重试策略所有元素的组合。 它定义了能确定故障是否可能是暂时性的检测机制、使用的间隔类型（例如固定或指数）、实际间隔值，以及重试次数。
利用内置或默认的重试策略，但前提是这些策略适合方案。 这些策略通常是通用的。 在某些状况下，这些策略可能都是必需的，但在其他状况下，它们可能无法提供完整的选项范围来满足特定的要求。 要确定最合适的值，需要执行测试来了解设置如何影响应用程序。
记录和跟踪暂时性与非暂时性故障
在重试策略中包含异常处理，以及其他用于记录重试尝试的检测。 偶尔会出现暂时性故障和重试，这并不表示存在问题。 但是，固定递增的重试次数通常表示出现了可能会造成故障或降低应用程序性能与可用性的问题。
将暂时性故障记录为警告项，而不是错误项，以便监视系统不会将其检测为应用程序错误而触发误报。
考虑将值存储在日志项中，用于指示重试是由服务中的限制所造成，还是由其他类型的故障（例如连接失败）造成，使你能够在分析数据期间进行区分。 限制错误数目的增加通常表示应用程序的设计有瑕疵，或者需要向环境中添加高级容量。
考虑实施遥测和监视系统，当故障次数与比率、重试平均次数或操作成功所需的整体时间增加时，该系统会引发警报。
管理不断失败的操作
请考虑如何处理在每次尝试时继续失败的操作。 这种情况是不可避免的。
尽管重试策略会定义操作应重试次数的上限，但它不会防止应用程序使用与重试次数相同的次数一再重复操作。 例如，在应用程序中提交表单可能会触发一个流。 重试策略可能会检测到连接超时，并将其视为暂时性故障。 该流将重试该操作指定的次数，然后放弃。 但是，当同一用户或新用户再次尝试提交表单时，将再次尝试该操作，即使该操作每次都会失败。
应用程序将定期测试服务，并间歇性地（请求之间的间隔非常长）检测服务何时可供使用。 适当的间隔取决于操作的重要性和服务的性质等因素。 它可能是几分钟到几小时之间之间的任何时间。 测试成功时，应用程序将恢复正常操作，并将请求传递给刚刚恢复的服务。
与此同时，可执行某些替代操作，以期该服务很快可供使用。 例如，有时适合将服务的请求存储在队列或数据存储中，供以后重试。 或者将消息返回给用户，指出应用程序当前不可用。
其他注意事项
确定重试次数的值和策略的重试间隔时，请考虑服务或资源的操作是否是长时间运行或多步骤操作的一部分。 当某个操作步骤失败时，补偿其他所有操作步骤可能会很困难或代价非凡。 在此情况下，可以接受很长的间隔及大量的重试次数，前提是该策略不会因为保留或锁定稀缺资源而阻止其他操作。
考虑重试相同的操作是否会导致数据不一致。 如果多步骤过程中的某些部分是重复的，并且操作不是幂等的，则可能会出现不一致情况。 例如，如果重复将记录插入 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 应用的业务连续性和灾难恢复
可靠性清单
请参考整套建议。