По какой логике выделяют микросервисы?

Логика выделения микросервисов

Определение микросервисов

Микросервисы — это архитектурный подход, при котором приложение разбивается на несколько независимых, слабосвязанных сервисов, каждый из которых:

• Отвечает за одну бизнес-функцию
• Может разворачиваться отдельно
• Имеет собственное хранилище данных
• Взаимодействует с другими через API

Это противоположность монолиту, где всё находится в одном приложении.

Основные принципы выделения микросервисов

1. Domain-Driven Design (DDD)

Это наиболее популярный и рекомендуемый подход. Микросервисы выделяются по бизнес-доменам, а не по технологическим слоям.

Пример: интернет-магазин

Монолит (неправильно):

• Одно приложение со всеми компонентами
• Одна БД, один язык, тесная связанность

Микросервисы (правильно):

• Auth Service (управление пользователями, аутентификация)
• Catalog Service (продукты и категории)
• Orders Service (оформление и управление заказами)
• Payment Service (обработка платежей)
• Inventory Service (управление остатками)
• Notification Service (отправка уведомлений)

Критерии DDD:

• Бизнес-функция (Bounded Context) - сервис отвечает за одну область бизнеса
• Слабая связанность (Loose Coupling) - сервисы взаимодействуют только через API
• Высокая когезия (High Cohesion) - логика внутри сервиса связана и имеет смысл
• Независимость данных - каждый сервис имеет свою БД

2. Анализ на основе ответственности (Single Responsibility)

Каждый микросервис должен отвечать за одну и только одну ответственность.

Плохо (слишком много ответственности):

• UserService содержит управление пользователями, аутентификацию, авторизацию, логирование, отправку email и SMS
• Слишком много причин для изменения

Хорошо (одна ответственность):

• UserService: управление пользователями и аутентификация
• AuthService: авторизация
• NotificationService: email, SMS, push
• AuditService: логирование действий

3. Анализ потоков данных и зависимостей

Изучите, как данные движутся через систему.

Поток заказа в интернет-магазине:

• Пользователь оформляет заказ
• Orders Service проверяет продукты через Catalog Service
• Проверяет наличие через Inventory Service
• Обрабатывает платёж через Payment Service
• Зарезервирует товар через Inventory Service
• Отправляет уведомление через Notification Service

Сервисы с часто совместно изменяемой логикой должны быть в одном микросервисе. Сервисы с независимой логикой должны быть отдельными.

4. Организационная структура (Conway's Law)

Архитектура системы отражает организационную структуру компании.

Если у вас есть отдельные команды платежей, инвентаря и уведомлений, то создайте Payment Service, Inventory Service и Notification Service. Каждая команда владеет своим сервисом.

Это облегчает:

• Независимую разработку - команды не мешают друг другу
• Независимый деплой - изменения в одной команде не влияют на другие
• Ясную ответственность - знаешь, кто отвечает

5. Масштабируемость и производительность

Выделяйте сервис, если его нужно масштабировать независимо:

Высоконагруженные:

• Search Service (требует Elasticsearch, может быть 10 инстансов)
• Analytics Service (требует Kafka, можно масштабировать отдельно)

Низконагруженные:

• Notification Service (несколько инстансов достаточно)

Отдельные сервисы позволяют масштабировать независимо.

6. Частота изменений (Change Frequency)

Сервисы, которые часто меняются, должны быть отдельными от стабильных.

Частые изменения:

• Правила расчёта скидок (меняется каждый месяц)
• Алгоритм рекомендаций (постоянно улучшается)

Стабильные (меняются редко):

• Аутентификация
• Основные CRUD операции

7. Секьюрность и compliance

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

Высокая безопасность:

• Payment Service (PCI DSS compliance)
• Auth Service (GDPR для персональных данных)

Обычная безопасность:

• Catalog Service
• Recommendation Service

Это позволяет применять разные уровни контроля доступа.

Методология: Event Storming

Для выделения микросервисов используйте Event Storming — техника из DDD.

1. Выпишите все события в системе:

   • UserCreated
   • OrderPlaced
   • PaymentProcessed
   • InventoryReserved
   • NotificationSent

2. Сгруппируйте события по доменам:

   • AUTH_DOMAIN: UserCreated, UserDeleted
   • ORDERS_DOMAIN: OrderPlaced, OrderCancelled
   • PAYMENT_DOMAIN: PaymentProcessed, PaymentFailed
   • INVENTORY_DOMAIN: InventoryReserved, InventoryReleased

3. Каждый домен → отдельный микросервис

Признаки правильного выделения

Сервис хорошо выделен, если:

• Может быть развёрнут и перезагружен независимо
• Имеет свою БД (нет общего хранилища)
• Общается только через API
• Может быть переписан на другом языке без влияния на другие
• Может масштабироваться независимо
• Разные команды могут работать без синхронизации

Признаки неправильного выделения:

• Постоянно делает синхронные вызовы в другие сервисы (deadlock risk)
• Разделяет БД с другим сервисом (скрытая связанность)
• Часто обновляется вместе с другим сервисом (не независим)
• Содержит логику из разных бизнес-доменов

Антипаттерны

• Микросервисы по технологическим слоям (UI, Business-Logic, Database) - это всё ещё монолит
• Микросервисы по языкам (JavaService, NodeService) - усложняет поддержку
• Микросервис для каждой функции (100+ сервисов) - nightmare с операциями

Рекомендуемое количество

Начните с 3-7 микросервисов:

• Меньше чем 3: вероятно, это монолит
• 3-7: золотая середина
• Больше чем 7: нужна хорошая инфраструктура (Kubernetes, Service Mesh)

Практический чеклист

Перед выделением нового микросервиса задайте себе:

1. Может ли этот сервис быть развёрнут независимо?
2. Может ли у него быть своя БД?
3. Будут ли разные команды работать над этим сервисом?
4. Может ли он масштабироваться независимо?
5. Это действительно отдельный бизнес-домен?

Если на большинство вопросов ответ "нет" — оставьте в монолите или в другом сервисе.