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

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

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

1. Доменно-ориентированное проектирование (Domain-Driven Design, DDD)

Это фундаментальный принцип. Мы делим систему не по технологическим слоям (например, «база данных», «логика»), а по бизнес-возможностям.

• Выявление ограниченных контекстов (Bounded Contexts): Анализируем бизнес-домен и выделяем логически изолированные части с четкими границами. Каждый контекст имеет свою собственную унифицированную модель данных и язык (Ubiquitous Language).

    *   *Пример:* В системе электронной коммерции можно выделить контексты `Заказ (Order)`, `Оплата (Payment)`, `Доставка (Shipping)`, `Каталог товаров (Catalog)`, `Пользователь (User)`.

• Один контекст — один потенциальный микросервис: Каждый ограниченный контекст становится сильным кандидатом в отдельный микросервис. Это обеспечивает высокую связность (high cohesion) внутри сервиса и слабую связанность (loose coupling) между сервисами.

// Пример: Сервис "Заказы" владеет своей моделью и не зависит от деталей модели "Каталога"
namespace App\Order\Domain;

class Order
{
    private string $orderId;
    /** @var OrderItem[] */
    private array $items; // Ссылается на ProductId, а не на объект Product из каталога
    private string $status;
    // ... бизнес-логика, связанная именно с жизненным циклом заказа
}

2. Принцип единственной ответственности (Single Responsibility Principle, SRP)

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

• Плохо: Сервис Пользователь, который управляет аутентификацией, профилями, ролями И отправкой email-уведомлений.
• Хорошо: Отдельный сервис Уведомления (Notification) отвечает за отправку сообщений через разные каналы (email, SMS, push). Сервис Пользователь лишь отправляет в него события.

3. Независимость жизненного цикла и развертывания

Микросервисы должны быть независимо развертываемыми. Если для внесения изменения в одну маленькую функцию вам необходимо пересобрать и перезапустить половину системы — границы выбраны неверно.

• Собственное хранилище данных: Каждый сервис управляет своей схемой БД и не имеет прямого доступа к БД другого сервиса. Для обмена данными используется публичный API (обычно REST/gRPC) или асинхронные события.
• Отдельные репозитории и конвейеры CI/CD: Это позволяет командам работать автономно, выбирать технологии (в рамках соглашений компании) и выпускать обновления в своем ритме.

4. Устойчивость к сбоям и автономность

Сервис должен быть спроектирован так, чтобы отказы других сервисов минимально влияли на его работоспособность. Это достигается через:

• Асинхронное взаимодейение (через брокеры сообщений, например, RabbitMQ или Kafka).
• Шаблоны устойчивости: Circuit Breaker, Retry, Fallback.
• Избыточность данных (при необходимости): Сервис может хранить локальную денормализованную копию данных, критичных для его работы, чтобы не зависеть от постоянных запросов к другому сервису.

// Пример: Использование Circuit Breaker для вызова сервиса оплаты
use Resiliency\CircuitBreaker;

$circuitBreaker = new CircuitBreaker();
try {
    $paymentResult = $circuitBreaker->call(
        function () use ($paymentService, $order) {
            return $paymentService->process($order); // Вызов внешнего сервиса
        },
        function () use ($order) {
            // Fallback: помещаем заказ в очередь на повторную обработку
            $this->queue->push(new RetryPaymentJob($order));
            return ['status' => 'pending'];
        }
    );
} catch (ServiceUnavailableException $e) {
    // Сервис оплаты недоступен, но заказ создан
}

5. Масштабируемость

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

• Пример: Сервис Генерация PDF-отчетов может требовать много CPU, а сервис Изменение настроек пользователя — нет. Мы можем запустить 20 инстансов первого и 2 инстанса второго.

Ключевые антипаттерны при разделении

1. Разделение по технологическому стеку («Сервис PHP», «Сервис Python») — ведет к распределенному монолиту.
2. Слишком мелкое дробление («наносервисы») — порождает чудовищную сложность оркестрации, лавину сетевых вызовов и убивает производительность.
3. Сквозная общая база данных — это главный враг независимости. Изменение схемы одним сервисом сломает все остальные.

Процесс принятия решения

На практике я руководствуюсь следующей последовательностью:

1. Начинаем с монолита (для новых проектов), четко модулируя его по DDD. Это позволяет понять естественные границы предметной области.
2. Выделяем первый микросервис, когда для модуля появляется явная потребность в отдельном жизненном цикле: иная команда, особые требования к масштабированию, эксперимент с новой технологией.
3. Постоянно переоцениваем границы. Они не высечены в камне. Если два сервиса становятся неразрывно связанными (часто меняются вместе, постоянные синхронные вызовы), возможно, их стоит объединить.

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