Введение . Актуальность микросервисного подхода в современных облачных системах обусловлена необходимостью обеспечения высокой масштабируемости и гибкости разработки [2]. Таким образом, при проектировании распределенных систем возникает проблема выбора между синхронным REST-взаимодействием и асинхронным событийно-ориентированным подходом. Традиционный REST характеризуется простотой реализации, но несет риски высокой связанности компонентов и возникновения каскадных отказов. В свою очередь, событийно-ориентированные архитектуры предлагают слабую связанность и временную развязку, обладая при этом значительными накладными расходами на сериализацию данных и управление очередями.

Проблема выбора усугубляется спецификой облачных сред: например, в публичных облаках интеграционные таймауты и задержки «холодного старта» создают дополнительные риски, что делает необходимым проведение тестов в контролируемой среде Kubernetes. Научная новизна данной работы заключается в разработке методики объективного сопоставления моделей на базе единой бизнес-логики с использованием показателя end-to-end latency. Данный подход позволяет учесть полное время выполнения операции, включая фоновые процессы в очередях, что невозможно при простом измерении времени отклика API.

Теоретическая база и показатели производительности . Теоретический фундамент оценки производительности в данном исследовании базируется на методологических работах И. В. Артамонова [1]. Под производительностью микросервисной системы понимается набор показателей эффективности, рассматриваемых в рамках заданных временных ограничений. Согласно исследованию, метрики классифицируются на четыре иерархические группы:

1. Время: время выполнения задачи, пропускная способность, время ожидания в очереди.
2. Количество: длина очереди и количество задач, находящихся в обработке.
3. Механизмы: уровень простоя и эффективность использования вычислительных ресурсов.
4. Нормативность: уровень производительности — вероятность того, что система обеспечит заданный уровень качества, и нормативность производительности.

Методология предполагает установление допустимых границ для каждого показателя. Выход за эти пределы интерпретируется как «предельное событие», способное привести к опасному состоянию или полному отказу системы.

Методология исследования и архитектура стенда . Эксперимент проведен в кластере Kubernetes на специализированном стенде в облачной среде.

Стек технологий:

— прикладной уровень: FastAPI (Python), выбранный благодаря его асинхронной природе и высокой пропускной способности, подтвержденной в бенчмарках [3];

— слой данных и сообщений: PostgreSQL и RabbitMQ;

— генератор нагрузки: фреймворк Locust;

Система моделирует цепочку обработки заказа через четыре сервиса: API Gateway, Order, Inventory и Payment. В REST-режиме Order Service последовательно вызывает Inventory и Payment через HTTP-запросы. В Event-режиме Order Service публикует событие order.created в RabbitMQ, которое асинхронно обрабатывается остальными сервисами.

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

Сценарии тестирования включают в себя базовую нагрузку (stable), пиковый рост RPS (spike), конкуренцию за ресурсы (degradation) и наличие бизнес-ошибок (fault).

Результаты экспериментального исследования . Количественные результаты сравнительного тестирования представлены в таблице 1.

Таблица 1

Сравнительные показатели производительности REST и Event-driven систем

В базовом сценарии (A1/A2) REST-архитектура оказалась в 2,1 раза эффективнее Event-режима (61,20 мс против 132,21 мс). В сценарии S1 spike наблюдается десятикратный разрыв в задержке: end-to-end p95 для Event-driven модели возрастает до 935,57 мс. Применение метрик групп «Queue» и «Equipment», согласно Артамонову, объясняет этот эффект: при пиковой нагрузке стоимость управления очередями в RabbitMQ и накладные расходы на сериализацию перевешивают выгоды от асинхронности, приводя к накоплению задач в обработке и деградации пропускной способности. В сценарии D1 degradation Event-система продемонстрировала неспособность соблюсти стандарты нормативности, выдав 5328 ошибок из-за исчерпания ресурсов брокера.

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

Анализ полученных результатов опровергает гипотезу о безусловном преимуществе Event-driven архитектур при высоких нагрузках. Для коротких цепочек сервисов накладные расходы брокера и задержки, вносимые опросом статуса, делают асинхронную модель менее эффективной. Преимущество REST внутри кластера обусловлено меньшим количеством посредников и отсутствием «буферного» оверхеда.

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

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

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

Литература:

1. Артамонов, И. В. Показатели производительности микросервисных систем / И. В. Артамонов. — Текст: непосредственный // Вестник НГИЭИ. — 2018. — № 8 (87). — С. 24–33.
2. Чикалева, Ю. С. Анализ гранулярности микросервисов: эффективность архитектурных подходов / Ю. С. Чикалева. — Текст: непосредственный // Программные системы и вычислительные методы. — 2025. — № 2.
3. Салтанов, Д. С. Сравнительный анализ архитектурных подходов к разработке REST API для высоконагруженных систем / Д. С. Салтанов, Н. В. Арсентьева. — Текст: непосредственный // Форум молодых ученых. — 2025. — № 6 (106).