--- title: "Что нового в API7 Enterprise 3.2.9: Обновленная конфигурация Health Check - API7.ai" description: "В версии API7 Enterprise 3.2.9 функция проверки работоспособности была полностью оптимизирована, предоставляя более интуитивно понятные и семантически ясные параметры конфигурации. Это помогает пользователям легко управлять upstream-узлами и достигать эффективной балансировки нагрузки." url: "https://api7.ai/ru/blog/api7-3.2.9-upgraded-health-check-configuration" --- [Blog](https://api7.ai/ru/blog) [Products](https://api7.ai/ru/category/products)[Technology](https://api7.ai/ru/category/technology)[Ecosystem](https://api7.ai/ru/category/ecosystem)[Case Study](https://api7.ai/ru/category/usercase)[Team & Community](https://api7.ai/ru/category/community) Search ⌘ + K [Blog](https://api7.ai/blog) Products # Что нового в API7 Enterprise 3.2.9: Обновленная конфигурация Health Check [![Zhihuang Lin](https://github.com/oil-oil.png)](https://github.com/oil-oil) [Zhihuang Lin](https://github.com/oil-oil) April 16, 2024 [Products](https://api7.ai/category/products) ## Введение в новые функции проверки работоспособности В версии 3.2.9 [API7 Enterprise](https://api7.ai/enterprise) опыт взаимодействия с настройками проверки работоспособности был значительно улучшен. 1. Ранее разрозненные элементы конфигурации были логически объединены, такие как настройки зондов и критерии определения здоровых и нездоровых узлов, что сделало их **более структурированными**. 2. Некоторые абстрактные названия элементов конфигурации были преобразованы в **более интуитивно понятные** и семантические выражения, позволяя пользователям напрямую вводить соответствующие параметры в формате заполнения пропусков, что дает более четкое понимание практических эффектов настроек. 3. В процессе настройки вышестоящих узлов и проверки работоспособности добавлено больше подсказок, помогающих пользователям лучше понять внутреннюю связь между вышестоящими узлами и проверкой работоспособности, что облегчает **более простое** выполнение задач конфигурации. ![Сравнение конфигураций проверки работоспособности в API7 Enterprise 3.2.9](https://static.api7.ai/uploads/2024/04/16/bWfDV00e_3.2.9-health-check-1.png?imageMogr2/format/webp) ## Основные концепции проверки работоспособности В API7 Enterprise настройка приоритета вышестоящих узлов тесно связана с механизмами балансировки нагрузки и проверки работоспособности. Когда пользователи настраивают несколько вышестоящих узлов с разными приоритетами для шлюза, шлюз в первую очередь использует узлы с наивысшим приоритетом при балансировке нагрузки. Это означает, что пока узлы с наивысшим приоритетом остаются здоровыми, шлюз будет продолжать направлять трафик на эти узлы. Только если все узлы с наивысшим приоритетом будут признаны недоступными из-за неудачных проверок работоспособности, шлюз автоматически переключится на узлы с более низким приоритетом. Этот дизайн обеспечивает эффективное использование трафика и высокую доступность системы. Стоит отметить, что если в сервисе настроено несколько уровней приоритета вышестоящих узлов, но функция проверки работоспособности отключена, то все клиентские запросы всегда будут направляться на узлы с наивысшим приоритетом, независимо от их фактического состояния. ## Методы настройки проверки работоспособности ### Настройка зонда Зонд используется для проверки активности и состояния сервиса вышестоящих узлов. В [APISIX](https://api7.ai/apisix) зонд похож на "инспектора", который регулярно проверяет, работает ли вышестоящий сервис. Если он обнаруживает проблемы или сервис "недоступен", он сообщает APISIX: "Этот сервис сейчас недоступен, поэтому не отправляйте сюда запросы". Этот процесс "проверки" выполняется с помощью зондов. **Зонд включает следующие элементы конфигурации:** ![Настройка зонда в API7 Enterprise 3.2.9](https://static.api7.ai/uploads/2024/04/16/kCS79sWQ_3.2.9-health-check-2.png?imageMogr2/format/webp) - **Схема зонда**: Тип протокола, используемого зондом для проверки работоспособности, поддерживает TCP, HTTP и HTTPS. - **Конкуренция**: Этот элемент конфигурации позволяет установить количество одновременных запросов проверки работоспособности. Другими словами, это количество раз, которое вы хотите "постучаться в дверь" одновременно, чтобы проверить отзывчивость вышестоящих сервисов. Регулируя конкуренцию, вы можете моделировать возможные одновременные запросы в реальных сценариях, что позволяет лучше оценить производительность и стабильность вышестоящих сервисов. - **Хост**: Указывает адрес хоста вышестоящего сервера, который нужно проверить. Это как определить, в какой дом "постучаться". - **Порт**: Номер порта вышестоящего сервиса. Это как знать, в какую дверь постучаться во время проверки. - **Путь**: Если вы используете HTTP-зонд, этот элемент конфигурации указывает путь URL, который вы хотите проверить. Это как сказать зонду, какую комнату проверить, когда он войдет. ### Критерии определения здоровых узлов ![Определение здоровых узлов в API7 Enterprise](https://static.api7.ai/uploads/2024/04/16/RAAxOPaF_3.2.9-health-check-3.png?imageMogr2/format/webp) Что касается определения здоровых узлов, система регулярно проверяет узлы, ранее отмеченные как нездоровые, с интервалом, установленным пользователем (в секундах), чтобы своевременно обнаруживать и правильно обрабатывать любые временные аномалии узлов. Если зонд использует протокол TCP, узел считается здоровым после того, как зонд успешно подключится к вышестоящему узлу количество раз, установленное пользователем. Если зонд использует протокол HTTP/HTTPS, система считает узел здоровым только тогда, когда он непрерывно получает запросы зонда с указанными кодами состояния (такими как `200` и `302`) от узла. Это означает, что узел считается работающим правильно только тогда, когда он непрерывно возвращает эти конкретные коды состояния. ### Критерии определения нездоровых узлов ![Определение нездоровых узлов в API7 Enterprise](https://static.api7.ai/uploads/2024/04/16/4GXUqB8C_3.2.9-health-check-4.png?imageMogr2/format/webp) Что касается определения нездоровых узлов, метод конфигурации аналогичен определению здоровых узлов. Система регулярно проверяет узлы, отмеченные как здоровые, с интервалом, установленным пользователем. Как только эти узлы соответствуют предустановленным условиям нездоровья, они переклассифицируются как нездоровые. Немного отличаясь от определения здоровых узлов, в процессе определения нездоровых узлов добавляется дополнительный элемент конфигурации — проверка клиентских запросов. Когда эта функция включена, шлюз не только полагается на результаты проверки зонда, но и глубоко анализирует запросы от клиентов и фактические ответы от вышестоящих сервисов. На основе этих данных и пользовательских критериев шлюз может более точно оценивать состояние работы вышестоящих сервисов. ## Лучшие практики проверки работоспособности ### Выбор подходящего типа зонда - **TCP-зонд**: Подходит для сценариев, где требуется только подтверждение, что порт сервиса открыт и доступен. Например, для сервиса базы данных может потребоваться только TCP-зонд для подтверждения открытия порта. - **HTTP/HTTPS-зонд**: Более подходит для сценариев, где требуется подтверждение не только нормального сетевого соединения, но и того, что сервис может правильно обрабатывать запросы. Например, для веб-сервера или API-сервиса нам нужно убедиться, что он может не только принимать соединения, но и возвращать правильные страницы или данные. ### Разумная настройка параметров проверки работоспособности При настройке проверки работоспособности обратите внимание на несколько ключевых параметров: - **Интервал проверки**: Он не должен быть слишком коротким, чтобы избежать ненужной нагрузки, или слишком длинным, чтобы избежать медленного реагирования в случае проблем. Например, для сайта электронной коммерции с высоким трафиком проверка каждые 30 секунд является относительно разумным выбором. Этот интервал не чрезмерно потребляет ресурсы системы и не задерживает обнаружение и обработку проблем на сайте. Конечно, этот интервал не является абсолютным, и его необходимо корректировать в зависимости от фактической ситуации сайта. Например, если сайт испытывает значительные колебания трафика или всплески трафика в определенные периоды (например, во время акций), может потребоваться корректировка интервала проверки для адаптации к этим изменениям. - **Тайм-аут**: Время, которое зонд ждет ответа от сервиса. Если сервис не отвечает в течение этого времени, зонд считает сервис нездоровым. Это значение должно быть установлено в соответствии с фактическим временем ответа сервиса. - **Количество повторных попыток**: Количество попыток подключения зонда перед тем, как сервис будет признан нездоровым. Это значение должно быть умеренным, чтобы избежать ошибочных суждений. ### Корректировка стратегий на основе бизнеса Стратегии проверки работоспособности должны корректироваться в зависимости от фактической бизнес-ситуации. Если сервис обычно испытывает высокие нагрузки в определенные периоды времени, интервалы проверки работоспособности могут быть увеличены или количество повторных попыток уменьшено в эти периоды, чтобы избежать дополнительного давления на сервис. ### Включение проверки клиентских запросов по мере необходимости Проверка клиентских запросов может эффективно определять состояние сервиса на основе фактических бизнес-запросов, особенно для выявления проблем, тесно связанных с бизнес-логикой. Однако она может не подходить для каждого бизнес-сценария. 1. **Сервисы с низким трафиком**: Если трафик сервиса низкий, пассивные проверки работоспособности на основе клиентских запросов могут не предоставить достаточно данных для точной оценки состояния сервиса. В таких случаях более надежным может быть использование активных проверок зонда. 2. **Соображения производительности в средах с высокой конкуренцией**: Пассивные проверки работоспособности требуют мониторинга и обработки каждого клиентского запроса, что может увеличить дополнительную нагрузку на производительность в средах с высокой конкуренцией. Если производительность является основным приоритетом и сервис уже адекватно контролируется другими средствами, пассивные проверки работоспособности могут быть отключены. 3. **Наличие других систем мониторинга**: Если в компании уже развернуты зрелые системы мониторинга, способные захватывать и анализировать состояние сервиса в реальном времени, пассивные проверки работоспособности могут быть не нужны, чтобы избежать избыточности данных и дополнительной сложности. ## Заключение [Проверка работоспособности](https://api7.ai/blog/health-check-ensures-high-availability) является важным аспектом обеспечения высокой доступности API-шлюзов. В версии 3.2.9 API7 Enterprise мы значительно улучшили интерактивную конфигурацию проверки работоспособности, упростив операции и улучшив пользовательский опыт. Правильно настраивая зонды, устанавливая критерии для здоровых и нездоровых узлов и корректируя стратегии на основе фактических бизнес-потребностей, пользователи могут более эффективно контролировать состояние вышестоящих сервисов, обеспечивая, чтобы трафик всегда направлялся на здоровые узлы. Это не только повышает стабильность и доступность системы, но и гарантирует, что пользовательские запросы получают своевременные и точные ответы. Tags: [API7 Enterprise](https://api7.ai/tags/api7-enterprise) [Health Check](https://api7.ai/tags/health-check) Share article link Share Related Posts [![API7 Enterprise v3.2.16.4 поддерживает уведомления через Webhook и Email Alert](https://static.api7.ai/uploads/2024/11/14/MZsGTMyQ_alert.png)](https://api7.ai/blog/api7-3.2.16.4-supports-email-webhook-alert-notification) ## [API7 Enterprise v3.2.16.4 поддерживает уведомления через Webhook и Email Alert](https://api7.ai/blog/api7-3.2.16.4-supports-email-webhook-alert-notification) [![API7 Enterprise v3.2.16.3 интегрируется с AWS Secrets Manager](https://static.api7.ai/uploads/2025/02/13/nrkyTz2U_3.2.16.3-aws-secrets-manager.png)](https://api7.ai/blog/api7-3.2.16.3-supports-aws-secrets-manager) ## [API7 Enterprise v3.2.16.3 интегрируется с AWS Secrets Manager](https://api7.ai/blog/api7-3.2.16.3-supports-aws-secrets-manager) Table of Contents - [Введение в новые функции проверки работоспособности](#%D0%B2%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B2-%D0%BD%D0%BE%D0%B2%D1%8B%D0%B5-%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%B8-%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B8-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BE%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1%D0%BD%D0%BE%D1%81%D1%82%D0%B8) - [Основные концепции проверки работоспособности](#%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D0%B5-%D0%BA%D0%BE%D0%BD%D1%86%D0%B5%D0%BF%D1%86%D0%B8%D0%B8-%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B8-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BE%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1%D0%BD%D0%BE%D1%81%D1%82%D0%B8) - [Методы настройки проверки работоспособности](#%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D1%8B-%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B8-%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B8-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BE%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1%D0%BD%D0%BE%D1%81%D1%82%D0%B8) - [Настройка зонда](#%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0-%D0%B7%D0%BE%D0%BD%D0%B4%D0%B0) - [Критерии определения здоровых узлов](#%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8-%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-%D0%B7%D0%B4%D0%BE%D1%80%D0%BE%D0%B2%D1%8B%D1%85-%D1%83%D0%B7%D0%BB%D0%BE%D0%B2) - [Критерии определения нездоровых узлов](#%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8-%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-%D0%BD%D0%B5%D0%B7%D0%B4%D0%BE%D1%80%D0%BE%D0%B2%D1%8B%D1%85-%D1%83%D0%B7%D0%BB%D0%BE%D0%B2) - [Лучшие практики проверки работоспособности](#%D0%BB%D1%83%D1%87%D1%88%D0%B8%D0%B5-%D0%BF%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D0%BA%D0%B8-%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B8-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BE%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1%D0%BD%D0%BE%D1%81%D1%82%D0%B8) - [Выбор подходящего типа зонда](#%D0%B2%D1%8B%D0%B1%D0%BE%D1%80-%D0%BF%D0%BE%D0%B4%D1%85%D0%BE%D0%B4%D1%8F%D1%89%D0%B5%D0%B3%D0%BE-%D1%82%D0%B8%D0%BF%D0%B0-%D0%B7%D0%BE%D0%BD%D0%B4%D0%B0) - [Разумная настройка параметров проверки работоспособности](#%D1%80%D0%B0%D0%B7%D1%83%D0%BC%D0%BD%D0%B0%D1%8F-%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0-%D0%BF%D0%B0%D1%80%D0%B0%D0%BC%D0%B5%D1%82%D1%80%D0%BE%D0%B2-%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B8-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BE%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1%D0%BD%D0%BE%D1%81%D1%82%D0%B8) - [Корректировка стратегий на основе бизнеса](#%D0%BA%D0%BE%D1%80%D1%80%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B0-%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%B5%D0%B3%D0%B8%D0%B9-%D0%BD%D0%B0-%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B5-%D0%B1%D0%B8%D0%B7%D0%BD%D0%B5%D1%81%D0%B0) - [Включение проверки клиентских запросов по мере необходимости](#%D0%B2%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B8-%D0%BA%D0%BB%D0%B8%D0%B5%D0%BD%D1%82%D1%81%D0%BA%D0%B8%D1%85-%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D0%BE%D0%B2-%D0%BF%D0%BE-%D0%BC%D0%B5%D1%80%D0%B5-%D0%BD%D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B8) - [Заключение](#%D0%B7%D0%B0%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5) ## Related Posts [![API7 Enterprise v3.5.0: Multi-Upstream Configuration](https://static.api7.ai/uploads/2025/02/19/mQ8cStKu_multi-upstream-configuration.png)](https://api7.ai/ru/blog/api7-3.5.0-mutli-upstream-for-traffic-management) Products February 19, 2025 #### [API7 Enterprise v3.5.0: Multi-Upstream Configuration](https://api7.ai/ru/blog/api7-3.5.0-mutli-upstream-for-traffic-management) API7 Enterprise v3.5.0 introduces multi-upstream configuration for flexibel and reliable traffic management. [Traffic Managment](https://api7.ai/tags/traffic-managment) [API7 Enterprise](https://api7.ai/tags/api7-enterprise) [![API7 Enterprise v3.4.0: Упрощенное управление сертификатами через SNI](https://static.api7.ai/uploads/2025/02/13/Q7IIQt7d_sni-certificate-management.png)](https://api7.ai/ru/blog/api7-3.4.0-sni-certificate-management) Products February 13, 2025 #### [API7 Enterprise v3.4.0: Упрощенное управление сертификатами через SNI](https://api7.ai/ru/blog/api7-3.4.0-sni-certificate-management) API7 Enterprise v3.4.0 представляет управление ресурсами SNI для интуитивно понятного и эффективного управления сертификатами. [Certificate Management](https://api7.ai/tags/certificate-management) [API7 Enterprise](https://api7.ai/tags/api7-enterprise) [![API7 Enterprise v3.3.0 поддерживает API Portal](https://static.api7.ai/uploads/2024/12/26/y70oTHfl_api-portal-cover.png)](https://api7.ai/ru/blog/api7-3.3.0-api-portal) Products December 26, 2024 #### [API7 Enterprise v3.3.0 поддерживает API Portal](https://api7.ai/ru/blog/api7-3.3.0-api-portal) API7 Enterprise поддерживает API Portal, что повышает доступность API, упрощает интеграцию и улучшает управление жизненным циклом вашей платформы. [API Portal](https://api7.ai/tags/api-portal) [API7 Enterprise](https://api7.ai/tags/api7-enterprise)