Zuul тайм-аут в длинных запросах

Я использую приложение облачного приложения spring (микросервис), выступающее в качестве прокси-сервера zuul (@EnableZuulProxy) для маршрутизации запросов от внешнего источника к другим внутренним микросервисам, написанным с использованием spring облака (spring boot).
Сервер zuul прямо из приложений в разделе образцов

@SpringBootApplication
@Controller
@EnableZuulProxy
@EnableDiscoveryClient
public class ZuulServerApplication {
    public static void main(String[] args) {
        new SpringApplicationBuilder(ZuulServerApplication.class).web(true).run(args);
    }
}

Я запускал этот набор сервисов локально, и все это работает нормально, но если я запускаю его в сети с некоторой нагрузкой или через VPN, то я начинаю видеть ошибки перенаправления zuul, которые я вижу как тайм-ауты клиента в журналах

Есть ли способ изменить тайм-аут на zulul forwards, чтобы я мог устранить эту проблему из-за моих непосредственных проблем. Какие доступные параметры доступны для этого.

Я нахожусь в середине выпуска, и это только что появилось:)

Ответ 1

Свойства для установки: ribbon.ReadTimeout в целом и <service>.ribbon.ReadTimeout для определенной службы в миллисекундах. В Ribbon wiki есть несколько примеров. Этот javadoc имеет имена свойств.

Ответ 2

В моем случае мне пришлось изменить следующее свойство:

zuul.host.socket-timeout-millis=30000

Ответ 3

У меня возникла одна и та же проблема: при длинных запросах команда hugrix Zuul продолжала выходить из строя через секунду, несмотря на установку ribbon.ReadTimeout=10000.

Я решил это, полностью отключив таймауты:

hystrix:
  command:
    default:
      execution:
        timeout:
          enabled: false

Альтернативой, которая также работает, является изменение стратегии изоляции Zuul Hystrix на THREAD:

hystrix:
  command:
    default:
      execution:
        isolation:
          strategy: THREAD
          thread:
            timeoutInMilliseconds: 10000

Ответ 4

Мне пришлось изменить два тайм-аута, чтобы заставить zuul прекратить синхронизацию длительных запросов. Даже если таймауты hystrix отключены, лента по-прежнему будет отключена.

hystrix:
  command:
    default:
      execution:
        timeout:
          enabled: false
ribbon:
  ReadTimeout: 100000
  ConnectTimeout: 100000

Ответ 5

Это сработало для меня, я должен был установить время ожидания подключения и сокета в application.yml:

zuul:
  host:
    connect-timeout-millis: 60000 # starting the connection 
    socket-timeout-millis: 60000  # monitor the continuous incoming data flow

Ответ 6

Если Zuul использует обнаружение служб, вам нужно настроить эти таймауты со свойствами ленты. ribbon.ReadTimeout и ribbon.SocketTimeout.

Если вы настроили маршруты Zuul, указав URL-адреса, вам нужно использовать zuul.host.connect-timeout-millis и zuul.host.socket-timeout-millis

я имею в виду маршруты

zuul:
  routes:
    dummy-service:
      path: /dummy/**

Ответ 7

У меня была похожая проблема, и я пытался установить глобальное время ожидания, а также последовательность установки таймаута для вопросов Hystrix и Ribbon.

Потратив много времени, я остановился на этом решении. Мой сервис занимал до 50 секунд из-за огромного объема данных.

Точки, которые следует учитывать перед изменением значения по умолчанию для Timeout:

Время Hystrix должно быть больше, чем объединенное время Ribbon ReadTimeout и ConnectionTimeout.

Используйте только для определенных услуг, что означает, что не устанавливается глобально (что не работает).

Я имею в виду использовать это:

command:
   your-service-name:

вместо этого:

command:
   default:

Рабочий раствор:

hystrix:
 command:
   your-service-name:
  execution:
    isolation:
      strategy: THREAD
      thread:
        timeoutInMilliseconds: 95000

your-service-name:
 ribbon:
  ConnectTimeout: 30000
  ReadTimeout: 60000
  MaxTotalHttpConnections: 500
  MaxConnectionsPerHost: 100

Ссылка

Ответ 8

У меня работали только эти настройки на application.yml:

ribbon:
    ReadTimeout: 90000
    ConnectTimeout: 90000

eureka:
    enabled: true

zuul:
    host:
        max-total-connections: 1000
        max-per-route-connections: 100
    semaphore:
        max-semaphores: 500

hystrix:
    command:
        default:
            execution:
                isolation:
                    thread:
                        timeoutInMilliseconds: 1000000

Надеюсь, это поможет кому-то!