Устойчивость компонентов Dapr (предварительная версия)

Политики устойчивости упреждающе предотвращают, обнаруживают и восстанавливаются после сбоев контейнерного приложения. В этой статье вы узнаете, как применять политики устойчивости для приложений, использующих Dapr для интеграции с различными облачными службами, такими как хранилища состояний, брокеры сообщений pub/sub, хранилища секретов и многое другое.

Политики устойчивости, такие как повторы, тайм-ауты и выключатели цепи для следующих направлений операций исходящего и входящего трафика, можно настроить с помощью компонента Dapr:

• Исходящие операции: вызовы от сайдкара Dapr к компоненту, например:
  • Сохранение или извлечение состояния
  • Публикация сообщения
  • Вызов выходного связывания
• Входящие операции: вызовы из бокового контейнера Dapr в приложение контейнера, например:
  • Подписки во время доставки сообщения
  • Входные привязки, генерирующие событие

На следующем снимку экрана показано, как приложение использует политику повторных попыток для восстановления после неудачных запросов.

Поддерживаемые политики устойчивости

• Время ожидания
• Повторные попытки (HTTP)
• Автоматические выключатели

Настройка политик устойчивости

Вы можете выбрать, следует ли создавать политики устойчивости с помощью Bicep, Azure CLI или портала Azure.

Bicep

В следующем примере устойчивости показаны все доступные конфигурации.

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     
      }  
    }
  }
}

CLI

Прежде чем начать

Войдите в Azure CLI.

az login

Убедитесь, что у вас установлена последняя версия расширения приложения контейнера Azure.

az extension show --name containerapp
az extension update --name containerapp

Создание определенных политик

Примечание.

Если все свойства в политике не заданы во время создания или обновления, интерфейс командной строки автоматически применяет рекомендуемые параметры по умолчанию. Сведения о настройке определенных политик с помощью флагов см. в статье "Создание определенных политик".

Создайте политики устойчивости, нацелив отдельную политику. Например, чтобы создать Outbound Timeout политику, выполните следующую команду.

az containerapp env dapr-component resiliency create --group <your-resource-group> --name <your-resiliency-name> --environment <your-environment> --dapr-component-name <your-component> --out-timeout 20

Полный список параметров см. в справочном руководстве по CLI.

Создание политик с использованием YAML для повышения устойчивости

Чтобы применить политики устойчивости из ФАЙЛА YAML, выполните следующую команду:

az containerapp env dapr-component resiliency create --group <your-resource-group> --name <your-resiliency-name> --environment <your-environment> --dapr-component-name <your-component> --yaml <your-YAML-file>

Эта команда передает файл YAML политики устойчивости, который может выглядеть примерно так:

outboundPolicy:
  httpRetryPolicy:
    maxRetries: 5
    retryBackOff:
      initialDelayInMilliseconds: 1000
      maxIntervalInMilliseconds: 10000
  timeoutPolicy:
    responseTimeoutInSeconds: 15
  circuitBreakerPolicy:
    intervalInSeconds: 15
    consecutiveErrors: 10
    timeoutInSeconds: 5
inboundPolicy:
  httpRetryPolicy:
    maxRetries: 3
    retryBackOff:
      initialDelayInMilliseconds: 500
      maxIntervalInMilliseconds: 5000
  circuitBreakerPolicy:
    intervalInSeconds: 15
    consecutiveErrors: 10
    timeoutInSeconds: 5

Обновление определенных политик

Обновите политики устойчивости, нацелив отдельную политику. Например, чтобы обновить время ожидания ответа для политики Outbound Timeout, выполните следующую команду.

az containerapp env dapr-component resiliency update --group <your-resource-group> --name <your-resiliency-name> --environment <your-environment> --dapr-component-name <your-component> --out-timeout 20

Обновление политик с использованием YAML для обеспечения устойчивости

Вы также можете обновить существующие политики устойчивости, обновив ранее созданный YAML-файл конфигурации устойчивости.

az containerapp env dapr-component resiliency update --group <your-resource-group> --name <your-resiliency-name> --environment <your-environment> --dapr-component-name <your-component> --yaml <your-YAML-file>

Просмотр политик

resiliency list Используйте команду для перечисления всех политик устойчивости, подключенных к приложению-контейнеру.

az containerapp env dapr-component resiliency list --group <your-resource-group> --environment <your-environment> --dapr-component-name <your-component>

resiliency show Используйте команду для отображения одной политики по имени.

az containerapp env dapr-component resiliency show --group <your-resource-group> --name <your-resiliency-name> --environment <your-environment> --dapr-component-name <your-component>

Удаление политик

Чтобы удалить политики устойчивости, выполните следующую команду.

az containerapp env dapr-component resiliency delete --group <your-resource-group> --name <your-resiliency-name> --environment <your-environment> --dapr-component-name <your-component>

Портал Azure

Перейдите в среду вашего контейнерного приложения в Azure Portal. В меню боковой панели в разделе "Параметры" выберите компоненты Dapr , чтобы открыть панель компонентов Dapr.

Политики устойчивости можно добавить в существующий компонент Dapr, выбрав "Добавить устойчивость " для этого компонента.

В области политики устойчивости выберите исходящий или входящий трафик, чтобы задать политики для исходящих или входящих операций. Например, для исходящих операций можно задать политики времени ожидания и повторных попыток HTTP, как показано ниже.

Нажмите кнопку "Сохранить", чтобы сохранить политики устойчивости.

Примечание.

В настоящее время можно задать только политики времени ожидания и повторных попыток с помощью портал Azure.

Вы можете изменить или удалить политики устойчивости, выбрав "Изменить устойчивость".

Внимание

После применения всех политик устойчивости необходимо перезапустить приложения 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

Выберите "Выполнить" , чтобы запустить запрос и просмотреть полученное сообщение журнала с конфигурацией политики.

Связанный контент

• Устойчивость обнаружения служб (предварительная версия)