Dapr 组件复原能力（预览版）
复原策略会主动阻止、检测和恢复容器应用故障。 在本文中，你会了解如何为使用 Dapr 与不同云服务（例如状态存储、发布/子消息代理、机密存储等）集成的应用程序应用复原策略。
可以通过 Dapr 组件为以下出站和入站操作方向配置复原策略，例如重试、超时和断路器：
- 出站操作：从 Dapr sidecar 到组件的调用，例如：
- 持久保存或检索状态
- 发布消息
- 调用输出绑定
- 入站操作：从 Dapr sidecar 到容器应用的调用，例如：
- 传递消息时的订阅
- 传递事件的输入绑定
以下屏幕截图显示了应用程序如何使用重试策略尝试从失败的请求中恢复。
支持的复原策略
配置复原策略
可以选择是使用 Bicep、CLI 还是 Azure 门户创建复原策略。
以下复原示例演示了所有可用的配置。
resource myPolicyDoc 'Microsoft.App/managedEnvironments/daprComponents/resiliencyPolicies@2023-11-02-preview' = {
name: 'my-component-resiliency-policies'
parent: '${componentName}'
properties: {
outboundPolicy: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
inboundPolicy: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
}
}
重要
应用所有复原策略后，需要重启 Dapr 应用程序。
策略规范
超时
超时用于提前终止长时间运行的操作。 超时策略包括以下属性。
properties: {
outbound: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
}
inbound: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
}
}
| 元数据 | 必须 | 说明 | 示例 |
|---|---|---|---|
responseTimeoutInSeconds |
是 | 等待来自 Dapr 组件的响应的超时。 | 15 |
重试
为失败的操作定义httpRetryPolicy策略。 重试策略包括以下配置。
properties: {
outbound: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
}
inbound: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
}
}
| 元数据 | 必须 | 说明 | 示例 |
|---|---|---|---|
maxRetries |
是 | 针对失败的 http 请求执行的最大重试次数。 | 5 |
retryBackOff |
是 | 监视请求，并在满足超时和重试条件后关闭受影响服务的所有流量。 | 不可用 |
retryBackOff.initialDelayInMilliseconds |
是 | 第一个错误与第一次重试之间的延迟。 | 1000 |
retryBackOff.maxIntervalInMilliseconds |
是 | 重试之间的最大延迟。 | 10000 |
断路器
定义一个 circuitBreakerPolicy 来监视导致故障率增加的请求，并在满足特定条件时关闭流向受影响的服务的所有流量。
properties: {
outbound: {
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
},
inbound: {
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
}
| 元数据 | 必须 | 说明 | 示例 |
|---|---|---|---|
intervalInSeconds |
否 | 断路器清除其内部计数的周期性时间段（以秒为单位）。 如果未提供，则时间间隔设置成与为 timeoutInSeconds 提供的相同值。 |
15 |
consecutiveErrors |
是 | 线路跳闸和开路之前允许发生的请求错误数。 | 10 |
timeoutInSeconds |
是 | 故障后直接出现的开路状态的时间段（以秒为单位）。 | 5 |
断路器进程
如果将 consecutiveErrors（线路跳闸条件）指定为 consecutiveFailures > $(consecutiveErrors)-1，会设置线路中途跳闸和开路之前允许发生的错误数。
线路在中途等待 timeoutInSeconds 的时间，在此期间，consecutiveErrors 个请求必须连续成功。
- 如果请求成功，路线会闭路。
- 如果请求失败，线路仍然处于半开路状态。
如果未设置任何 intervalInSeconds 值，则线路会在你为 timeoutInSeconds 设置的时间后重置为闭路状态，而不管连续请求是成功还是失败。 如果将 intervalInSeconds 设置为 0，则线路永远不会自动重置，仅在连续成功完成 consecutiveErrors 个请求后从半开路状态变为闭路状态。
如果确实设置了 intervalInSeconds 值，它确定在线路重置为闭路状态之前的时间，而不管在半开路状态下发送的请求是否成功。
复原日志
在容器应用的“监视”部分中，选择“日志”。
在“日志”窗格中，编写并运行查询，以通过容器应用系统日志查找复原。 例如，要查找是否已加载复原策略：
ContainerAppConsoleLogs_CL
| where ContainerName_s == "daprd"
| where Log_s contains "Loading Resiliency configuration:"
| project time_t, Category, ContainerAppName_s, Log_s
| order by time_t desc
点击“运行”以运行查询，并使用指示策略正在加载的日志消息查看结果。
或者，可以通过在容器应用上启用调试日志并查询以查看复原资源是否已加载来查找实际的复原策略。
启用调试日志后，请使用类似于下例的查询：
ContainerAppConsoleLogs_CL
| where ContainerName_s == "daprd"
| where Log_s contains "Resiliency configuration ("
| project time_t, Category, ContainerAppName_s, Log_s
| order by time_t desc
点击“运行”以运行查询，并使用策略配置查看生成的日志消息。
相关内容
了解如何使用服务发现中内置的 Azure 容器应用来实现服务到服务通信的复原能力