Для чего нужна микросервисная архитектура?

Для чего нужна микросервисная архитектура?

Микросервисная архитектура (Microservices Architecture) — это подход к разработке, при котором приложение разбивается на маленькие, независимые сервисы. Давайте разберёмся, зачем это нужно и какие проблемы она решает.

Проблемы монолитной архитектуры

Сначала посмотрим, почему люди отходят от традиционного монолита:

Монолитное приложение:
┌─────────────────────────────────┐
│     Monolithic Application      │
├──────────┬──────────┬───────────┤
│ User     │ Order    │ Payment   │
│ Service  │ Service  │ Service   │
├──────────┼──────────┼───────────┤
│  Single Database              │
└─────────────────────────────────┘

Проблемы:
1. Сложность масштабирования (масштабируется всё вместе, не отдельные части)
2. Одна ошибка в модуле может упадить всё приложение
3. Разные команды работают на одном коде (merge conflicts)
4. Сложно использовать разные технологии для разных компонентов
5. Дорогостоящий рефакторинг при изменении архитектуры

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

Микросервисы:
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│ User Service │     │ Order Service│     │PaymentService│
│              │     │              │     │              │
│  User DB     │     │  Order DB    │     │  Payment DB  │
└──────────────┘     └──────────────┘     └──────────────┘
       ↑                    ↑                     ↑
       └────────────────────┴─────────────────────┘
           REST/gRPC/Message Broker

Основные преимущества

1. Независимое масштабирование

// Микросервисы
// UserService может работать на 2 экземплярах
// OrderService может работать на 10 экземплярах (нагрузка выше)
// PaymentService может работать на 5 экземплярах

// В монолите пришлось бы копировать ВСЁ приложение

2. Независимое развёртывание

// Команда Order Service обновляет свой сервис
// Не нужно перезагружать User Service и Payment Service
// Можно развёртывать по графику каждого сервиса

// В монолите нужно перезагружать всё приложение

3. Отказоустойчивость

// Payment Service упал?
// Остальные сервисы продолжают работать
// Можно запустить Payment Service независимо

// В монолите упадёт всё приложение

4. Технологическая гибкость

User Service     → Spring Boot + PostgreSQL + Java
Order Service    → Node.js + MongoDB + JavaScript
Payment Service  → Go + MySQL
Notification     → Python + RabbitMQ

Каждая команда выбирает лучший стек для своей задачи!
В монолите всё на одном языке.

5. Командная независимость

Традиционное:
Все разработчики в одном репозитории
→ конфликты в merge
→ разработчики мешают друг другу
→ сложно масштабировать команду

Микросервисы:
Каждая команда имеет свой сервис
→ независимый репозиторий
→ независимая разработка
→ легче нанимать новых людей

Практический пример: e-commerce платформа

Монолит

@SpringBootApplication
public class ECommerceApplication {
    // ВСЁ в одном приложении
    // Product Controller
    // Order Controller
    // Payment Controller
    // User Controller
    // Notification Service
    // Payment Gateway Integration
    // Inventory Management
}

// Проблема: Black Friday sales → упал весь сайт!
// Потребовалось горячо перезагружать огромное приложение

Микросервисы

// 1. Product Service
@RestController
@RequestMapping("/api/products")
public class ProductController {
    @GetMapping("/{id}")
    public Product getProduct(@PathVariable Long id) {
        return productService.getProduct(id);
    }
}

// 2. Order Service
@RestController
@RequestMapping("/api/orders")
public class OrderController {
    @PostMapping
    public Order createOrder(@RequestBody OrderRequest req) {
        // Вызывает Payment Service через REST/gRPC
        paymentServiceClient.charge(req.getAmount());
        // Вызывает Notification Service через Message Broker
        notificationQueue.sendOrderConfirmation(req.getEmail());
        return orderService.create(req);
    }
}

// 3. Payment Service
@RestController
@RequestMapping("/api/payments")
public class PaymentController {
    @PostMapping("/charge")
    public PaymentResponse charge(@RequestBody ChargeRequest req) {
        return paymentService.processPayment(req);
    }
}

// 4. Notification Service
@Service
public class NotificationService {
    @RabbitListener(queues = "order.confirmation")
    public void onOrderConfirmation(OrderEvent event) {
        emailService.sendOrderConfirmation(event.getEmail());
    }
}

В Black Friday:

• Order Service может масштабироваться к 100 экземплярам
• Product Service остаётся на 5 экземплярах (спрос умеренный)
• Система остаётся живой!

Коммуникация между микросервисами

1. REST API

