通过弹性策略实现错误恢复 on Dapr 文档库

概述

Mon, 01 Jan 0001 00:00:00 +0000

Dapr 提供了一种通过弹性规范来定义和应用容错策略的功能。弹性规范与组件规范存放在同一位置，并在 Dapr sidecar 启动时生效。sidecar 决定如何将这些策略应用于您的 Dapr API 调用。在自托管模式下，弹性规范文件必须命名为 resiliency.yaml。在 Kubernetes 中，Dapr 会找到您的应用程序使用的命名弹性规范。在弹性规范中，您可以定义常见的弹性模式策略，例如：

这些策略可以应用于目标，包括：

通过服务调用的应用程序
组件
actor

此外，弹性策略还可以限定到特定应用程序。

演示视频

了解更多关于如何使用 Dapr 编写弹性微服务。

弹性策略结构

以下是弹性策略的一般结构：

apiVersion: dapr.io/v1alpha1
kind: Resiliency
metadata:
 name: myresiliency
scopes:
 # 可选地将策略限定到特定应用程序
spec:
 policies:
 timeouts:
 # 超时策略定义

 retries:
 # 重试策略定义

 circuitBreakers:
 # 断路器策略定义

 targets:
 apps:
 # 应用程序及其应用的策略

 actors:
 # actor 类型及其应用的策略

 components:
 # 组件及其应用的策略

完整示例策略

apiVersion: dapr.io/v1alpha1
kind: Resiliency
metadata:
 name: myresiliency
# 类似于订阅和配置规范，scopes 列出了可以使用此弹性规范的 Dapr 应用程序 ID。
scopes:
 - app1
 - app2
spec:
 # policies 是定义超时、重试和断路器策略的地方。
 # 每个策略都有一个名称，以便可以在弹性规范的 targets 部分引用。
 policies:
 # 超时是简单的命名持续时间。
 timeouts:
 general: 5s
 important: 60s
 largeResponse: 10s

 # 重试是重试配置的命名模板，并在操作的生命周期内实例化。
 retries:
 pubsubRetry:
 policy: constant
 duration: 5s
 maxRetries: 10

 retryForever:
 policy: exponential
 maxInterval: 15s
 maxRetries: -1 # 无限重试

 important:
 policy: constant
 duration: 5s
 maxRetries: 30

 someOperation:
 policy: exponential
 maxInterval: 15s

 largeResponse:
 policy: constant
 duration: 5s
 maxRetries: 3

 # 断路器会自动为每个组件和应用实例创建。
 # 断路器维护的计数器在 Dapr sidecar 运行期间存在。它们不会被持久化。
 circuitBreakers:
 simpleCB:
 maxRequests: 1
 timeout: 30s 
 trip: consecutiveFailures >= 5

 pubsubCB:
 maxRequests: 1
 interval: 8s
 timeout: 45s
 trip: consecutiveFailures > 8

 # targets 是应用命名策略的对象。Dapr 支持 3 种目标类型 - 应用程序、组件和 actor
 targets:
 apps:
 appB:
 timeout: general
 retry: important
 # 服务的断路器是按应用实例限定的。
 # 当断路器被触发时，该路由将从负载均衡中移除，持续配置的 `timeout` 时间。
 circuitBreaker: simpleCB

 actors:
 myActorType: # 自定义 actor 类型名称
 timeout: general
 retry: important
 # actor 的断路器可以按类型、ID 或两者限定。
 # 当断路器被触发时，该类型或 ID 将从配置表中移除，持续配置的 `timeout` 时间。
 circuitBreaker: simpleCB
 circuitBreakerScope: both ## 
 circuitBreakerCacheSize: 5000

 components:
 # 对于状态存储，策略适用于保存和检索状态。
 statestore1: # 任何组件名称 -- 这里是一个状态存储
 outbound:
 timeout: general
 retry: retryForever
 # 组件的断路器是按组件配置/实例限定的。例如 myRediscomponent。
 # 当此断路器被触发时，所有与该组件的交互将在配置的 `timeout` 时间内被阻止。
 circuitBreaker: simpleCB

 pubsub1: # 任何组件名称 -- 这里是一个 pubsub broker
 outbound:
 retry: pubsubRetry
 circuitBreaker: pubsubCB

 pubsub2: # 任何组件名称 -- 这里是另一个 pubsub broker
 outbound:
 retry: pubsubRetry
 circuitBreaker: pubsubCB
 inbound: # inbound 仅适用于从 sidecar 到应用程序的传递
 timeout: general
 retry: important
 circuitBreaker: pubsubCB

弹性策略

Mon, 01 Jan 0001 00:00:00 +0000

在 policies 下定义超时、重试和断路器策略。每个策略都有一个名称，以便您可以在弹性规范的 targets 部分中引用它们。

注意：Dapr 为某些 API 提供默认的重试机制。请参阅此处了解如何使用用户定义的重试策略覆盖默认重试逻辑。

