Конспект

Архитектуры приложений: монолитная, сервис-ориентированная и микросервисная

Ключевые тезисы

• Монолитная архитектура — всё в одном блоке: проще в разработке и деплое, но сложнее в поддержке и масштабировании.
• Сервис-ориентированная архитектура (SOA) — система из независимых, переиспользуемых сервисов, общающихся через шину данных.
• Микросервисная архитектура — эволюция SOA: небольшие независимые сервисы, часто со своими БД, общающиеся напрямую или через API-шлюз.
• Выбор архитектуры определяется на этапе проектирования исходя из требований проекта, бюджета и планов на масштабирование.

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

Монолитная архитектура — это подход, при котором все компоненты системы (frontend, backend, бизнес-логика) объединены в единую кодовую базу и единый блок развёртывания.

Виды монолитов:

• Классический: Frontend и backend не разделены.
• Современный: Frontend (веб-приложение, мобильное приложение) отделён и взаимодействует с монолитным backend через API.

Преимущества:

• Простота реализации и деплоя (одно приложение).
• Упрощённое сквозное тестирование.
• Высокая производительность (все вызовы внутри одного процесса).

Недостатки:

• Большая, сложная кодовая база.
• Риск появления ошибок в несвязанных частях при изменении кода.
• Сложность масштабирования.

Роль аналитика:

• В классическом монолите — описание поведения экранов.
• В современном — дополнительно описание API-вызовов и разделение задач на frontend и backend.

Клиент-серверная архитектура

Способ организации ПО, при котором система делится на две части:

• Клиент — запрашивает данные (веб-приложение, мобильное приложение).
• Сервер — формирует и отправляет ответ.

Важный принцип: Использование тонкого клиента, где на клиенте выполняется минимум логики и проверок, а основная обработка происходит на сервере. Задачи для клиента и сервера должны чётко разделяться.

Сервис-ориентированная архитектура (SOA)

Подход, при котором приложение разбивается на независимые сервисы, которые можно повторно использовать в разных проектах.

Ключевые характеристики:

• Автономность: Каждый сервис работает независимо.
• Переиспользуемость: Сервисы имеют достаточную функциональность для использования в разных бизнес-процессах.
• Стандартизированные контракты: Чётко определённые интерфейсы взаимодействия.
• Интероперабельность: Возможность взаимодействия сервисов, написанных на разных технологиях.

Центральный элемент — шина данных (Enterprise Service Bus, ESB):

• Служит единой точкой входа для маршрутизации запросов.
• Агрегирует и трансформирует данные (например, из JSON в XML).
• Управляет бизнес-процессами (оркестрация).
• Недостатки ESB: Может стать "бутылочным горлышком" и точкой отказа; часто проприетарные решения, требующие специфических знаний.

Преимущества SOA:

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

Недостатки SOA:

• Сложность реализации и управления шиной данных.
• Трудность управления большим количеством сервисов.

Роль аналитика: Детальное описание межсервисных взаимодействий, трансформации данных, определение, в какой сервис добавлять новую функциональность, анализ последствий недоступности сервисов.

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

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

Основные шаблоны (паттерны):

• API-шлюз: Единая точка входа для клиентов. Занимается маршрутизацией, проверкой запросов, кэшированием.
• Хореография: Сервисы общаются асинхронно через брокер сообщений (например, Kafka, RabbitMQ). Сервис публикует событие, а другие сервисы, подписанные на него, реагируют.
• Оркестрация: Выделенный сервис-оркестратор управляет бизнес-процессом, явно вызывая другие сервисы.
• Backend for Frontend (BFF): Создание отдельного backend-сервиса под конкретный тип клиента (например, под мобильное приложение) для оптимизации данных и форматов ответа.
• Реестр сервисов: Сервис, который отслеживает состояние, доступность и расположение всех микросервисов.

Преимущества:

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

Недостатки:

• Сложность деплоя и оркестрации множества сервисов.
• Сложность сквозного тестирования.
• Потенциальное дублирование данных в разных хранилищах.
• Проблемы безопасности и производительности из-за большого количества сетевых вызовов.

Сравнение SOA и микросервисной архитектуры

Выбор архитектуры

• Монолит: Небольшие проекты без планов масштабирования, нуждающиеся в быстром запуске. Иногда используется принцип Monolith First для старта MVP с последующим переходом на другую архитектуру.
• SOA: Сейчас применяется реже из-за сложности. Может быть оправдана для очень крупных корпоративных систем.
• Микросервисы: Современный стандарт для сложных, высоконагруженных и масштабируемых приложений. Выбор зависит от готовности команды к сложностям операционной поддержки.

Выводы
Каждая архитектура имеет свои сильные и слабые стороны. Монолит — простота, SOA — переиспользование в масштабах предприятия, микросервисы — гибкость и отказоустойчивость. Решение должно приниматься на основе конкретных бизнес-требований, бюджета и экспертизы команды.