Переписать http-запрос на основе заголовка местоположения ответа - Istio - PullRequest
Новая
       53

Переписать http-запрос на основе заголовка местоположения ответа - Istio

0 голосов
/ 02 марта 2019

Описание:

Сделать запрос к прокси Istio (1.0.6) для апстрима через virtual_service.Служба отвечает с заголовком newuri , с кодом httpStatus , т. Е. 307 - я знаю, что перенаправление должно работать по умолчанию с 302 и заголовком местоположения.Но я хочу сделать обработку перенаправления на основе ошибки http.Я попытался использовать envoyFilters с lua, но все функции связаны с обработкой потока (мод заголовков запрос / ответ), а не переписывают или пересылают запрос.

Таким образом, путь запроса выглядит следующим образом:

  • клиент делает запрос, т.е. curl http://foo/path
  • прокси пересылает запрос в восходящий поток
  • апстрим отвечает пользовательским заголовком с new_uri, т.е. http://blabla/path2 в качестве значения
  • , в то время как заголовок существует в ответном прокси-сервере и выполняет новый запрос к new_uri
  • клиенту см. ответ от new_uri

Спасибо

1 Ответ

0 голосов
/ 21 марта 2019

В случае, если у вас есть предопределенный список вышестоящих хостов, вы можете посмотреть на Envoy Retry plugin .Этот механизм позволяет определить список предикатов Hosts , которые могут быть связаны с некоторым конкретным условием повторения retry_on: то есть с конкретным кодом ошибки HTTP;и число серий повторных попыток num_retries, таким образом, после того, как количество повторных попыток достигнет числа повторных попыток, политика повторных попыток Envoy выберет следующий хост из списка, определенного в retry_host_predicate. 

{
  "retry_on": "...",
  "num_retries": "{...}",
  "per_try_timeout": "{...}",
  "retry_priority": "{...}",
  "retry_host_predicate": [],
  "host_selection_retry_max_attempts": "...",
  "retriable_status_codes": []
}

В другом случае, когда ваше перенаправлениехосты заранее не известны, было бы лучше найти способ применения соответствующей логики на уровне приложений, поскольку большинство прокси-серверов HTTP спроектированы таким образом, что обработчики ответов выполняются синхронно, то есть когда обработчик ответов не выполняет ничего другогобудет запланировано в той же теме.Это нормально, если обработчик ответов обрабатывает только данные, уже находящиеся в памяти, и не ожидает удаленных служб.Однако если вы сделаете сетевой запрос от обработчика ответа, весь поток будет заблокирован и абсолютно ничего не будет делать до тех пор, пока удаленная служба не ответит, что приведет к снижению производительности.

...