通过

服务发现复原能力（预览版）

  • 项目

借助 Azure 容器应用复原能力，可以使用简单的复原策略主动防止、检测和恢复服务请求失败。 本文介绍如何在使用 Azure 容器应用服务发现启动请求时配置 Azure 容器应用复原策略。

注意

目前，复原策略不能应用于使用 Dapr 服务调用 API 发出的请求。

策略对容器应用的每个请求都有效。 可以针对接受请求的容器应用定制策略，配置如下：

  • 重试次数
  • 重试和超时持续时间
  • 重试匹配项
  • 断路器连续错误等

以下屏幕截图显示了应用程序如何使用重试策略尝试从失败的请求中恢复。

示意图使用容器应用的服务名称演示了容器应用到容器应用复原。

支持的复原策略

配置复原策略

无论是使用 Bicep、CLI 还是 Azure 门户配置复原策略，每个容器应用只能应用一个策略。

将策略应用到一个容器应用时，这些规则会应用到对该容器应用发出的所有请求，而不是从该容器应用发出的请求。 例如，重试策略应用于名为 App B 的容器应用。 对应用 B 发出的所有入站请求都会在失败时自动重试。 但是，无法保证应用 B 发送的出站请求在失败时重试。

以下复原示例演示了所有可用的配置。

resource myPolicyDoc 'Microsoft.App/containerApps/resiliencyPolicies@2023-11-02-preview' = {
  name: 'my-app-resiliency-policies'
  parent: '${appName}'
  properties: {
    timeoutPolicy: {
        responseTimeoutInSeconds: 15
        connectionTimeoutInSeconds: 5
    }
    httpRetryPolicy: {
        maxRetries: 5
        retryBackOff: {
          initialDelayInMilliseconds: 1000
          maxIntervalInMilliseconds: 10000
        }
        matches: {
            headers: [
                {
                    header: 'x-ms-retriable'
                    match: { 
                        exactMatch: 'true'
                    }
                }
            ]
            httpStatusCodes: [
                502
                503
            ]
            errors: [
                'retriable-status-codes'
                '5xx'
                'reset'
                'connect-failure'
                'retriable-4xx'
            ]
        }
    } 
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
    circuitBreakerPolicy: {
        consecutiveErrors: 5
        intervalInSeconds: 10
        maxEjectionPercent: 50
    }
    tcpConnectionPool: {
        maxConnections: 100
    }
    httpConnectionPool: {
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
    }
  }
}

策略规范

超时

超时用于提前终止长时间运行的操作。 超时策略包括以下属性。

properties: {
  timeoutPolicy: {
      responseTimeoutInSeconds: 15
      connectionTimeoutInSeconds: 5
  }
}
元数据 必须 说明 示例
responseTimeoutInSeconds 是 等待来自容器应用的响应超时。 15
connectionTimeoutInSeconds 是 与容器应用建立连接超时。 5

重试

为失败的操作定义 tcpRetryPolicy 或 httpRetryPolicy 策略。 重试策略包括以下配置。

httpRetryPolicy

properties: {
    httpRetryPolicy: {
        maxRetries: 5
        retryBackOff: {
          initialDelayInMilliseconds: 1000
          maxIntervalInMilliseconds: 10000
        }
        matches: {
            headers: [
                {
                    header: 'x-ms-retriable'
                    match: { 
                       exactMatch: 'true'
                    }
                }
            ]
            httpStatusCodes: [
                502
                503
            ]
            errors: [
                'retriable-headers'
                'retriable-status-codes'
            ]
        }
    } 
}
元数据 必须 说明 示例
maxRetries 是 针对失败的 http 请求执行的最大重试次数。 5
retryBackOff 是 监视请求，并在满足超时和重试条件后关闭受影响服务的所有流量。 不可用
retryBackOff.initialDelayInMilliseconds 是 第一个错误与第一次重试之间的延迟。 1000
retryBackOff.maxIntervalInMilliseconds 是 重试之间的最大延迟。 10000
matches 是 设置匹配值以限制应用应何时尝试重试。 headers, httpStatusCodes, errors
matches.headers 是* 错误响应包含特定标头时重试。 *仅当指定 retriable-headers 错误属性时，标头才是必需的属性。 详细了解可用标头匹配。 X-Content-Type
matches.httpStatusCodes 是* 当响应返回特定状态代码时重试。 *仅当指定 retriable-status-codes 错误属性时，状态代码才是必需的属性。 502, 503
matches.errors 是 仅当应用返回特定错误时重试。 详细了解可用错误。 connect-failure, reset
标头匹配

如果指定了 retriable-headers 错误，则可以使用以下标头匹配属性在响应包含特定标头时重试。

