弹性策略

• 1: 超时弹性策略
• 2: 重试和退避弹性策略
• 2.1: 重试弹性策略
• 2.2: 覆盖默认重试弹性策略
• 3: 断路器弹性策略
• 4: 默认弹性策略

1 - 超时弹性策略

网络调用可能因多种原因失败，导致应用程序无限期等待响应。通过设置超时时长，您可以切断那些无响应的服务，释放资源以处理新请求。

超时是可选策略，可用于提前终止长时间运行的操作。设置一个现实的超时时长，反映生产环境中的实际响应时间。如果超出了超时时长：

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

超时策略格式

spec:
  policies:
    # 超时是指定的时长。
    timeouts:
      timeoutName: timeout1
      general: 5s
      important: 60s
      largeResponse: 10s

规范元数据

| 字段 | 详情 | 示例 | | timeoutName | 超时策略的名称 | timeout1 | | general | 标记为"general"的超时时长。使用 Go 的 time.ParseDuration 格式。没有设置最大值。 | 15s、2m、1h30m | | important | 标记为"important"的超时时长。使用 Go 的 time.ParseDuration 格式。没有设置最大值。 | 15s、2m、1h30m | | largeResponse | 等待大型响应的超时时长。使用 Go 的 time.ParseDuration 格式。没有设置最大值。 | 15s、2m、1h30m |

如果未指定超时值，策略不会强制执行时间，默认为您根据请求客户端设置的值。

后续步骤

• 了解更多关于默认弹性策略
• 了解更多关于：
  • 重试策略
  • 熔断器策略

相关链接

试用其中一个弹性快速入门：

• 弹性：服务间
• 弹性：状态管理

2 - 重试和退避弹性策略

2.1 - 重试弹性策略

请求可能因瞬时错误而失败，例如遇到网络拥塞、重新路由到过载实例等。有时，请求也可能因已设置的其他弹性策略而失败，例如触发了定义的超时或熔断器策略。

在这些情况下，配置 retries 可以：

• 将相同请求发送到不同的实例，或
• 在条件清除后重试发送请求。

重试和超时协同工作，超时确保您的系统在需要时快速失败，而重试从临时故障中恢复。

Dapr 提供默认弹性策略，您可以使用用户定义的重试策略覆盖它们。

重试策略格式

示例 1

spec:
  policies:
    # Retries are named templates for retry configurations and are instantiated for life of the operation.
    retries:
      pubsubRetry:
        policy: constant
        duration: 5s
        maxRetries: 10

      retryForever:
        policy: exponential
        maxInterval: 15s
        maxRetries: -1 # Retry indefinitely

示例 2

spec:
  policies:
    retries:
      retry5xxOnly:
        policy: constant
        duration: 5s
        maxRetries: 3
        matching:
          httpStatusCodes: "429,500-599" # retry the HTTP status codes in this range. All others are not retried. 
          gRPCStatusCodes: "1-4,8-11,13,14" # retry gRPC status codes in these ranges and separate single codes.

规范元数据

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

指数退避策略

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

BackOffDuration = PreviousBackOffDuration * (Random value from 0.5 to 1.5) * 1.5
if BackOffDuration > maxInterval {
  BackoffDuration = maxInterval
}

重试状态码

当应用程序跨越多个服务时，特别是在像 Kubernetes 这样的动态环境中，服务可能因各种原因而消失，网络调用可能会开始挂起。状态码提供了对我们操作的洞察以及它们在生产中可能失败的位置。

HTTP

下表包含您可能收到的一些 HTTP 状态码示例，以及您是否应该或不应该重试某些操作。

gRPC

下表包含您可能收到的一些 gRPC 状态码示例，以及您是否应该或不应该重试某些操作。

基于状态码的重试过滤器

重试过滤器允许通过指定应应用重试的 HTTP 和 gRPC 状态码或范围，对重试策略进行细粒度控制。

spec:
  policies:
    retries:
      retry5xxOnly:
        # ...
        matching:
          httpStatusCodes: "429,500-599" # retry the HTTP status codes in this range. All others are not retried. 
          gRPCStatusCodes: "4,8-11,13,14" # retry gRPC status codes in these ranges and separate single codes.

演示

观看 Diagrid 的 Dapr v1.15 庆祝活动期间演示的演示，了解如何使用 Diagrid Conductor 设置重试状态码过滤器。

后续步骤

• 了解如何为特定 API 覆盖默认重试策略。
• 了解如何从弹性规范中定位您的重试策略。
• 了解更多：
  • 超时策略
  • 熔断器策略

相关链接

尝试其中一个弹性快速入门：

• 弹性：服务到服务
• 弹性：状态管理

2.2 - 覆盖默认重试弹性策略

Dapr 为任何不成功的请求（如故障和临时错误）提供默认重试。在弹性规范中，您可以通过使用保留的命名关键字定义策略来覆盖 Dapr 的默认重试逻辑。例如，定义一个名为 DaprBuiltInServiceRetries 的策略可以覆盖通过服务间请求在边车之间发生故障时的默认重试。策略覆盖不会应用于特定目标。

注意：虽然您可以使用更稳健的重试来覆盖默认值，但不能使用低于提供的默认值的值进行覆盖，也不能完全移除默认重试。这可以防止意外的停机。

下表描述了 Dapr 的默认重试以及用于覆盖它们的策略关键字：

下面的弹性规范示例展示了如何使用保留的命名关键字 ‘DaprBuiltInServiceRetries’ 来覆盖_所有_服务调用请求的默认重试。

同时还定义了一个名为 ‘retryForever’ 的重试策略，该策略仅应用于 appB 目标。appB 使用 ‘retryForever’ 重试策略，而所有其他应用程序服务调用重试故障则使用被覆盖的 ‘DaprBuiltInServiceRetries’ 默认策略。

