Актуальность исследования
Актуальность исследования обусловлена ростом объёмов данных, обрабатываемых современными веб-приложениями, а также необходимостью обеспечивать их высокую производительность, масштабируемость и надёжность. Одним из распространённых подходов к решению этих задач является микросервисная архитектура, основанная на разделении приложения на самостоятельные и независимо развёртываемые сервисы.
При этом применение микросервисов связано с усложнением взаимодействия компонентов, обеспечением согласованности данных, обработкой сбоев и сопровождением системы. Различные концепции построения микросервисной архитектуры имеют собственные преимущества и ограничения, поэтому их выбор должен учитывать характер нагрузки, требования к времени отклика, отказоустойчивости и масштабируемости.
Таким образом, сравнительный анализ архитектурных концепций необходим для обоснованного выбора решения, наиболее подходящего для создания веб-приложений, предназначенных для обработки больших массивов данных.
Цель исследования
Целью данного исследования является сравнительный анализ основных концепций построения микросервисных систем и обоснование выбора архитектурного решения для веб-приложений, предназначенных для обработки больших массивов данных, с учётом требований к производительности, масштабируемости, надёжности, работе с данными и сложности эксплуатации.
Материалы и методы исследования
Материалами исследования послужили основные концепции построения микросервисных систем: синхронное и асинхронное взаимодействие сервисов, событийно-ориентированная архитектура, разделение операций чтения и записи, хранение последовательности событий и гибридная модель.
В работе применялись методы анализа, сравнения, систематизации и обобщения. Архитектурные решения сопоставлялись по назначению, преимуществам, ограничениям и условиям применения. В качестве критериев использовались время ответа, пропускная способность, масштабируемость, доступность системы, восстановление после отказов, особенности чтения и записи данных, возможность повторной обработки, сложность развёртывания и потребление инфраструктурных ресурсов.
Результаты исследования
Микросервисная архитектура основывается на декомпозиции программной системы по функциям предметной области. Границы отдельных сервисов рекомендуется определять с учётом принципов предметно-ориентированного проектирования [3, с. 4]. В частности, каждому сервису должен соответствовать ограниченный контекст, внутри которого используется единая модель данных и бизнес-правил. Один микросервис не должен объединять несколько несвязанных моделей предметной области, поскольку это увеличивает зависимость компонентов и затрудняет их изменение.
Взаимодействие между сервисами осуществляется через заранее определённые программные интерфейсы. Для приёма внешних запросов может применяться шлюз API, который направляет обращения к нужным сервисам, ограничивает доступ и скрывает внутреннее устройство системы от клиента. При изменении интерфейсов необходимо сохранять совместимость с используемыми версиями, чтобы обновление одного сервиса не нарушало работу остальных компонентов.
Важным принципом является владение данными на уровне сервиса. Постоянные данные микросервиса должны оставаться закрытыми для прямого доступа со стороны других компонентов и предоставляться через его интерфейс [4, с. 76]. Для разных сервисов могут использоваться различные типы баз данных, соответствующие характеру выполняемых операций. Общая база данных упрощает отдельные запросы, однако усиливает зависимость сервисов от единой структуры таблиц и требует согласования изменений схемы.
Поскольку экземпляры сервисов могут запускаться, завершаться и перемещаться между вычислительными узлами, архитектуре необходим механизм их обнаружения. В Kubernetes объект Service предоставляет постоянное сетевое имя для группы экземпляров приложения и распределяет поступающий трафик между ними. Управление количеством экземпляров и их обновлением может выполняться средствами оркестрации контейнеров [10].
Работа распределённой системы контролируется с помощью журналов, метрик и трассировки запросов. Распределённая трассировка позволяет проследить прохождение одного запроса через несколько сервисов и определить участок, на котором возникла задержка или ошибка. OpenTelemetry предусматривает сбор и передачу трёх основных видов телеметрических данных: трассировок, метрик и журналов [9].
Основные элементы микросервисной архитектуры представлены в таблице 1.
Таблица 1
Основные элементы микросервисной архитектуры (разработка автора)
Элемент | Назначение |
Ограниченный контекст | Определяет границы модели предметной области и ответственности сервиса |
Программный интерфейс | Устанавливает правила обмена запросами и данными между компонентами |
Шлюз API | Принимает внешние обращения и направляет их к соответствующим сервисам |
Собственное хранилище | Обеспечивает контроль сервиса над его постоянными данными |
Обнаружение сервисов | Позволяет находить действующие экземпляры компонентов по сетевому имени |
Оркестрация | Управляет запуском, обновлением и количеством экземпляров сервисов |
Средства наблюдения | Собирают журналы, метрики и сведения о прохождении запросов |
Микросервисы могут взаимодействовать синхронно или асинхронно. При синхронной модели один сервис направляет запрос другому и ожидает ответ. Для этого применяются HTTP API и gRPC. Такая модель подходит для операций, результат которых требуется получить сразу, однако создаёт зависимость от доступности вызываемого сервиса [2, с. 83].
При асинхронном взаимодействии данные передаются через очередь или брокер сообщений (рисунок). Отправитель не ожидает немедленного ответа, поэтому сервисы могут обрабатывать операции независимо. Очередь используется для передачи задания одному обработчику, а модель публикации и подписки – для доставки события нескольким сервисам.
Рис. Асинхронное взаимодействие микросервисов через шину событий [8]
При стандартном опросе сервисы самостоятельно реагируют на события. При оркестрации порядок выполнения операций определяет отдельный управляющий компонент. Оркестрация удобна для сложных процессов с несколькими этапами, ветвлениями и повторными попытками.
CQRS предусматривает разделение операций чтения и изменения данных. Event Sourcing основан на хранении последовательности событий, изменяющих состояние системы. В гибридной архитектуре синхронные запросы могут использоваться для получения данных пользователем, а асинхронные сообщения – для длительной обработки больших массивов информации [6, с. 149].
Архитектурные решения необходимо сравнивать при одинаковой нагрузке, объёме данных и вычислительных ресурсах. Основными критериями являются производительность, масштабируемость, надёжность, работа с данными и сложность эксплуатации.
Производительность оценивается по времени ответа, пропускной способности и числу ошибок. Для анализа задержки используются значения времени отклика в процентах, показывающие время выполнения наиболее медленных запросов.
Масштабируемость определяется способностью системы сохранять требуемую производительность при увеличении нагрузки и числа экземпляров сервисов. Дополнительно учитываются загрузка процессора, расход оперативной памяти и время автоматического развертывания.
Надёжность характеризуется доступностью системы, долей успешно выполненных операций и скоростью восстановления после отказа. Для этого применяются показатели RTO – допустимое время восстановления, RPO – допустимый период потери данных.
При оценке работы с данными учитываются скорость чтения и записи, задержка обновления, сохранность сообщений и возможность повторной обработки. Эксплуатационная оценка включает сложность развёртывания, количество компонентов, потребление ресурсов и стоимость инфраструктуры.
Выбор архитектурной концепции должен основываться на совокупности показателей и требованиях конкретного веб-приложения. Наиболее производительный вариант может потреблять больше ресурсов, а более независимая система – требовать сложного управления и наблюдения.
Синхронная архитектура подходит для коротких операций, когда результат требуется пользователю сразу. Её недостатком является зависимость общего времени ответа от доступности и скорости всех участвующих сервисов.
Событийно-ориентированная архитектура более эффективна для длительной и распределённой обработки данных. Она позволяет разделить отправителей и получателей сообщений, подключать несколько обработчиков и повторно обрабатывать события. При этом необходимо учитывать порядок сообщений, повторную доставку и совместимость их форматов.
CQRS применяется в системах, где нагрузка на чтение и запись существенно различается. Разделение моделей позволяет независимо масштабировать операции, но усложняет синхронизацию данных. Event Sourcing целесообразен при необходимости сохранять полную историю изменений и восстанавливать состояние системы, однако требует управления версиями событий и проекциями.
Сравнение архитектурных решений показано в таблице 2.
Таблица 2
Сравнение архитектурных решений (разработка автора)
Решение | Основное применение | Преимущество | Ограничение |
Синхронное взаимодействие | Быстрые пользовательские запросы | Простая логика выполнения | Зависимость от доступности сервисов |
Событийная архитектура | Длительная обработка данных | Повторная обработка и независимость компонентов | Сложность управления событиями |
CQRS | Различная нагрузка на чтение и запись | Независимое масштабирование | Возможная задержка обновления данных |
Event Sourcing | Хранение истории изменений | Восстановление состояния системы | Сложность обработки событий |
Гибридная модель | Системы с разными типами операций | Сочетание нескольких подходов | Более сложное сопровождение |
Для веб-приложений, обрабатывающих большие массивы данных, наиболее обоснованным является применение гибридной событийно-ориентированной архитектуры. Такое решение подходит для систем, в которых пользователь должен быстро получить подтверждение о приёме запроса, а непосредственная обработка информации может выполняться продолжительное время [7].
Внешний программный интерфейс принимает запрос, проверяет обязательные параметры и возвращает пользователю идентификатор задания. После этого данные передаются в очередь или поток сообщений. Отдельные сервисы выполняют проверку, преобразование, расчёты и сохранение результатов. Благодаря этому сбой одного обработчика не требует повторного выполнения всей операции.
При увеличении нагрузки количество экземпляров наиболее загруженных сервисов может автоматически изменяться. Масштабирование следует применять прежде всего к компонентам, выполняющим ресурсоёмкую обработку, поскольку нагрузка на отдельные части приложения может быть неодинаковой [1, с. 17-20].
Разделение операций чтения и записи необходимо использовать только в тех сервисах, где существует значительная разница между количеством запросов на получение и изменение данных. Хранение полной последовательности событий оправдано при необходимости восстановления состояния, проведения аудита и сохранения истории изменений.
Для простых процессов может применяться децентрализованное управление, при котором каждый сервис самостоятельно реагирует на полученное событие [5, с. 9]. Если операция состоит из нескольких зависимых этапов и требует отмены ранее выполненных действий при сбое, необходимо использовать отдельный управляющий компонент, контролирующий последовательность выполнения.
Основные элементы оптимальной архитектурной концепции представлены в таблице 3.
Таблица 3
Состав оптимальной архитектурной концепции (разработка автора)
Компонент | Назначение | Условие применения |
Синхронный программный интерфейс | Приём запроса и передача пользователю идентификатора задания | Требуется быстрый ответ |
Очередь или поток сообщений | Передача заданий между сервисами | Обработка выполняется продолжительное время |
Независимые сервисы обработки | Проверка, преобразование и сохранение данных | Этапы имеют различную нагрузку |
Горизонтальное масштабирование | Изменение количества экземпляров сервисов | Объём поступающих данных изменяется |
Разделение чтения и записи | Отдельная обработка запросов и изменений | Нагрузка на чтение и запись существенно различается |
Управление последовательностью операций | Координация зависимых этапов | Процесс затрагивает несколько сервисов |
Средства наблюдения | Сбор журналов, показателей и сведений о прохождении запросов | Требуется контроль распределённой обработки |
Таким образом, гибридная событийно-ориентированная архитектура позволяет отделить быстрое взаимодействие с пользователем от длительной обработки больших массивов данных. Дополнительные архитектурные решения следует применять только в тех компонентах, где они соответствуют установленным требованиям системы.
Выводы
Проведённый анализ показал, что универсальной концепции микросервисной архитектуры, одинаково эффективной для всех видов веб-приложений, не существует. Синхронная модель целесообразна для кратких операций, требующих немедленного ответа, тогда как событийно-ориентированный подход больше соответствует длительной и распределённой обработке данных. Разделение чтения и записи оправдано при существенном различии нагрузки на соответствующие операции, а хранение последовательности событий – при необходимости сохранять историю изменений и восстанавливать состояние системы.
Для веб-приложений, обрабатывающих большие массивы данных, наиболее обоснованным является применение гибридной событийно-ориентированной архитектуры. Она позволяет отделить быстрое взаимодействие с пользователем от длительной обработки информации, независимо масштабировать наиболее загруженные сервисы и организовать повторное выполнение отдельных операций. При этом разделение чтения и записи, хранение событий и централизованное управление последовательностью действий должны применяться избирательно, в зависимости от требований конкретного компонента системы.
