1. Предыстория проблемы
Кластер сервисов, созданный с использованием компонентов Spring Cloud, часто испытывает тайм-аут при первом запросе, но во второй раз он работает нормально. Версия Spring Cloud — Dalston.SR4.
Запустите соответствующие службы:
- шлюз (Зуул шлюз)
- аутентификация (служба аутентификации)
- Услуги пользователей (обслуживание клиентов)
Интерфейс конечной точки теста: http:/login/oauth/token. Последовательность вызовов между службами: шлюз->служба авторизации->служба-пользователь. Шлюз получает запрос клиента и перенаправляет запрос в службу аутентификации. Служба аутентификации проверяет личность пользователя, вызывая службу пользователя. Служба пользователя возвращает результат проверки личности в службу аутентификации, а служба аутентификации возвращает личность. информацию об авторизации шлюзу, шлюз возвращает ответ с окончательным результатом клиенту. После запуска трех служб отслеживайте информацию о ссылке вызова через zipkin, и вы можете увидеть первый и второй вызовы, как показано на следующем рисунке:
Из приведенных выше двух скриншотов с информацией о мониторинге ссылок видно, что первый раз более чем в 10 раз длиннее второго. В некоторых случаях очень вероятно, что будет тайм-аут первого запроса. Я зашел на официальный сайт и посмотрел на него.Основная причина в том, что лента между шлюзом zuul и различными вызывающими службами выполняет ленивую загрузку клиента для балансировки нагрузки клиента, в результате чего первый вызов запроса включает время для создания клиента ленты . Узнать это можно, запустив лог-информацию:
Отложенная загрузка клиента ленты
Ниже приводится решение этой проблемы, состоящее из двух частей: первая — вызвать голодающую загрузку Ribbon между службами, что соответствует приведенному выше тесту для вызова user-Service для auth-Service, а другая — голодающая загрузка шлюза zuul.
2. Лента голодает загрузки
После расследования было обнаружено, что основная причина того, что первая служба аутентификации долго вызывает службу пользователя, заключается в том, что экземпляр службы, который Ribbon выполняет балансировку клиентской нагрузки, инициализируется не при запуске службы, а только тогда, когда она Будет создан соответствующий экземпляр службы. Таким образом, время, необходимое для вызова пользовательской службы в первый раз, включает не только время отправки HTTP-запроса, но и время создания ленточного клиента. Таким образом, если время создания медленное и время ожидания запроса набор относительно короткий, это легко Это займет много времени или даже тайм-аут. На официальном сайте вы можете увидеть следующие инструкции по настройке:
Each Ribbon named client has a corresponding child Application Context that Spring Cloud maintains, this application context is lazily loaded up on the first request to the named client. This lazy loading behavior can be changed to instead eagerly load up these child Application contexts at startup by specifying the names of the Ribbon clients.
Это означает, что Spring Cloud поддерживает относительный контекст среды подприложения для каждого клиента Ribbon, а контекст приложения загружается отложенно при первом запросе к указанному клиенту. Однако его можно изменить с помощью следующей конфигурации:
ribbon:
eager-load:
enabled: true
clients: client1, client2, client3В соответствии с приведенной выше конфигурацией обнаружено, что ленточный клиент пользовательской службы загружается при запуске службы проверки подлинности.
пользовательская служба нетерпеливая нагрузка
3. Голодная загрузка zuul gateway
В приведенном выше разделе решается проблема голодной загрузки, когда ленточный клиент пользовательской службы вызывается службой аутентификации. Шлюз используется в качестве точки входа для внешних запросов. Zuul использует ленту для внутреннего вызова других служб. Spring Cloud по умолчанию загружает клиент ленты лениво при первом вызове. Zuul также должен поддерживать относительный контекст среды подприложения, поэтому он также должен быть голодным при запуске.
Zuul внутренне использует ленту для вызова удаленных URL-адресов, а клиенты ленты по умолчанию лениво загружаются Spring Cloud при первом вызове.Это поведение можно изменить для Zuul с помощью следующей конфигурации и приведет к дочернему Контексты приложений, связанные с лентой, активно загружаются во время запуска приложения.
Конкретная конфигурация выглядит следующим образом:
zuul:
ribbon:
eager-load:
enabled: trueНа этом оптимизация завершена, снова перезапустите сервис, чтобы сделать первый запрос, и обнаружите, что ситуация намного лучше, вы можете попытаться улучшить ее самостоятельно.
4. Резюме
В этой статье в основном представлен метод оптимизации для тайм-аута первого запроса службы Spring Cloud. Сначала вводится предыстория проблемы и исследуется причина проблемы, в основном ленивая загрузка клиента Ribbon; затем выполняется настройка клиента Ribbon, вызываемого между шлюзом zuul и службой, чтобы лента клиент загружается при запуске контекстная информация. Последнее, что я хочу сказать, это то, что производительность http-вызовов все-таки намного ниже, чем у RPC. . 🙂
Ссылаться на
WeChat награда
Вознаграждение Alipay
- Автор этой статьи: aoho
- Ссылка на эту статью: блюз доступен empty.com/2017/11/18/…
- Уведомление об авторских правах:Все статьи в этом блоге, если не указано иное, используютCC BY-NC-SA 3.0соглашение. Пожалуйста, укажите источник!