Связь между ленточным и тайм-аутом hystrix

Spring Cloud

Феномен

Недавно я обнаружил подсказку фонового журнала при тестировании производительности слоя Zuul проекта.

2018-12-03 16:22:30.306  WARN [apigateway,7447152c2c5cc400,7447152c2c5cc400,true] 20024 --- [nio-8102-exec-3] o.s.c.n.z.f.r.s.AbstractRibbonCommand    : The Hystrix timeout of 3000ms for the command serviceA is set lower than the combination of the Ribbon read and connect timeout, 28000ms.

Макет представляет собой комбинацию тайм-аута HYSTRIX, меньшего, чем тайм-аут чтения ленты, и тайм-аут соединения.

Роль HYSTRIX и RIBBON

hystrix: прерыватель цепи.Когда шлюз zuul вызывает конкретный бизнес, на него может влиять сеть, время выполнения кода и т. д., и ответа не будет в течение длительного времени. В это время вам необходимо настроить hystrix на избегайте того, чтобы потоки занимали память в течение длительного времени, вызывая утечки памяти и зависания службы.

Лента: балансировка нагрузки, которая представляет собой конфигурацию балансировки нагрузки с несколькими экземплярами для служб.

Почему это предупреждение?

Поскольку в производственной среде наши серверы обычно развертываются в кластерах, лента не только выполняет функцию балансировки нагрузки, но также имеет функцию повторной попытки при сбое, но если экземпляр 1 не работает или истекает время чтения, лента будет пересылать запрос к другому экземпляру Если hystrix Если время предохранения меньше, чем время тайм-аута ленты, возможно, что hystrix переплавится при повторной попытке ленты, поэтому повторная конфигурация ленты не имеет практического эффекта.

Откуда берется тайм-аут hystrix и риббона?

hystrix

Время взрывателя hystrix настроено следующим образом:

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds

ribbon

Как видно из приведенного выше, период ожидания ленты представляет собой комбинацию периода ожидания чтения ленты и периода ожидания подключения.Проверьте исходный код, чтобы узнать

protected static int getHystrixTimeout(IClientConfig config, String commandKey) {
  int ribbonTimeout = getRibbonTimeout(config, commandKey);
  DynamicPropertyFactory dynamicPropertyFactory = DynamicPropertyFactory.getInstance();
  // 获取默认的hytrix超时时间
  int defaultHystrixTimeout = dynamicPropertyFactory.getIntProperty("hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds", 0).get();
  // 获取具体服务的hytrix超时时间，这里应该是hystrix.command.serviceA.execution.isolation.thread.timeoutInMilliseconds
  int commandHystrixTimeout = dynamicPropertyFactory.getIntProperty("hystrix.command." + commandKey + ".execution.isolation.thread.timeoutInMilliseconds", 0).get();
  int hystrixTimeout;
  // hystrixTimeout的优先级是 具体服务的hytrix超时时间 > 默认的hytrix超时时间 > ribbon超时时间
  if (commandHystrixTimeout > 0) {
    hystrixTimeout = commandHystrixTimeout;
  } else if (defaultHystrixTimeout > 0) {
    hystrixTimeout = defaultHystrixTimeout;
  } else {
    hystrixTimeout = ribbonTimeout;
  }
  // 如果默认的或者具体服务的hytrix超时时间小于ribbon超时时间就会警告
  if (hystrixTimeout < ribbonTimeout) {
    LOGGER.warn("The Hystrix timeout of " + hystrixTimeout + "ms for the command " + commandKey + " is set lower than the combination of the Ribbon read and connect timeout, " + ribbonTimeout + "ms.");
  }

  return hystrixTimeout;
}

Как видно из второй строчки кода, риббонтаймаут получается через метод getRibbonTimeout()

protected static int getRibbonTimeout(IClientConfig config, String commandKey) {
  int ribbonTimeout;
  // 默认为 2s
  if (config == null) {
    ribbonTimeout = 2000;
  } else {
    // 这里获取了四个参数，ReadTimeout，ConnectTimeout，MaxAutoRetries， MaxAutoRetriesNextServer,优先级：具体服务 > 默认
    // 1. 请求处理的超时时间,默认 1s
    int ribbonReadTimeout = getTimeout(config, commandKey, "ReadTimeout", Keys.ReadTimeout, 1000);
    // 2. 请求连接的超时时间,默认 1s
    int ribbonConnectTimeout = getTimeout(config, commandKey, "ConnectTimeout", Keys.ConnectTimeout, 1000);
    // 3. 对当前实例的重试次数.默认 0
    int maxAutoRetries = getTimeout(config, commandKey, "MaxAutoRetries", Keys.MaxAutoRetries, 0);
    // 4. 切换实例的重试次数,默认 1
    int maxAutoRetriesNextServer = getTimeout(config, commandKey, "MaxAutoRetriesNextServer", Keys.MaxAutoRetriesNextServer, 1);
    // ribbonTimeout的计算方法
    ribbonTimeout = (ribbonReadTimeout + ribbonConnectTimeout) * (maxAutoRetries + 1) * (maxAutoRetriesNextServer + 1);
  }

  return ribbonTimeout;
}

Отсюда видно,

ribbonTimeout = (ribbonReadTimeout + ribbonConnectTimeout) * (maxAutoRetries + 1) * (maxAutoRetriesNextServer + 1);

в

ribbonReadTimeout 由 ribbon.ReadTimeout 配置决定
ribbonConnectTimeout 由 ribbon.ConnectTimeout 配置决定
maxAutoRetries 由 ribbon.MaxAutoRetries 配置决定
maxAutoRetriesNextServer 由 ribbon.MaxAutoRetriesNextServer 配置决定

Конфигурация нашего проекта

"hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds": 3000
"ribbon.ReadTimeout": 3000,
"ribbon.ConnectTimeout": 1000,
"ribbon.MaxAutoRetries": 0,
"ribbon.MaxAutoRetriesNextServer": 0,

Так ribbontimeout = (3000 + 1000)(1+0)(1+0)=4000ms

PS

Почему Maxautortries и Maxautoretiesnextserver настраивают наш проект, это ноль

Фактически он основан на рассмотрении идемпотентности.

Решите, следует ли включить повторную попытку при сбое на основе различных сценариев.

Одним словом, дизайны, вышедшие из бизнеса, — это все хулиганы, сказал г-н Шэнь Цзянь.

Категории