// Order Service вызывает Payment Service
public class OrderService {
    private final RestTemplate restTemplate;
    
    public Order createOrder(OrderRequest req) {
        // Синхронный вызов
        PaymentResponse payment = restTemplate.postForObject(
            "http://payment-service:8080/api/payments/charge",
            new ChargeRequest(req.getAmount()),
            PaymentResponse.class
        );
        
        if (payment.isSuccess()) {
            return saveOrder(req);
        }
        throw new PaymentFailedException();
    }
}

2. Message Broker (асинхронный)

// Order Service отправляет событие
@Service
public class OrderService {
    private final RabbitTemplate rabbitTemplate;
    
    public Order createOrder(OrderRequest req) {
        Order order = saveOrder(req);
        
        // Отправляем событие асинхронно
        rabbitTemplate.convertAndSend(
            "order.exchange",
            "order.created.routing",
            new OrderCreatedEvent(order.getId(), order.getUserEmail())
        );
        
        return order;  // Не ждём ответа
    }
}

// Notification Service слушает события
@Service
public class NotificationService {
    @RabbitListener(queues = "notification.queue")
    public void onOrderCreated(OrderCreatedEvent event) {
        emailService.send(event.getEmail(), "Order created");
    }
}

3. gRPC (высокопроизводительный)

// payment.proto
service PaymentService {
    rpc Charge(ChargeRequest) returns (ChargeResponse);
}

message ChargeRequest {
    int64 amount = 1;
}

message ChargeResponse {
    bool success = 1;
    string transaction_id = 2;
}

// Java клиент
public class OrderService {
    private final PaymentServiceGrpc.PaymentServiceBlockingStub paymentStub;
    
    public void createOrder(OrderRequest req) {
        ChargeResponse response = paymentStub.charge(
            ChargeRequest.newBuilder()
                .setAmount(req.getAmount())
                .build()
        );
    }
}

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

1. Сетевые задержки
   - Вызовы между сервисами медленнее, чем локальные вызовы методов
   - Нужно обработать сетевые ошибки (retry, timeout, circuit breaker)

2. Распределённые транзакции
   - Сложно обеспечить ACID для операций между сервисами
   - Нужно использовать Saga pattern

3. Отладка
   - Баг может быть в сервисе A, B или в их коммуникации
   - Нужна трассировка (distributed tracing)

4. Операционная сложность
   - Нужно мониторить много сервисов
   - Логирование, метрики, health checks

5. Тестирование
   - Нужны интеграционные тесты между сервисами

Решения сложностей

// 1. Retry и Circuit Breaker (Resilience4j)
@Service
public class OrderService {
    @Retry(name = "paymentService", fallbackMethod = "fallback")
    @CircuitBreaker(name = "paymentService", fallbackMethod = "fallback")
    public PaymentResponse charge(BigDecimal amount) {
        return restTemplate.postForObject(
            "http://payment-service/charge",
            amount,
            PaymentResponse.class
        );
    }
    
    public PaymentResponse fallback(BigDecimal amount, Exception e) {
        // Fallback логика при сбое
        return PaymentResponse.pending();
    }
}

// 2. Saga Pattern для распределённых транзакций
public class OrderSaga {
    public void executeOrder(OrderRequest req) {
        // Шаг 1: Зарезервировать инвентарь
        inventoryService.reserve(req.getProductId());
        try {
            // Шаг 2: Обработать платёж
            paymentService.charge(req.getAmount());
            // Шаг 3: Создать заказ
            orderService.create(req);
        } catch (PaymentException e) {
            // Откатиться на шаг 1
            inventoryService.release(req.getProductId());
        }
    }
}

// 3. Distributed Tracing (Sleuth + Zipkin)
@Slf4j
@Service
public class OrderService {
    public Order createOrder(OrderRequest req) {
        // Sleuth автоматически добавляет trace_id и span_id в логи
        log.info("Creating order: {}", req.getId());
        // Этот trace_id будет во всех микросервисах!
        return orderRepository.save(new Order(req));
    }
}

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

ИСПОЛЬЗУЙ микросервисы когда:

• Большая команда (10+ разработчиков)
• Разные части приложения масштабируются по-разному
• Нужна высокая доступность
• Разные команды работают независимо
• Разные части требуют разные технологии

НЕ ИСПОЛЬЗУЙ микросервисы когда:

• Маленький стартап (<10 людей)
• Простое приложение
• Команда не готова к операционной сложности
• Требуется простая разработка и быстрый time-to-market

Микросервисная архитектура — это мощный подход, но требует опыта и инфраструктуры для работы с ней!