Как бы организовал взаимодействие нескольких сервисов

# Как организовать взаимодействие нескольких сервисов

Взаимодействие микросервисов — ключевой аспект современной архитектуры. Рассмотрю различные подходы и лучшие практики.

1. Синхронное взаимодействие (REST/HTTP)

Самый простой и традиционный способ:

@Service
public class OrderService {
    private final RestTemplate restTemplate;
    
    public Order createOrder(OrderRequest request) {
        // Вызываем сервис платежей синхронно
        PaymentResponse payment = restTemplate.postForObject(
            "http://payment-service/api/payments",
            new PaymentRequest(request.getAmount()),
            PaymentResponse.class
        );
        
        if (payment.isSuccess()) {
            return saveOrder(request);
        }
        throw new PaymentFailedException();
    }
}

Преимущества:

• Простая реализация
• Немедленная обратная связь
• Легко отладить

Недостатки:

• Тесная связанность (tight coupling)
• Если сервис платежей недоступен, создание заказа падает
• Низкая масштабируемость при высоких нагрузках

2. Асинхронное взаимодействие (Message Queue)

Более надёжный подход с использованием очереди сообщений:

@Service
public class OrderService {
    private final RabbitTemplate rabbitTemplate;
    
    public Order createOrder(OrderRequest request) {
        Order order = Order.create(request);
        orderRepository.save(order);
        
        // Отправляем сообщение асинхронно
        rabbitTemplate.convertAndSend(
            "orders.exchange",
            "order.created",
            new OrderCreatedEvent(order.getId(), request.getAmount())
        );
        
        return order;
    }
}

@Component
public class PaymentListener {
    @RabbitListener(queues = "payment.queue")
    public void handleOrderCreated(OrderCreatedEvent event) {
        // Обрабатываем платёж асинхронно
        paymentService.processPayment(event.getOrderId(), event.getAmount());
    }
}

Преимущества:

• Слабая связанность (loose coupling)
• Высокая отказоустойчивость
• Хорошая масштабируемость

Недостатки:

• Сложнее отладить
• Нужна очередь сообщений (RabbitMQ, Kafka)
• Требует обработки ошибок и повторных попыток

3. Событийная архитектура (Event-Driven)

Вариант с использованием локальных событий Spring:

@Service
public class OrderService {
    private final ApplicationEventPublisher eventPublisher;
    
    public Order createOrder(OrderRequest request) {
        Order order = Order.create(request);
        orderRepository.save(order);
        
        // Опубликовываем локальное событие
        eventPublisher.publishEvent(new OrderCreatedEvent(order));
        
        return order;
    }
}

@Component
public class PaymentEventListener {
    @EventListener
    public void onOrderCreated(OrderCreatedEvent event) {
        paymentService.processPayment(event.getOrder());
    }
    
    @EventListener
    public void onPaymentCompleted(PaymentCompletedEvent event) {
        notificationService.sendEmail(event.getOrderId());
    }
}

4. Saga Pattern (для распределённых транзакций)

Используется для координации сложных процессов:

@Service
public class OrderSaga {
    private final OrderService orderService;
    private final PaymentService paymentService;
    private final InventoryService inventoryService;
    
    public void createOrderWithSaga(OrderRequest request) {
        try {
            // Шаг 1: Создаём заказ
            Order order = orderService.createOrder(request);
            
            // Шаг 2: Резервируем инвентарь
            inventoryService.reserveItems(order.getItems());
            
            // Шаг 3: Обрабатываем платёж
            Payment payment = paymentService.processPayment(order);
            
            // Если всё хорошо, подтверждаем
            orderService.confirmOrder(order);
            
        } catch (Exception e) {
            // Компенсирующие транзакции (откат)
            rollbackOrder(order);
            rollbackInventory(order);
        }
    }
}

5. Service Discovery (обнаружение сервисов)

В микросервисной архитектуре сервисы могут менять адреса:

@Configuration
public class RestClientConfig {
    @LoadBalanced
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

@Service
public class UserService {
    private final RestTemplate restTemplate;
    
    public User getUserById(Long id) {
        // Eureka или Consul разрешит "user-service" в реальный адрес
        return restTemplate.getForObject(
            "http://user-service/api/users/" + id,
            User.class
        );
    }
}

6. Circuit Breaker Pattern

Защита от cascading failures:

@Service
public class ResilientOrderService {
    private final RestTemplate restTemplate;
    
    @CircuitBreaker(
        name = "paymentService",
        fallbackMethod = "paymentServiceFallback"
    )
    public PaymentResponse processPayment(Order order) {
        return restTemplate.postForObject(
            "http://payment-service/api/payments",
            order,
            PaymentResponse.class
        );
    }
    
    private PaymentResponse paymentServiceFallback(
            Order order, Exception e) {
        // Возвращаем fallback или сохраняем в очередь
        return PaymentResponse.pending();
    }
}

Рекомендации по выбору

Оптимальная архитектура часто комбинирует несколько подходов: REST для синхронных операций, RabbitMQ/Kafka для асинхронных, и Circuit Breaker для защиты от сбоев.