Когда используешь микросервис?

Когда использовать микросервисы

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

Когда микросервисы — хороший выбор

1. Большие команды разработчиков

Когда над проектом работают несколько независимых команд, микросервисы позволяют им разрабатывать, развертывать и масштабировать сервисы параллельно без конфликтов:

// Архитектура
микросервис-аутентификация (Team Auth)
  - AuthService
  - TokenValidator
  - PasswordManager

микросервис-платежи (Team Payments)
  - PaymentProcessor
  - PaymentGateway
  - RefundService

микросервис-заказы (Team Orders)
  - OrderService
  - OrderValidator
  - ShippingService

Каждая команда может использовать свой стек и деплойить независимо.

2. Разные требования масштабируемости

Если разные части приложения имеют разные требования к нагрузке:

// Микросервис поиска (высокие требования, нужно масштабировать)
@Service
public class SearchService {
    // Требует: Redis, Elasticsearch, большая пропускная способность
    public List<Product> search(String query) {
        // 10000 rps в пиковое время
    }
}

// Микросервис рекомендаций (низкие требования)
@Service
public class RecommendationService {
    // Требует: ML модель, меньше нагрузки
    public List<Product> recommend(Long userId) {
        // 100 rps достаточно
    }
}

Можно масштабировать SearchService независимо, не масштабируя всё приложение.

3. Разные технологические стеки

Когда разные части приложения требуют разных технологий:

// Микросервис рекомендаций (Python + ML)
// Микросервис аналитики (Go + high-performance)
// Микросервис уведомлений (Node.js + async)
// Микросервис платежей (Java + надежность)

// Они взаимодействуют через REST/gRPC API

4. Высокие требования к надежности

Отказ одного микросервиса не должен привести к отказу всего приложения:

// Микросервис уведомлений может быть временно недоступен
// но заказ будет создан, уведомление отправится позже (через очередь)

@Service
public class OrderService {
    @Autowired
    private MessageQueue messageQueue;
    
    public Order createOrder(OrderRequest request) {
        Order order = orderRepository.save(new Order(request));
        
        // Асинхронно отправляем событие
        messageQueue.publish(new OrderCreatedEvent(order));
        
        return order;  // Не зависит от успеха отправки уведомления
    }
}

@Service
public class NotificationService {
    // Может быть недоступна, но заказы все равно будут создаваться
    public void sendNotification(OrderCreatedEvent event) {
        // Отправить уведомление
    }
}

5. Частые обновления отдельных функций

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

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

// Blue-Green развертывание
Version 1.0: Платежи на 100% работают на старой версии
Version 2.0: Постепенно переводим трафик на новую версию

// Если проблемы, откатываемся только для платежей

6. Независимые базы данных

Когда разные сервисы требуют разных типов БД:

// Микросервис заказов (PostgreSQL)
@Entity
public class Order {
    @Id
    private Long id;
    private String status;
}

// Микросервис логирования (Elasticsearch)
// Микросервис кеширования (Redis)
// Микросервис аналитики (ClickHouse)

// Каждый имеет свой database и schema

Когда микросервисы — ПЛОХОЙ выбор

1. Маленький проект

// Плохо: запущен стартап на микросервисах
// Сложность: Docker, Kubernetes, Service Discovery, Circuit Breakers
// Команда из 1-2 разработчиков не справится

// Хорошо: начать с монолита
package com.startup.app;

public class OrderService { }
public class PaymentService { }
public class NotificationService { }

2. Малая команда разработчиков

// 3-4 человека не смогут эффективно работать с 10+ микросервисами
// Придется каждому разбираться во всех сервисах

3. Однородные требования масштабируемости

// Если всё приложение имеет примерно одинаковые требования
// Монолит легче масштабировать горизонтально

4. Простая бизнес-логика

// CRUD приложение без сложной бизнес-логики
// Микросервисы добавляют ненужную сложность

Признаки, что пора переходить на микросервисы

- Код монолита превышает 50k+ строк
- Команда более 5 человек
- Deploy занимает 30+ минут
- Изменения в одной части ломают другие части
- Нужна независимая масштабируемость компонентов
- Разные команды требуют разные технологии
- Частые версионирования отдельных модулей

Типичная эволюция

Fase 1: Монолит (быстро и просто)
    ↓
Fase 2: Модульный монолит (разделение слоев)
    ↓
Fase 3: Микросервисы (при необходимости)

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