Что нового в API7 Enterprise 3.2.9: Обновленная конфигурация Health Check

Введение в новые функции проверки работоспособности

В версии 3.2.9 API7 Enterprise опыт взаимодействия с настройками проверки работоспособности был значительно улучшен.

1. Ранее разрозненные элементы конфигурации были логически объединены, такие как настройки зондов и критерии определения здоровых и нездоровых узлов, что сделало их более структурированными.

2. Некоторые абстрактные названия элементов конфигурации были преобразованы в более интуитивно понятные и семантические выражения, позволяя пользователям напрямую вводить соответствующие параметры в формате заполнения пропусков, что дает более четкое понимание практических эффектов настроек.

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

Основные концепции проверки работоспособности

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

Только если все узлы с наивысшим приоритетом будут признаны недоступными из-за неудачных проверок работоспособности, шлюз автоматически переключится на узлы с более низким приоритетом. Этот дизайн обеспечивает эффективное использование трафика и высокую доступность системы.

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

Методы настройки проверки работоспособности

Настройка зонда

Зонд используется для проверки активности и состояния сервиса вышестоящих узлов. В APISIX зонд похож на "инспектора", который регулярно проверяет, работает ли вышестоящий сервис. Если он обнаруживает проблемы или сервис "недоступен", он сообщает APISIX: "Этот сервис сейчас недоступен, поэтому не отправляйте сюда запросы". Этот процесс "проверки" выполняется с помощью зондов.

Зонд включает следующие элементы конфигурации:

• Схема зонда: Тип протокола, используемого зондом для проверки работоспособности, поддерживает TCP, HTTP и HTTPS.

• Конкуренция: Этот элемент конфигурации позволяет установить количество одновременных запросов проверки работоспособности. Другими словами, это количество раз, которое вы хотите "постучаться в дверь" одновременно, чтобы проверить отзывчивость вышестоящих сервисов. Регулируя конкуренцию, вы можете моделировать возможные одновременные запросы в реальных сценариях, что позволяет лучше оценить производительность и стабильность вышестоящих сервисов.

• Хост: Указывает адрес хоста вышестоящего сервера, который нужно проверить. Это как определить, в какой дом "постучаться".

• Порт: Номер порта вышестоящего сервиса. Это как знать, в какую дверь постучаться во время проверки.

• Путь: Если вы используете HTTP-зонд, этот элемент конфигурации указывает путь URL, который вы хотите проверить. Это как сказать зонду, какую комнату проверить, когда он войдет.

Критерии определения здоровых узлов

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

Если зонд использует протокол TCP, узел считается здоровым после того, как зонд успешно подключится к вышестоящему узлу количество раз, установленное пользователем.

Если зонд использует протокол HTTP/HTTPS, система считает узел здоровым только тогда, когда он непрерывно получает запросы зонда с указанными кодами состояния (такими как 200 и 302) от узла. Это означает, что узел считается работающим правильно только тогда, когда он непрерывно возвращает эти конкретные коды состояния.

Критерии определения нездоровых узлов

Что касается определения нездоровых узлов, метод конфигурации аналогичен определению здоровых узлов. Система регулярно проверяет узлы, отмеченные как здоровые, с интервалом, установленным пользователем. Как только эти узлы соответствуют предустановленным условиям нездоровья, они переклассифицируются как нездоровые.

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

Лучшие практики проверки работоспособности

Выбор подходящего типа зонда

• TCP-зонд: Подходит для сценариев, где требуется только подтверждение, что порт сервиса открыт и доступен. Например, для сервиса базы данных может потребоваться только TCP-зонд для подтверждения открытия порта.

• HTTP/HTTPS-зонд: Более подходит для сценариев, где требуется подтверждение не только нормального сетевого соединения, но и того, что сервис может правильно обрабатывать запросы. Например, для веб-сервера или API-сервиса нам нужно убедиться, что он может не только принимать соединения, но и возвращать правильные страницы или данные.

Разумная настройка параметров проверки работоспособности

При настройке проверки работоспособности обратите внимание на несколько ключевых параметров:

• Интервал проверки: Он не должен быть слишком коротким, чтобы избежать ненужной нагрузки, или слишком длинным, чтобы избежать медленного реагирования в случае проблем. Например, для сайта электронной коммерции с высоким трафиком проверка каждые 30 секунд является относительно разумным выбором. Этот интервал не чрезмерно потребляет ресурсы системы и не задерживает обнаружение и обработку проблем на сайте.

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

• Тайм-аут: Время, которое зонд ждет ответа от сервиса. Если сервис не отвечает в течение этого времени, зонд считает сервис нездоровым. Это значение должно быть установлено в соответствии с фактическим временем ответа сервиса.

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

Корректировка стратегий на основе бизнеса

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

Включение проверки клиентских запросов по мере необходимости

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

1. Сервисы с низким трафиком: Если трафик сервиса низкий, пассивные проверки работоспособности на основе клиентских запросов могут не предоставить достаточно данных для точной оценки состояния сервиса. В таких случаях более надежным может быть использование активных проверок зонда.

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

3. Наличие других систем мониторинга: Если в компании уже развернуты зрелые системы мониторинга, способные захватывать и анализировать состояние сервиса в реальном времени, пассивные проверки работоспособности могут быть не нужны, чтобы избежать избыточности данных и дополнительной сложности.

Заключение

Проверка работоспособности является важным аспектом обеспечения высокой доступности API-шлюзов. В версии 3.2.9 API7 Enterprise мы значительно улучшили интерактивную конфигурацию проверки работоспособности, упростив операции и улучшив пользовательский опыт.

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