超时

超时是可选策略，用于提前终止长时间运行的操作。如果超过了超时时间：

正在进行的操作将被终止（如果可能）。
返回错误。

有效值是 Go 的 time.ParseDuration 接受的格式，例如：15s、2m、1h30m。超时没有设置最大值。

示例：

spec:
 policies:
 # 超时是简单的命名持续时间。
 timeouts:
 general: 5s
 important: 60s
 largeResponse: 10s

如果未指定超时值，则策略不会强制执行时间限制，默认使用请求客户端设置的任何值。

重试

通过 retries，您可以为失败的操作定义重试策略，包括由于触发定义的超时或断路器策略而失败的请求。

Pub/sub 组件重试与入站弹性

每个 pub/sub 组件都有其内置的重试行为。显式应用 Dapr 弹性策略不会覆盖这些内置重试机制。相反，重试策略补充了内置重试机制，这可能导致消息的重复聚集。

以下重试选项是可配置的：

重试选项	描述
`policy`	确定退避和重试间隔策略。有效值为 `constant` 和 `exponential`。默认为 `constant`。
`duration`	确定重试之间的时间间隔。仅适用于 `constant` 策略。有效值为 `200ms`、`15s`、`2m` 等格式。默认为 `5s`。
`maxInterval`	确定 `exponential` 退避策略可以增长到的最大间隔。额外的重试总是在 `maxInterval` 的持续时间之后发生。默认为 `60s`。有效值为 `5s`、`1m`、`1m30s` 等格式。
`maxRetries`	尝试的最大重试次数。 `-1` 表示无限次重试，而 `0` 表示请求不会被重试（本质上表现为未设置重试策略）。默认为 `-1`。
`matching.httpStatusCodes`	可选：要重试的 HTTP 状态代码或代码范围的逗号分隔字符串。未列出的状态代码不重试。有效值：100-599，参考格式：`<code>` 或范围 `<start>-<end>` 示例：“429,501-503” 默认：空字符串 `""` 或字段未设置。重试所有 HTTP 错误。
`matching.gRPCStatusCodes`	可选：要重试的 gRPC 状态代码或代码范围的逗号分隔字符串。未列出的状态代码不重试。有效值：0-16，参考格式：`<code>` 或范围 `<start>-<end>` 示例：“1,501-503” 默认：空字符串 `""` 或字段未设置。重试所有 gRPC 错误。

httpStatusCodes 和 gRPCStatusCodes 格式

字段值应遵循字段描述中指定的格式或下面的“示例 2”中的格式。格式不正确的值将产生错误日志（“无法读取弹性策略”），并且 daprd 启动序列将继续。

指数退避窗口使用以下公式：

目标

Mon, 01 Jan 0001 00:00:00 +0000

目标

命名的策略被应用于目标。Dapr支持三种目标类型，这些类型适用于所有Dapr构建块的API：

apps
components
actors

应用程序

使用apps目标，您可以将retry、timeout和circuitBreaker策略应用于Dapr应用程序之间的服务调用。在targets/apps下，策略应用于每个目标服务的app-id。当sidecar之间的通信出现故障时，这些策略将被调用，如下图所示。

Dapr提供了内置的服务调用重试，因此任何应用的retry策略都是额外的。

应用于目标应用程序app-id为"appB"的策略示例：

specs:
 targets:
 apps:
 appB: # 目标服务的app-id
 timeout: general
 retry: general
 circuitBreaker: general

组件

使用components目标，您可以将retry、timeout和circuitBreaker策略应用于组件操作。

策略可以应用于outbound操作（从Dapr sidecar到组件的调用）和/或inbound（从sidecar到您的应用程序的调用）。

出站

outbound操作是从sidecar到组件的调用，例如：

持久化或检索状态。
在pubsub组件上发布消息。
调用输出绑定。

某些组件可能具有内置的重试功能，并且可以在每个组件的基础上进行配置。

spec:
 targets:
 components:
 myStateStore:
 outbound:
 retry: retryForever
 circuitBreaker: simpleCB

入站

inbound操作是从sidecar到您的应用程序的调用，例如：

pubsub订阅在传递消息时。
输入绑定。

某些组件可能具有内置的重试功能，并且可以在每个组件的基础上进行配置。

spec:
 targets:
 components:
 myInputBinding:
 inbound: 
 timeout: general
 retry: general
 circuitBreaker: general

PubSub

在pubsub target/component中，您可以同时指定inbound和outbound操作。

通过弹性策略实现错误恢复 on Dapr 文档库

概述

演示视频

弹性策略结构

完整示例策略

相关链接

弹性策略

超时

重试

Pub/sub 组件重试与入站弹性

httpStatusCodes 和 gRPCStatusCodes 格式

目标

目标

应用程序

组件

出站

入站

PubSub