spec:
  policies:
    retries:
      DaprBuiltInServiceRetries: # 覆盖服务间调用的默认重试行为
        policy: constant
        duration: 5s
        maxRetries: 10

      retryForever: # 用户定义的重试策略会替换默认重试。目标仅依赖于应用的策略。 
        policy: exponential
        maxInterval: 15s
        maxRetries: -1 # 无限期重试

  targets:
    apps:
      appB: # 目标服务的 app-id
        retry: retryForever

相关链接

尝试其中一个弹性快速入门：

• 弹性：服务间
• 弹性：状态管理

3 - 断路器弹性策略

当其他应用程序/服务/组件出现较高的故障率时，会使用断路器策略。断路器通过监控请求并在满足特定条件时切断到受影响服务的所有流量来减少负载。

在一定数量的请求失败后，断路器会"跳闸"或打开以防止级联故障。通过这样做，断路器为服务提供从故障中恢复的时间，而不是用事件淹没它。

断路器还可以进入"半开"状态，允许部分流量通过以查看系统是否已恢复。

一旦请求恢复成功，断路器将进入"关闭"状态，并允许流量完全恢复。

断路器策略格式

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

规格元数据

后续步骤

• 了解默认弹性策略的更多信息
• 了解更多：
  • 重试策略
  • 超时策略

相关链接

尝试以下弹性快速入门之一：

• 弹性：服务到服务
• 弹性：状态管理

4 - 默认弹性策略

在弹性中，您可以设置具有广泛范围的默认策略。这是通过保留关键字完成的，让 Dapr 知道何时应用该策略。有 3 种默认策略类型：

• DefaultRetryPolicy
• DefaultTimeoutPolicy
• DefaultCircuitBreakerPolicy

如果定义了这些策略，它们将用于对服务、应用程序或组件的每个操作。它们还可以通过附加额外关键字来修改以更加具体。具体策略遵循以下模式，Default%sRetryPolicy、Default%sTimeoutPolicy 和 Default%sCircuitBreakerPolicy。其中 %s 被替换为策略的目标。

下表列出了所有可能的默认策略关键字以及它们如何转换为策略名称。

策略层次解析

如果正在执行的操作匹配策略类型，并且没有针对它的更具体的策略，则会应用默认策略。对于每个目标类型（app、actor 和 component），优先级最高的策略是命名策略，即专门针对该构造的策略。

如果不存在，则策略从最具体到最广泛应用。

默认策略与内置重试如何协同工作

在内置重试的情况下，默认策略不会阻止内置重试策略运行。两者一起使用，但仅在特定情况下。

对于服务和 Actor 调用，内置重试专门处理连接到远程边车时的问题（在需要时）。由于这些对 Dapr 运行时的稳定性很重要，因此它们不会被禁用，除非为操作专门引用了命名策略。在某些情况下，可能会同时从内置重试和默认重试策略进行额外重试，但这可以防止过于薄弱的默认策略降低边车的可用性/成功率。

应用程序的策略解析层次，从最具体到最广泛：

1. App 目标中的命名策略
2. 默认 App 策略 / 内置服务重试
3. 默认策略 / 内置服务重试

Actor 的策略解析层次，从最具体到最广泛：

1. Actor 目标中的命名策略
2. 默认 Actor 策略 / 内置 Actor 重试
3. 默认策略 / 内置 Actor 重试

组件的策略解析层次，从最具体到最广泛：

1. 组件目标中的命名策略
2. 默认组件类型 + 组件方向策略 / 内置 Actor 提醒重试（如果适用）
3. 默认组件方向策略 / 内置 Actor 提醒重试（如果适用）
4. 默认组件策略 / 内置 Actor 提醒重试（如果适用）
5. 默认策略 / 内置 Actor 提醒重试（如果适用）

作为一个示例，考虑以下解决方案，其中包含三个应用程序、三个组件和两个 Actor 类型：

应用程序：

• AppA
• AppB
• AppC

组件：

• Redis Pubsub：pubsub
• Redis statestore：statestore
• CosmosDB Statestore：actorstore

Actor：

• EventActor
• SummaryActor

以下是使用默认和命名策略并将其应用于目标的策略。

spec:
  policies:
    retries:
      # 全局重试策略
      DefaultRetryPolicy:
        policy: constant
        duration: 1s
        maxRetries: 3
      
      # 应用程序的全局重试策略
      DefaultAppRetryPolicy:
        policy: constant
        duration: 100ms
        maxRetries: 5

      # 应用程序的全局重试策略
      DefaultActorRetryPolicy:
        policy: exponential
        maxInterval: 15s
        maxRetries: 10

      # 入站组件操作的全局重试策略
      DefaultComponentInboundRetryPolicy:
        policy: constant
        duration: 5s
        maxRetries: 5

      # 状态存储的全局重试策略
      DefaultStatestoreComponentOutboundRetryPolicy:
        policy: exponential
        maxInterval: 60s
        maxRetries: -1

     # 命名策略
      fastRetries:
        policy: constant
        duration: 10ms
        maxRetries: 3

     # 命名策略
      retryForever:
        policy: exponential
        maxInterval: 10s
        maxRetries: -1

  targets:
    apps:
      appA:
        retry: fastRetries

      appB:
        retry: retryForever
    
    actors:
      EventActor:
        retry: retryForever

    components:
      actorstore:
        retry: fastRetries

下表详细分解了在尝试调用此解决方案中的各种目标时应用哪些策略。

后续步骤

了解如何覆盖默认重试策略。

相关链接

尝试其中一个弹性快速入门：

• 弹性：服务对服务
• 弹性：状态管理