Композитная архитектура — развитие идеи микросервисов

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

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

В целом, композитная архитектура похожа на классическую микросервисную, разницу разберём ниже.

Композит, в отличие от монолита, позволяет использовать систему как конструктор.

Разница между композитом и микросервисами

Микросервисная архитектура

Архитектурный стиль, в котором приложение разбито на независимые сервисы, каждый со своей логикой, базой данных (или схемой), API и жизненным циклом. Основные признаки:

• Сервисы полностью изолированы.
• Общение — через API (обычно HTTP/gRPC/очереди).
• Каждый сервис можно разворачивать, масштабировать и обновлять отдельно.
• Высокая операционная сложность: сервис-меш, мониторинг, трассировка, CI/CD для десятков модулей.

Композитная архитектура

Это более крупнозернистая архитектура, объединяющая несколько модулей/компонентов в единый развертываемый продукт.

• Модули логически разделены, но физически — в одном процессe/репозитории/приложении.
• Коммуникации внутренние (функциональные вызовы), без сетевой латентности.
• Развертывание и масштабирование — единое.
• Сложность ниже, чем у микросервисов, но дисциплина модульности должна быть строгой.

Основная разница

Разница — в степени разбиения и операционных последствиях.

• Микросервисы — модульность + независимое развертывание + независимые окружения + распределённость (сеть).
• Композитная архитектура — модульность без распределённости; независимость логическая, а не операционная.

Когда что выбирают:

• Композитная архитектура — когда нужна ясная модульность, но инфраструктура не готова к эксплуатации распределённой системы.
• Микросервисы — когда бизнес-домены сильно автономны и критична независимость команд и релизов.

Если кратко:
Композитная архитектура = модульная монолитная система.
Микросервисы = распределённая модульная система.

Ну вы поняли, разница в нюансах, но она есть.

Техническая реализация композитной архитектуры

В общем, каждый компонент композитной архитектуры отвечает за свой кусок бизнес-логики и достаточно автономен.

Взаимодействие компонентов происходит через API и механизмы обмена событиями, формируя коммуникационную инфраструктуру. Для прямых запросов и ответов используют синхронные протоколы (REST, gRPC, GraphQL). Когда нужна гибкость и устойчивость, прибегают к асинхронной связи через брокеры сообщений (Kafka, RabbitMQ).

Как работают API-шлюзы: 

• направляют входящие запросы к подходящим сервисам;
• обеспечивают безопасность (контроль доступа, аутентификация, TLS-шифрование);
• преобразуют и объединяют данные из нескольких источников;
• ограничивают частоту запросов (rate limiting);
• кешируют ответы и предоставляют метрики для анализа работы системы.

Headless-подход предписывает разделение backend (бизнес-логики, данных и API) и frontend (любой пользовательский интерфейс). Это позволяет независимо развивать интерфейсы и бэкенд, используя универсальные форматы данных (JSON, Protobuf) для совместимости. Один бэкенд может обслуживать в такой системе разные клиенты: веб, мобилки.

Событийно-ориентированная архитектура (EDA) увеличивает гибкость и слабую связанность системы. Сервисы создают события, например, «Пользователь зарегистрирован», и отправляют их в центральный брокер (Kafka, RabbitMQ). Другие сервисы, которые подписаны на эти события, получают их и выполняют свои задачи, например, отправляют приветственное письмо.

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

В целом, такие же, как в микросервисной архитектуре.

Гибкость

Можно тестировать и внедрять новые функции и процессы с минимальными рисками для всей системы. Вы легко можете добавить, например, к своему интернет-магазину ИИ-консультанта.

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

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

Отпадает необходимость каждый раз создавать с нуля однотипные функции (платежи, уведомления, аналитику). Компания формирует библиотеку готовых решений, ускоряя разработку, новых продуктов.

Свобода выбора инструментов для разработчиков

Модули могут быть написаны, буквально на чём угодно.

Оптимизация бюджета

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

Недостатки композитной архитектуры 

Высокие требования к квалификации архитектора

Композит сложно нормально спроектировать. Неправильное разбиение ведёт к «распределённому монолиту»: плохо организованным модулям, сочетающим недостатки монолита и сложности распределённой системы. Это происходит, если:

• модули слишком мелкие (вы выносите в микросервис то, что можно сделать функцией или модулем);
• границы между компонентами размыты (сервисы постоянно обращаются друг к другу, создавая запутанные зависимости);
• нет чёткой доменной модели (сервисы дублируют логику или данные).

Высокие требования к службе эксплуатации

Композитная система требует дополнительных инструментов и опыта:

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

Высокие требования к ИБ

Каждый API может стать точкой входа для атаки. Основные проблемы:

• Больше целей атаки: злоумышленник может попытаться взломать не только внешний API, но и внутренние сервисы.
• Нужно контролировать права для сотен микросервисов.
• Согласованность политик: если в одном сервисе включено шифрование, а в другом нет — это создаёт риски.

Нужен комплексный подход: Service Mesh-и для управления безопасностью на уровне сети, API-шлюзы для защиты периметра и централизованные системы управления идентификацией и доступом (IAM).

Когда стоит выбирать композитную архитектуру

• Если планируется делать что-то крупное и долгоживущее (SaaS, корпоративных платформ).
• Когда среда и бизнес постоянно меняется и надо адаптироваться.
• Если есть необходимость большого количества интеграций (платежами, аналитикой).
• Когда у вас большое количество удалёнщиков в распределённой команде разработки.

Заключение

Архитектура — тема сложная, это отдельная профессия. Не жалейте деньги на архитектора-профессионала, который разберётся, нужна ли вам композитная архитектура или подойдут микросервисы.

Но основные нюансы вы из этой статьи поняли.