Spring Cloud обеспечивает поддержку Netflix Zuul — инструментария для создания пограничных сервисов с возможностями маршрутизации и фильтрации.
Поддержка Zuul Proxy подробно описана на сайте Spring Cloud. Моя цель здесь — сосредоточиться на небольшом наборе атрибутов, связанных с обработкой таймаутов при работе с прокси-сервисами.
Целевой Сервис и Шлюз
Чтобы лучше изучить таймауты, я создал образец сервиса (код доступен здесь ), который принимает настраиваемый параметр «delay» как часть тела запроса, а пример запроса / ответа выглядит примерно так:
Пример запроса с 5-секундной задержкой:
|
1
2
3
4
5
6
|
{ "id": "1", "payload": "Hello", "delay_by": 5000, "throw_exception": false} |
и ожидаемый ответ:
|
1
2
3
4
5
|
{ "id": "1", "received": "Hello", "payload": "Hello!"} |
Этот сервис зарегистрирован с идентификатором «sample-svc» в Eureka, прокси-сервер Spring Cloud Zuul поверх этого сервиса имеет следующую конфигурацию:
|
1
2
3
4
5
6
7
|
zuul: ignoredServices: '*' routes: samplesvc: path: /samplesvc/** stripPrefix: true serviceId: sample-svc |
По сути, все запросы в / samplesvc / uri отправляются в службу, не имеющую неоднозначности, с именем sample-svc через Eureka.
У меня также есть интерфейс поверх шлюза, чтобы упростить тестирование с разными задержками:
Тесты задержки обслуживания
Шлюз ведет себя без каких-либо проблем, связанных с тайм-аутом, когда к служебному вызову добавляется параметр с низкой задержкой, однако, если параметр задержки изменяется так низко, как, скажем, от 1 до 1,5 секунд, шлюз будет отключаться.
Причина в том, что если шлюз настроен на использование Eureka, то шлюз использует компонент ленты Netflix для фактического вызова. Кроме того, вызов ленты обернут в Hystrix, чтобы гарантировать, что вызов остается отказоустойчивым. Первый тайм-аут, который мы выберем, заключается в том, что Hystrix имеет очень низкий порог допуска задержки, и настройка параметров Hystrix должна помочь нам преодолеть первый тайм-аут.
|
1
2
3
4
5
6
7
|
hystrix: command: sample-svc: execution: isolation: thread: timeoutInMilliseconds: 15000 |
Обратите внимание, что «командный ключ» Hystrix, используемый для настройки, — это имя службы, зарегистрированное в Eureka.
Это может быть слишком мелкозернистым для этого конкретного вызова Zuul, если вы хорошо настроили настройку по всем направлениям, тогда конфигурация по этим направлениям должна помочь:
|
1
2
3
4
5
6
7
|
hystrix: command: default: execution: isolation: thread: timeoutInMilliseconds: 15000 |
С этим изменением запрос к услуге через шлюз с задержкой до 5 секунд теперь будет проходить без проблем. Если бы мы превысили 5 секунд, мы бы получили еще один тайм-аут. Сейчас мы перешли к настройке тайм-аута ленты, которая снова может быть настроена детально для конкретного вызова службы путем настройки конфигурации, которая выглядит следующим образом:
|
1
2
3
|
sample-svc: ribbon: ReadTimeout: 15000 |
С обоими этими настройками тайм-аута теперь должен проходить вызов на основе шлюза
Вывод
Цель состояла не в том, чтобы показать способы установки произвольно высоких значений времени ожидания, а просто в том, чтобы показать, как установить значения, которые могут быть более подходящими для ваших приложений. Разумные тайм-ауты очень важны для обеспечения того, чтобы плохое поведение сервисов не касалось пользователей. Следует отметить, что если шлюз настроен без ленты и Eureka путем указания прямого URL-адреса для службы, то эти параметры тайм-аута вообще не имеют значения.
Если вы заинтересованы в дальнейшем изучении этого, образцы доступны здесь .
| Ссылка: | Поддержка Spring Cloud Zuul — Настройка тайм-аутов от нашего партнера JCG Биджу Кунджуммена в блоге all and sundry. |