若要处理部分故障，请使用此处所述的策略之一。
跨内部微服务使用异步通信（例如基于消息的通信）。 强烈建议不要跨内部微服务创建长时间的同步 HTTP 调用链，因为这种不正确的设计最终将成为中断错误的主要原因。 相反，除了客户端应用程序与第一级别的微服务或精细 API 网关之间的前端通信外，建议在经过初始请求/响应周期后，在内部微服务之间仅使用异步（基于消息）的通信。 最终一致性和事件驱动的体系结构将有助于最大程度地减少连锁反应。 这些方法强制实施更高级别的微服务自治，从而防止出现此处指出的问题。
采用使用指数回退算法的重试。 这种技术有助于通过执行特定次数的调用重试避免短时间的间歇性故障，以防仅短时间内服务不可用。 这可能是由于间歇性网络问题，或者当微服务/容器移动到群集中的其他节点时。 但是，如果这些重试未利用断路器正确设计，可能会加剧连锁反应，最终甚至导致拒绝服务（DoS）。
暂时避开网络超时。 通常，客户端应设计为不无限期地阻塞，并且始终在等待响应时使用超时机制。 使用超时可确保永远不会无限期地占用资源。
使用断路器模式。 在此方法中，客户端进程跟踪失败的请求数。 如果错误率超过配置的限制，则触发“熔断机制”，从而使后续尝试立即失败。 （如果大量请求失败，则表明服务不可用，并且发送请求毫无意义。超时期限过后，客户端应重试，如果新请求成功，请关闭断路器。
提供备用方案。 在此方法中，客户端进程在请求失败时执行回退逻辑，例如返回缓存的数据或默认值。 这是一种适用于查询的方法，对于更新或命令而言更为复杂。
限制排队的请求数。 客户端还应对客户端微服务可以发送到特定服务的未完成请求数施加上限。 如果已达到限制，则发出其他请求可能毫无意义，并且这些尝试应立即失败。 对于实现，Polly Bulkhead 隔离策略可以用于满足此要求。 此方法实质上是以 SemaphoreSlim 为实现的并行化节流。 它还允许在隔板外排队。 即使在执行之前，也可以主动放弃多余的负载（例如，因为容量被视为已满）。 这使得在某些故障场景下，它的响应速度比断路器更快，因为断路器需等到故障发生才能采取行动。 Polly 中的 BulkheadPolicy 对象公开 bulkhead 和队列的已满程度，且提供有关溢出的事件，因此也可用于驱动自动水平缩放。
其他资源
复原模式
https://learn.microsoft.com/azure/architecture/framework/resiliency/reliability-patterns添加复原能力和优化性能
https://learn.microsoft.com/previous-versions/msp-n-p/jj591574(v=pandp.10)Bulkhead。 GitHub 存储库。 使用 Polly 策略的实现。
https://github.com/App-vNext/Polly/wiki/Bulkhead设计适用于 Azure 的弹性应用程序
https://learn.microsoft.com/azure/architecture/framework/resiliency/app-design暂时性故障处理
https://learn.microsoft.com/azure/architecture/best-practices/transient-faults
