Политика повторной попытки, чтобы не запускать запросы POST
Можно ли настроить политику устойчивости в Dapr так, чтобы она не выполняла повторную попытку, когда HTTP-запрос является POST? Например, библиотека Polly в .NET позволяет детально настраивать политики повторных попыток и прерывания цепи. Можно ли сделать то же самое в Дапре?
apiVersion: dapr.io/v1alpha1
kind: Resiliency
metadata:
name: resiliency-policy
scopes:
- shoppingbasket
spec:
policies:
retries:
operation:
policy: constant
duration: 5s
maxRetries: 3
circuitBreakers:
serviceCB:
maxRequests: 1
timeout: 30s
trip: consecutiveFailures >= 3
targets:
apps:
discount:
retry: operation
circuitBreaker: serviceCB
Ответы 1
Dapr написан на Golang, поэтому внутри него не используется Polly.
У него немного другая концепция триггера:
- В Polly вы можете определить, когда политика/стратегия повтора должна обрабатывать результат данной операции.
- В Dapr повторная попытка может запускаться всякий раз, когда данная операция возвращает ненормальное состояние. Здесь вы можете найти несколько примеров.
В одном из выпусков github они называют следующее:
Вы правы, он повторяет попытку при любой ошибке, включая ответы 4xx. Для первоначальной версии устойчивости мы использовали подход: больше попыток лучше, чем отсутствие повторов. В будущем мы можем добавить дополнительные фильтры/сценарии, по которым вы сможете запускать повторную попытку. Я знаю, что планировалось добавить больше выражений уровня CEL для второго этапа устойчивости.
В PR предложения вы можете увидеть упоминание об условных повторах:
apis:
invoke:
- match: appId == "appB"
# Nested rules: Prevent duplicative checks in rules.
# Its likely that controler-gen does not support this
# but apiextensionsv1.JSON can be used as workaround.
rules:
- match:
request.method == "GET" &&
request.metadata.count > 1000
timeout: largeResponse
retry: largeResponse
- match:
request.path == "/someOperation"
retry: someOperation
К сожалению, насколько мне известно, Фаза 2 еще не состоялась. Есть один соответствующий открытый пиар: https://github.com/dapr/dapr/pull/7132.
@Sohlae 408 (время ожидания запроса), 429 (слишком много запросов) и 5xx считаются временными Http-кодами.
Питер Чала, так что, по сути, фаза 1 политик повторных попыток и CB применяется только к временным кодам HTTP, правильно ли мое предположение?
@Sohlae Есть вопрос: Какие ошибки в Dapr являются повторяемыми или постоянными? раздел в выпуске github. Несмотря на то, что в нем упоминается несколько кодов состояния, но не указывается явно, какой из них считается повторным, а какой нет. Так что я не совсем уверен, что ваше предположение верно.
Хорошо, спасибо.
Спасибо, Петр, за ответ, а что считается ненормальным состоянием? Это какой-нибудь код состояния >= 400? Это временная неисправность? Или, возможно, оба?