По какому принципу нужно делить монолит на микросервисы

Принципы декомпозиции монолита на микросервисы

Разделение монолита на микросервисы — это стратегический процесс, требующий баланса между техническими преимуществами и операционными сложностями. Основной принцип можно сформулировать так: каждый микросервис должен представлять собой независимую бизнес-способность (business capability), которая может развиваться, развёртываться и масштабироваться автономно.

Ключевые критерии декомпозиции

1. Предметная область (Domain-Driven Design) Использование ограниченных контекстов (Bounded Contexts) из DDD — это наиболее естественный способ разделения. Каждый контекст соответствует конкретной бизнес-подсистеме:

// Монолит: один модуль для заказов и доставки
type OrderService struct {
    // смешанная логика
}

// Микросервисы: разделение по контекстам
type OrderService struct {} // Контекст "Управление заказами"
type DeliveryService struct {} // Контекст "Логистика и доставка"

2. Принцип единой ответственности (Single Responsibility Principle) Каждый сервис должен отвечать за одну конкретную функцию бизнес-логики. Например:

• PaymentService — обработка платежей
• NotificationService — отправка уведомлений
• InventoryService — управление складскими запасами

3. Частота изменений и независимость развёртывания Группируйте код, который изменяется вместе. Если модуль аутентификации обновляется реже, чем модуль рекомендаций, их разделение позволит развёртывать рекомендации без затрагивания безопасности системы.

Практические подходы к разделению

Горизонтальное разделение по слоям (не рекомендуется):

- Сервис базы данных
- Сервис кэширования
- Сервис очередей

Такой подход создаёт сильную связность — изменения в бизнес-логике потребуют синхронного обновления нескольких сервисов.

Вертикальное разделение по бизнес-функциям (рекомендуется):

- OrderService (управляет заказами + своя БД)
- UserService (учётные записи + своя БД)
- AnalyticsService (аналитика + своя БД)

Каждый сервис инкапсулирует свои данные и логику, что соответствует паттерну Database per Service.

Технические соображения

Границы транзакций Если две операции должны быть в одной транзакции (например, списание денег и создание заказа), их стоит оставить в одном сервисе или использовать Saga-паттерн для распределённых транзакций:

// Saga Coordinator управляет распределённой транзакцией
type OrderSaga struct {
    paymentService PaymentClient
    inventoryService InventoryClient
}

func (s *OrderSaga) CreateOrder(ctx context.Context, order Order) error {
    // Компенсирующие транзакции при ошибках
    defer s.handleCompensation(ctx, order)
    
    if err := s.inventoryService.Reserve(order); err != nil {
        return err
    }
    
    if err := s.paymentService.Charge(order); err != nil {
        return err
    }
    
    return nil
}

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

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

• Отдельный CI/CD пайплайн
• Мониторинг и логирование
• Конфигурационное управление
• Сетевые вызовы и потенциальные задержки

Поэтапная стратегия миграции

1. Выделите модули внутри монолита с чёткими интерфейсами
2. Создайте фасад для обратной совместимости
3. Перенесите модуль в отдельный сервис
4. Направляйте трафик через feature flags
5. Удалите старый код после полного перехода

// Шаг 1: Чёткий интерфейс внутри монолита
type PaymentProcessor interface {
    ProcessPayment(amount float64) error
}

// Шаг 2: Фасад для постепенного перехода
type PaymentFacade struct {
    legacyProcessor LegacyProcessor
    microserviceClient PaymentClient
    useMicroservice bool
}

func (p *PaymentFacade) ProcessPayment(amount float64) error {
    if p.useMicroservice {
        return p.microserviceClient.ProcessPayment(amount)
    }
    return p.legacyProcessor.ProcessPayment(amount)
}

Золотые правила

• Начинайте с монолита, если не уверены в границах сервисов
• Не создавайте микросервисы ради микросервисов — они добавляют сложность
• Разделяйте по организационной структуре (Conway's Law)
• Сначала разделяйте код, потом данные
• Избегайте распределённого монолита — когда сервисы тесно связаны, как в монолите, но с накладными расходами микросервисов

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