Михайлов Б.А., Клюковкин Г.К. Построение высоконагруженной микросервисной архитектуры в условиях миллионов запросов в секунду // Вестник Науки и Творчества. 2024. № 6(97). С. 8-15.

Статья: Михайлов, Клюковкин 2024-06.pdf

Полный выпуск: Вестник Науки и Творчества. Выпуск №6 (2024).pdf

ПОСТРОЕНИЕ ВЫСОКОНАГРУЖЕННОЙ

МИКРОСЕРВИСНОЙ АРХИТЕКТУРЫ

В УСЛОВИЯХ МИЛЛИОНОВ

ЗАПРОСОВ В СЕКУНДУ

Михайлов Богдан Александрович,

ведущий инженер-программист,

профиль-разработчик,

Компания VK, г. Москва

Клюковкин Георгий Константинович,

ведущий инженер-программист,

RingCentral, г. Санкт-Петербург

E-mail: kliukovkin@gmail.com

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

Ключевые слова: микросервисы, масштабирование, отказоустойчивость, высоконагруженные системы, API Gateway, gRPC, event-driven architecture, Kubernetes, Service Mesh, serverless, WebAssembly, CAP-теорема.

Актуальность исследования

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

Простейший и популярный вариант архитектуры – монолитная. Каждый начинал с неё, и здесь нет никакой изоляции и распределённости: один монолит обрабатывает все запросы [3]. Однако, традиционные монолитные архитектуры оказываются неспособны эффективно справляться с подобными нагрузками: возрастает время отклика, снижается устойчивость системы к отказам, усложняется внесение изменений. В ответ на эти вызовы всё большее распространение получает микросервисная архитектура, которая позволяет разрабатывать, масштабировать и обновлять отдельные компоненты системы независимо друг от друга.

Реальные кейсы, такие как опыт компании iFood (обработка более 30 000 запросов в секунду на отдельный микросервис), Netflix или Amazon, демонстрируют эффективность микросервисного подхода при экстремальных нагрузках. При этом особое внимание уделяется таким аспектам, как асинхронные коммуникации, кэширование, использование брокеров сообщений, автоматическое масштабирование и мониторинг в режиме реального времени.

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

Цель исследования

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

Материалы и методы исследования

Материалы исследования включают публичные технические отчёты, научные статьи, документацию к архитектурам, а также практические кейсы и метрики, опубликованные в открытом доступе.

Использовались методы сравнительного анализа архитектурных подходов, теоретическая интерпретация CAP- и PACELC-теорем, контент-анализ технической документации.

Результаты исследования

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

Микросервисная архитектура представляет собой систему распределённых, слабо связанных компонентов, каждый из которых выполняет чётко определённую бизнес-функцию. Микросервисы – это «набор независимо развёртываемых сервисов, общающихся по лёгким протоколам». Изображения демонстрируют ключевую схему: клиенты (веб, мобильные, IoT) обращаются к API-шлюзу, который маршрутизирует запросы к специализированным сервисам с собственными базами данных (рисунок 1).

Рис. 1 Архитектура микросервисного взаимодействия

через API-шлюз с использованием

различных протоколов

При проектировании микросервисов важно учитывать паттерн «База данных на сервис» (Database per service): каждый сервис владеет своей БД и не имеет прямого доступа к чужим данным, что обеспечивает слабую связанность и независимое масштабирование [4].

Теоретической основой распределённых систем, к которым относят и микросервисы, является теорема CAP – фундаментальный результат Эрика Брюэра: система может гарантировать одновременно только две из трёх характеристик: согласованность, доступность и устойчивость к разделению сети. Это означает, что при проектировании сервисов приходится сознательно выбирать компромиссы: CP (согласованность + устойчивость) или AP (доступность + устойчивость), особенно при сетевых сбоях. Ещё более полный взгляд предлагает теорема PACELC, учитывающая задержки даже без разделений.

Микросервисная архитектура опирается на модульность и слабую связанность, что обеспечивает:

– горизонтальное масштабирование отдельных сервисов при росте нагрузки,

– изоляцию ошибок: отказ одного сервиса не влечёт провал всего приложения,

