АРХИТЕКТУРА И АЛГОРИТМ РАБОТЫ ПРОГРАММНОЙ ПЛАТФОРМЫ МНОГОУРОВНЕВОГО КОНТРОЛЯ СОСТОЯНИЯ РАСПРЕДЕЛЕННЫХ ВЕБ-СЕРВИСОВ

SOFTWARE PLATFORM ARCHITECTURE AND OPERATION ALGORITHM FOR MULTI-LEVEL STATE CONTROL OF DISTRIBUTED WEB SERVICES

Ignatiev Alexander Vsevolodovich

Student, Tula State University,

 Russia, Tula

АННОТАЦИЯ

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

ABSTRACT

The paper considers the design of a software platform for multi-level state control of distributed web services. The proposed approach separates availability, SSL/TLS and functional checks. The paper describes the platform architecture, the result storage model and the checking algorithm based on a task queue, retry handling and optional event publication to an external monitoring system.

Ключевые слова: программная платформа; распределенные веб-сервисы; архитектура программного обеспечения; REST API; SSL/TLS; модель данных; алгоритм проверки; брокер сообщений.

Keywords: software platform; distributed web services; software architecture; REST API; SSL/TLS; data model; checking algorithm; message broker.

Введение

Распределенные веб-сервисы используются в системах, где отдельные компоненты взаимодействуют через сетевые интерфейсы и могут отказывать независимо друг от друга. При этом простая проверка доступности отражает только факт ответа интерфейса, но не позволяет оценить корректность защищенного соединения и выполнение прикладной операции. Поэтому контроль состояния целесообразно рассматривать как многоуровневую задачу, включающую сетевой, транспортно-защищенный и функциональный уровни [2; 4; 9].

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

Постановка задачи и состав проверок

Объектом исследования являются распределенные веб-сервисы. Предметом исследования выступают архитектура и алгоритм программной платформы, обеспечивающей выполнение проверок состояния, хранение истории результатов и передачу сведений во внешний контур мониторинга. Архитектурная организация платформы опирается на разделение ответственности между интерфейсом, ядром управления, модулями проверок, базой данных и интеграционным контуром [1].

Соответствие классов отказов типам проверок приведено в таблице 1. Проверка доступности фиксирует факт ответа сетевого или HTTP-интерфейса [3]. Проверка SSL/TLS выявляет ошибки защищенного соединения и проблемы сертификатов [6; 8]. Функциональная проверка применяется при наличии заданного прикладного сценария и позволяет установить, выполняет ли сервис ожидаемую операцию.

Таблица 1.

Соответствие классов отказов типам проверок

Архитектура программной платформы

Архитектура платформы строится по принципу разделения ответственности. REST API используется для ручного запуска и получения результатов, планировщик формирует регулярные задания, модуль синхронизации обновляет сведения о сервисах, а ядро платформы координирует выполнение проверок. Обобщенная архитектура представлена на рисунке 1.

Рисунок 1. Архитектура программной платформы многоуровневого контроля состояния распределенных веб-сервисов

Результаты проверок сохраняются в базе данных, а брокер сообщений рассматривается как опциональный компонент для передачи событий во внешний мониторинг [5]. Основным источником истории остается база результатов, поэтому временная недоступность брокера не приводит к потере сведений о проверках.

Таблица 2.

Основные компоненты платформы

Модель хранения результатов

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

Для хранения специфичных сведений используется структурированное поле дополнительных данных. Его состав зависит от типа проверки: для SSL/TLS это может быть срок действия сертификата, для проверки доступности - код ответа или тип сетевой ошибки, для функциональной проверки - сведения о выполненном сценарии. Такой подход позволяет сохранять результаты разных типов в единой истории без создания отдельных таблиц под каждый вид проверки [7].

Алгоритм проверочного цикла

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

Рисунок 2. Алгоритм выполнения проверочного цикла программной платформы

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

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

Ограничения и заключение

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

В работе предложены архитектура и алгоритм работы программной платформы многоуровневого контроля состояния распределенных веб-сервисов. Показано, что разделение проверок на доступность, SSL/TLS и функциональность позволяет фиксировать разные классы отказов. Описаны основные компоненты платформы, модель хранения результатов и обработка очереди проверочных заданий. Архитектура может использоваться как основа для реализации системы контроля веб-сервисов с сохранением истории и опциональной передачей событий во внешний мониторинг.

Список литературы:

1. Bass L., Clements P., Kazman R. Software Architecture in Practice. — 4th ed. — Boston: Addison-Wesley Professional, 2021. — 464 p.
2. Ewaschuk R. Monitoring Distributed Systems // Site Reliability Engineering: How Google Runs Production Systems / ed. by B. Beyer, C. Jones, J. Petoff, N. R. Murphy [Электронный ресурс]. — O’Reilly Media, 2016. — URL: https://sre.google/sre-book/monitoring-distributed-systems/ (дата обращения: 07.06.2026).
3. Fielding R., Nottingham M., Reschke J. HTTP Semantics: RFC 9110 [Электронный ресурс]. — IETF, 2022. — URL: https://www.rfc-editor.org/rfc/rfc9110 (дата обращения: 10.06.2026).
4. Fowler M., Lewis J. Microservices [Электронный ресурс]. — 2014. — URL: https://martinfowler.com/articles/microservices.html (дата обращения: 07.06.2026).
5. Introduction | Apache Kafka Documentation [Электронный ресурс]. — Apache Software Foundation. — URL: https://kafka.apache.org/documentation/ (дата обращения: 14.06.2026).
6. OWASP Cheat Sheet Series. Transport Layer Security Cheat Sheet [Электронный ресурс]. — URL: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html (дата обращения: 10.06.2026).
7. PostgreSQL Documentation. JSON Types [Электронный ресурс]. — The PostgreSQL Global Development Group. — URL: https://www.postgresql.org/docs/current/datatype-json.html (дата обращения: 14.06.2026).
8. Rescorla E. The Transport Layer Security (TLS) Protocol Version 1.3: RFC 8446 [Электронный ресурс]. — IETF, 2018. — URL: https://www.rfc-editor.org/rfc/rfc8446 (дата обращения: 10.06.2026).
9. Waseem M., Liang P., Shahin M., Di Salle A., Márquez G. Design, Monitoring, and Testing of Microservices Systems: The Practitioners’ Perspective [Электронный ресурс]. — 2021. — URL: https://arxiv.org/abs/2108.03384 (дата обращения: 04.06.2026).