Устойчивость компонентов Dapr (предварительная версия)
Политики устойчивости упреждающе предотвращают, обнаруживают и восстанавливаются после сбоев приложения контейнера. В этой статье вы узнаете, как применять политики устойчивости для приложений, использующих Dapr для интеграции с различными облачными службами, такими как хранилища состояний, брокеры сообщений паба и вложенных сообщений, секретные хранилища и многое другое.
Политики устойчивости, такие как повторные попытки, тайм-ауты и выключатели цепи для следующих направлений исходящих и входящих операций, можно настроить с помощью компонента Dapr:
- Исходящие операции: вызовы от бокового автомобиля Dapr к компоненту, например:
- Сохранение или извлечение состояния
- Публикация сообщения
- Вызов выходной привязки
- Входящие операции: вызовы из бокового контейнера Dapr в приложение контейнера, например:
- Подписки при доставке сообщения
- Входные привязки, предоставляющие событие
На следующем снимку экрана показано, как приложение использует политику повторных попыток для восстановления после неудачных запросов.
Поддерживаемые политики устойчивости
Настройка политик устойчивости
Вы можете выбрать, следует ли создавать политики устойчивости с помощью Bicep, интерфейса командной строки или портал 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 |
No | Циклический период времени (в секундах), используемый выключателем для очистки внутренних счетчиков. Если это не указано, интервал задается таким же значением, как указано для 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, встроенных в обнаружение служб