– технологическую разнородность: каждый сервис может использовать оптимальный стек (например, Java, Node.js, Python).

В таблице 1 представлены ключевые преимущества и недостатки микросервисов, подтверждённые научными источниками и статьями.

Таблица 1

Преимущества и недостатки микросервисной архитектуры

Ключевые паттерны микросервисной архитектуры – это API-шлюз (единственная точка входа), сервис-дискавери, асинхронная коммуникация (через очереди сообщений), а также стратегическое разделение сервисов по bounded contexts (DDD). DDD предлагает решение данного типа задач с помощью так называемых моделей чтения (Read Model). В рамки концепции укладывается получение сводных, расчётных (то есть, полученных путём композиции, вычисления и/или проекции других сущностей) моделей из хранилища данных, используя, в том числе, заранее разработанные выражения на языке запросов этого хранилища [1, с. 149].

Высоконагруженные приложения требуют баланс между stateless и stateful подходами. Stateless‑сервисы легко масштабировать горизонтально: их можно клонировать за балансером нагрузки, назначать короткие «жизненные» контейнеры и быстро распределять на кластере. Stateful‑сервисы требуют сложных схем сессий, репликации данных и согласованных механизмов автоскейлинга, как описано в ряде исследований.

На рисунке 2 представлено разделение между stateless- и stateful-компонентами: stateless‑сервисы без состояния масштабируются просто клонированием, а stateful‑сервисы используют Persistent Volume Claims и StatefulSet в Kubernetes для сохранения состояния. Это отражает принципы статистических и устойчивых компонентов в облачной среде.

Рис. 2 Сравнение Stateless- и Stateful-микросервисов

по архитектуре хранения и обработки данных

Модель Масштабирования по кубу (Scale cube) предлагает три направления роста: X‑ось (клонирование), Y‑ось (разделение по функциям), Z‑ось (разбиение данных). Подход X‑оси соответствует stateless‑масштабированию, Y‑ось – микросервисному декомпозированию, Z‑ось – шардированию stateful‑данных.

Выбор коммуникационных протоколов напрямую влияет на производительность. Исследования показывают, что gRPC (HTTP/2 + Protocol Buffers) обеспечивает до 25-30 % выше пропускной способности по сравнению с REST. Глубокий анализ benchmark‑тестов подтверждает, что gRPC примерно в 7-10 раз быстрее REST при средних payload‑размерах.

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

Таблица 2

Сравнительная характеристика протоколов

REST, gRPC и GraphQL в микросервисной архитектуре

Обработка миллионов запросов в секунду требует от архитектуры микросервисной системы высокой гибкости и горизонтального масштабирования.

Стратегии масштабирования при нагрузке в миллионы запросов/сек представлены в таблице 3.

Таблица 3

Стратегии масштабирования при нагрузке в миллионы запросов/сек

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

Одним из наиболее распространённых шаблонов является Circuit Breaker. Согласно определению, этот шаблон отслеживает частоту неудачных запросов к downstream‑сервисам, и, при превышении порога, «размыкает цепь» – блокирует дальнейшие запросы в течение определённого времени, тем самым предотвращая каскадные падения всего потока запросов. Клиент получает ошибку сразу, вместо ожидания таймаута.

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

Кроме паттернов, высокую доступность обеспечивают HA‑кластеризация – активные реплики микросервисов, сбалансированные через health-check‑балансеры и автоматический failover. Kubernetes выступает как фреймворк для восстановления и автоскейлинга контейнеров, но исследования показывают, что у stateful-сервисов встроенные механизмы могут не соответствовать 5‑9 стандартам доступности, и требуют расширения через custom HA‑контроллеры для репликации и восстановления stateful‑данных.

Архитектура high availability строится вокруг принципов: Redundancy + Health Checking + Fast Failover + Graceful Degradation. В крупных системах (Amazon, Netflix) используется и клеточная модель: целые копии наборов сервисов функционируют параллельно в разных зонах, обеспечивая изоляцию и распределённость отказоустойчивости.

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

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

Серьёзной проблемой является отсутствие отказоустойчивых паттернов (circuit breaker, retry, timeout, bulkhead), что делает систему уязвимой к каскадным сбоям. Также часто недооцениваются нагрузочные пики: без эффективного автоскейлинга и throttling-систем система может выйти из строя.

