Современные высоконагруженные системы, работающие в условиях облачной инфраструктуры, требуют соответствия ряду подходов, принципов и методов обеспечения доступа, контроля и сопровождения ПО. Большинство этих систем работают на основе атомарных процессов, событийных моделей и межсервисного взаимодействия. Одной из таких систем является разработанная аукционная платформа — система, позволяющая множеству рекламодателей достигать целевой аудитории с минимальными затратами на продвижение бренда. Она должна не только поддерживать аукцион в режиме реального времени, но и обеспечивать пользователям своевременный и полный доступ.
В основе системы лежит микросервисная архитектура, включающая в себя несколько компонентов, каждый из которых выполняет свою бизнес-задачу. Независимые сервисы позволяют четко разграничивать ответственность: управление пользователями, управление сессиями пользователей, проведение аукционов, управление основным контентом и управление самой системой. Любой микросервисный подход минимизирует взаимные зависимости, но требует поддержания согласованности данных. Такой стиль называется Domain Driven Design или же предметно-ориентированное проектирование. Его основная цель — создать небольшие системы, которые легко и удобно поддерживать и дорабатывать. Доработка по новым требованиям проходит в определенной системе, которая взаимодействует с тем или иным доменом.
Важно отметить, что при проектировании отдельного элемента микросервисной архитектуры можно применять сразу несколько подходов и стилей. Реализация гибридной архитектуры позволяет взаимодействовать с системой разными способами: выполнять синхронные запросы для критичных операций и асинхронные согласно Event-Driven Architecture (событийно-ориентированную архитектуру). Асинхронность взаимодействия обеспечивает не только слабую зависимость компонентов, но и высокую масштабируемость. Основным инструментом такого подхода являются брокеры сообщений или использование единой шины событий. Apache Kafka, например, успела стать стандартом асинхронной передачи данных между сервисами практически во всех крупных IT компаниях. Система предоставляет возможность отправить событие в общий канал, на которое потребители реагируют в удобное для них время. Наглядным примером реализации такого стиля является система уведомлений. Производители событий из разных систем публикуют их в общую шину, откуда один сервис-потребитель трансформирует их в уведомления для конечного пользователя. Таким образом реализована нотификация о грядущих аукционах или перебитой ставке: события из двух разных источников обрабатываются единым компонентом, ответственным за информирование получателей.
Своевременный и оправданный выбор интернет-протокола для передачи данных играет одну из ведущих ролей при расчете максимальной пропускной способности системы на поздних этапах [1]. Почти все межсервисное взаимодействие в системе аукциона реализовано на основе протокола HTTP/2. Поддержка одного соединения, способного обрабатывать множество параллельных запросов, сжатие заголовков, передача данных в бинарном формате — всего лишь вершина айсберга возможностей протокола второй версии. Внедрение HTTP/2 ускорило большинство операций в разы по сравнению с теми же операциями на HTTP/1.1. Невозможно отрицать, что HTTP/1.1 имеет ряд преимуществ даже перед обновленной версией протокола. Так, например, версия 1.1 используется в системе для пользовательского взаимодействия с частью представления. Все внешние эндпоинты системы разработаны согласно подходу REST API. Данный подход подразумевает использование HTTP-команд, таких как GET, POST, PUT и DELETE. Серверная часть, в свою очередь, преобразует данные из пользовательского запроса в Protobuf и использует для дальнейшего взаимодействия между микросервисами. Выбор такого подхода обусловлен необходимостью разделить трафик, оптимизировав взаимодействие на каждом уровне — мультиплексирование HTTP/2 работает намного лучше по долгоживущему соединению, чем по коротким пользовательским запросам. Процесс аукциона требует достаточной скорости для передачи актуальной информации в режиме реального времени. На помощь приходит простой и изящный WebSocket. Протокол предоставляет двунаправленное постоянное соединение между клиентом и сервером поверх TCP, что позволяет передавать запросы на сервер или статус новой ставки для пользователя быстро, гарантированно и в правильном порядке.
Одним из важных подходов является идемпотентность. Данный подход означает обязательное соответствие требованию, при котором любой пользовательский запрос выполняется единожды и не оказывает дополнительного влияния при повторном случайном вызове. В системе аукциона это играет огромную роль. Любое двойное нажатие кнопки, обновление страницы, потери пакетов не должны нарушать логику торгов и создавать неконсистентность данных.
В контексте разработки распределенных облачных инфраструктур, Kubernetes рассматривается как эталонное и наиболее распространённое решение для оркестрации контейнеризированных приложений. Она способна автоматизировать их развертывание, масштабирование, управление ресурсами и сетевыми политиками. Платформа с открытым исходным кодом умеет объединять несколько распределенных серверов в единый вычислительный кластер, абстрагируя разработчиков от конкретного оборудования, предоставляя элементарный уровень работы с контейнеризорованными приложениями.
В контексте высоконагруженных приложений, k8s предоставляет множество различных инструментов для масштабирования. Горизонтальное масштабирование системы достигается через механизм автоскейлинга. Платформа отслеживает метрики приложений и использования серверных ресурсов. При достижении пиковых нагрузок, Kubernetes увеличивает число реплик приложения для распределения трафика, а при его снижении — уменьшает реплики. Такой подход отлично экономит ресурсы кластера, что, в свою очередь, сказывается на экономической составляющей при расчете стоимости работы системы. Так, например, в системе аукциона происходит работа компонента API Gateway. Сервис является ключевой точкой взаимодействия пользователя и всей системы. Любой запрос и ответ обязательно проходит через Gateway, валидирующий запросы и распределяющий нагрузку на остальные компоненты системы корректно. При увеличении трафика, Kubernetes автоматически разворачивает дополнительные копии сервиса и снижает нагрузку на каждую активную реплику. Важно отметить, что микросервисный подход в такой ситуации демонстрирует свое главное преимущество перед монолитным — независимость компонентов. Когда одному из компонентов требуется больше ресурсов для обработки потока данных, остальные могут спокойно работать при тех же условиях. Монолитный подход неизбежно требует увеличение общих вычислительных ресурсов, что сказывается на конечной стоимости обслуживания ПО.
Критичным аспектом проектирования системы является обеспечение её отказоустойчивости. В условиях распределенной инфраструктуры отказы бывают не только у программного обеспечения, но и у физического оборудования. Повреждение дисков, отключение питания, недоступность сети — всё это приводит к остановке работоспособности системы. Именно поэтому механизм репликации данных становится обязательным элементом архитектуры любых систем. В привычных конфигурациях СУБД широко используется подход primary — replica, при котором один узел обрабатывает все операции, а второй поддерживает идентичное состояние данных. Репликация бывает синхронной и асинхронной. При синхронной записи мастер ожидает подтверждения операции от реплики, а асинхронный подход предлагает ускоренный режим работы с небольшим отставанием данных от мастера. В аукционной системе реализован смешанный подход, при котором одновременно существует три копии одной базы данных: primary — replica — asyncreplica. Такая особенность репликации позволяет распределить нагрузку на одну базу данных без необходимости частого масштабирования. Данные записываются в основную базу, а вычитываются из синхронной реплики. При этом, отказ любого из компонентов минимизирует потери данных и обеспечивает максимальную стабильность.
Современные высоконагруженные системы перестали быть лишь чистым, читаемым и масштабируемым кодом. Структурный подход к проектированию информационных систем, с использованием большого спектра архитектурных подходов и инфраструктурных инструментов, позволяет обеспечивать стабильность и эффективность работы продуктов.
Литература:
1. Клепман, М. Высоконагруженные приложения. Программирование, масштабирование, поддержка / Мартин Клеппман. — Астана: Спринт Бук, 2025.