matches: {
  headers: [
    { 
      header: 'x-ms-retriable'
      match: {
        exactMatch: 'true'
      }
    }
  ]
}
元数据 说明
prefixMatch 基于标头值的前缀执行重试。
exactMatch 基于标头值的完全匹配执行重试。
suffixMatch 基于标头值的后缀执行重试。
regexMatch 基于正则表达式规则执行重试，其中标头值必须与正则表达式模式匹配。
错误

可以针对以下任何错误执行重试：

matches: {
  errors: [
    'retriable-headers'
    'retriable-status-codes'
    '5xx'
    'reset'
    'connect-failure'
    'retriable-4xx'
  ]
}
元数据 说明
retriable-headers 触发重试的 HTTP 响应头。 如果任何标头匹配项与响应标头匹配，则执行重试。 如果要在任何匹配的标头上重试，则需要执行重试。
retriable-status-codes 应触发重试的 HTTP 状态代码。 如果要在任何匹配的状态代码上重试，则需要执行重试。
5xx 如果服务器使用任何 5xx 响应代码进行响应，请重试。
reset 如果服务器未响应，请重试。
connect-failure 如果请求因与容器应用连接错误而失败，请重试。
retriable-4xx 如果容器应用使用 400 系列响应代码（如 409）进行响应，请重试。

tcpRetryPolicy

properties: {
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
}
元数据 必须 说明 示例
maxConnectAttempts 是 设置连接失败时的最大重试次数 (maxConnectionAttempts)。 3

断路器

断路器策略根据触发器（如连续错误数）指定是否暂时从负载均衡池中删除容器应用副本。

properties: {
    circuitBreakerPolicy: {
        consecutiveErrors: 5
        intervalInSeconds: 10
        maxEjectionPercent: 50
    }
}
元数据 必须 说明 示例
consecutiveErrors 是 容器应用副本暂时从负载均衡中删除之前的连续错误数。 5
intervalInSeconds 是 用于确定副本是否从负载均衡池中删除或还原的给定时间量。 10
maxEjectionPercent 是 从负载均衡中弹出的容器应用副本的最大失败百分比。 删除至少一个主机，而不考虑值。 50

连接池

Azure 容器应用的连接池维护已建立和可重用的容器应用连接池。 此连接池可减少为每个请求创建和断开单个连接的开销。

使用连接池可以指定服务允许的最大请求数或连接数。 这些限制控制每个服务的并发连接总数。 达到此限制后，在释放或关闭现有连接之前，不会与该服务建立新连接。 管理连接的过程可防止出现过多的资源请求，并维护高效的连接管理。

httpConnectionPool

properties: {
    httpConnectionPool: {
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
    }
}
元数据 必须 说明 示例
http1MaxPendingRequests 是 用于 http1 请求。 与容器应用建立的最大开放连接数。 1024
http2MaxRequests 是 用于 http2 请求。 对容器应用的最大并发请求数。 1024

tcpConnectionPool

properties: {
    tcpConnectionPool: {
        maxConnections: 100
    }
}
元数据 必须 说明 示例
maxConnections 是 与容器应用建立的最大并发连接数。 100

复原可观测性

可以通过容器应用的指标和系统日志执行复原可观测性。

复原日志

在容器应用的“监视”部分中，选择“日志”。

屏幕截图展示了在何处找到容器应用的日志。

在“日志”窗格中，编写并运行查询，以通过容器应用系统日志查找复原。 例如，运行类似于以下内容的查询以搜索复原事件并显示：

  • 时间戳
  • 环境名称
  • 容器应用名称
  • 复原类型和原因
  • 日志消息
ContainerAppSystemLogs_CL
| where EventSource_s == "Resiliency"
| project TimeStamp_s, EnvironmentName_s, ContainerAppName_s, Type_s, EventSource_s, Reason_s, Log_s

单击“运行”以运行查询并查看结果。

屏幕截图显示了基于提供的查询示例的复原查询结果。

复原指标

在容器应用的“监视”菜单中，选择“指标”。 在“指标”窗格中，选择以下筛选器：

  • 容器应用名称的范围。
  • “标准指标”指标命名空间。
  • 下拉菜单中的复原指标。
  • 你希望在结果中聚合数据的方式（按平均值、最大值等）。
  • 持续时间（过去 30 分钟、过去 24 小时等）。

屏幕截图展示了如何访问容器应用的复原指标筛选器。

例如，如果在“测试应用”范围中设置“复原请求重试”指标，并使用“平均”聚合在 30 分钟时间内进行搜索，结果将如下所示：

屏幕截图显示了将示例指标筛选器应用于复原所得到的结果。