Другой типовой промах – недостаточное логирование и мониторинг. Без трассировки запросов и метрик (например, через Prometheus, Grafana, Jaeger) затрудняется диагностика ошибок и SLA не выдерживаются.

Кроме того, избыточное количество сервисов может привести к «микросервисному аду» (microservice hell), когда управление зависимостями, версиями и CI/CD становится непомерно сложным.

В ближайшие годы развитие высоконагруженных микросервисных систем будет происходить в направлении большей автономности, адаптивности и самооптимизации инфраструктуры. Одним из ключевых векторов является внедрение интеллектуальных механизмов масштабирования, основанных на машинном обучении. В отличие от традиционного HPA (Horizontal Pod Autoscaler), ML-модели предсказывают будущие пики нагрузки по данным мониторинга и метрикам поведения пользователей, позволяя заранее поднимать нужные экземпляры сервисов и снижать время реакции.

Развитие также идёт в сторону serverless-микросервисов, где отдельные функции развёртываются без постоянных контейнеров и активируются только по запросу. Платформы вроде AWS Lambda, Azure Functions и Google Cloud Run позволяют сочетать микросервисную логику с платёжной моделью pay-per-use, существенно снижая стоимость поддержки инфраструктуры в неактивное время.

Важным трендом является переход к событийно-ориентированной архитектуре (Event-Driven Architecture, EDA) с использованием брокеров Kafka, NATS, RabbitMQ. Такой подход позволяет снизить связанность между сервисами, масштабировать их независимо и обрабатывать события асинхронно. Он активно используется в крупных системах реального времени: Uber, Netflix, LinkedIn.

Растёт интерес к использованию WebAssembly (WASM) как среды выполнения микросервисов. WASM позволяет запускать безопасный, изолированный код с низкой латентностью в различных средах – от браузера до edge-устройств. В сочетании с проектами вроде wasmCloud и Fermyon это даёт возможность построения лёгких, быстро масштабируемых микросервисов нового поколения.

Кроме того, развивается концепция Service Mesh 2.0. Традиционные решения (Istio, Linkerd) обеспечивают шифрование, трассировку, балансировку. Новые подходы (например, Ambient Mesh от Istio) делают это с меньшим overhead, упрощают развёртывание и уменьшают потребление ресурсов.

Ещё одна перспективная технология – sidecarless-архитектура, где функции прокси и мониторинга не внедряются в каждый под, а реализуются на уровне узла или ядра ОС (например, через eBPF). Это снижает накладные расходы и улучшает безопасность.

Выводы

Микросервисная архитектура продемонстрировала высокую эффективность в условиях экстремальной нагрузки благодаря своей модульности, масштабируемости и изоляции компонентов. Эффективное проектирование таких систем требует баланса между stateless и stateful подходами, выбора высокопроизводительных коммуникационных протоколов (например, gRPC), применения стратегий масштабирования по модели Scale Cube и надёжных отказоустойчивых паттернов. Использование современных инструментов мониторинга, автоскейлинга и архитектур высокой доступности (HA-кластеризация, Service Mesh, event-driven-модели) позволяет достичь SLA на уровне 99,99% и выше.

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

Литература:

1. Абрамов Д.В. Особенности применения принципов предметно-ориентированного проектирования и разделения команд и запросов в микросервисной архитектуре высоконагруженных систем // Энергетика в современном мире: VIII Международная заочная научно-практическая конференция. – 2017. – С. 148-156.

2. Городничев М.Г., Полонский Р.В. Оценка возможности использования микросервисной архитектуры при разработке пользовательских интерфейсов клиент-серверного программного обеспечения // Экономика и качество систем связи. – 2020. – № 3(17). – С. 33-43.

3. По стопам лучших: микросервисная архитектура в разрезе [Электронный ресурс]. – Режим доступа: https://proglib.io/p/po-stopam-luchshih-mikroservisnaya-arhitektura-v-razreze-2019-11-07.

4. Pattern: Database per service [Электронный ресурс]. – Режим доступа: https://microservices.io/patterns/data/database-per-service.html.