Какой было взаимодействие между микросервисами?

Взаимодействие между микросервисами: основные подходы

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

1. Синхронное взаимодействие (Synchronous Communication)

REST API / HTTP (Request-Response)

Микросервис A напрямую запрашивает данные у микросервиса B и ожидает ответ.

// Микросервис A (OrderService)
@Service
public class OrderService {
    @Autowired
    private RestTemplate restTemplate;  // или WebClient
    
    public Order createOrder(Order order) {
        // Синхронный вызов к UserService
        User user = restTemplate.getForObject(
            "http://user-service:8081/api/v1/users/" + order.getUserId(),
            User.class
        );
        
        if (user == null) {
            throw new UserNotFoundException();
        }
        
        // Синхронный вызов к PaymentService
        Payment payment = restTemplate.postForObject(
            "http://payment-service:8082/api/v1/payments",
            new PaymentRequest(order.getAmount(), user.getId()),
            Payment.class
        );
        
        order.setPaymentId(payment.getId());
        return orderRepository.save(order);
    }
}

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

• Простая реализация
• Синхронная модель = предсказуемые результаты
• Легко отладка

Недостатки:

❌ Coupling (тесная связанность) — если UserService упал, OrderService тоже сломается
❌ Cascading failures — цепочка отказов
❌ Performance — ждём всех ответов
❌ Resilience — нет встроенного механизма повторов

gRPC (Protocol Buffers)

Быстрое и эффективное взаимодействие с использованием Protocol Buffers.

// user-service.proto
service UserService {
    rpc GetUser(GetUserRequest) returns (User);
    rpc ListUsers(Empty) returns (stream User);
}

message GetUserRequest {
    string user_id = 1;
}

message User {
    string id = 1;
    string name = 2;
    string email = 3;
}

// Использование в OrderService
@Service
public class OrderService {
    private final UserServiceGrpc.UserServiceBlockingStub userServiceStub;
    
    public OrderService(ManagedChannel channel) {
        this.userServiceStub = UserServiceGrpc.newBlockingStub(channel);
    }
    
    public Order createOrder(Order order) {
        // Синхронный gRPC вызов (быстрее, чем HTTP)
        User user = userServiceStub.getUser(
            GetUserRequest.newBuilder().setUserId(order.getUserId()).build()
        );
        
        // ...
        return order;
    }
}

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

• Быстрее HTTP/REST (binary протокол)
• Type-safe (контракт в .proto)
• Поддержка streaming

Недостатки:

• Всё ещё синхронное
• Сложнее отладка (binary формат)
• Требует дополнительные зависимости

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

Kafka / Message Broker (Event-Driven)

Микросервисы общаются через события, не ожидая прямого ответа.

// Микросервис A: Публикует событие
@Service
public class OrderService {
    @Autowired
    private KafkaTemplate<String, OrderCreatedEvent> kafkaTemplate;
    
    public Order createOrder(Order order) {
        order = orderRepository.save(order);
        
        // Асинхронно публикует событие (не ждёт ответа)
        OrderCreatedEvent event = new OrderCreatedEvent(
            order.getId(),
            order.getUserId(),
            order.getAmount()
        );
        kafkaTemplate.send("order-events", order.getId(), event);
        
        return order;  // Возвращается сразу, до обработки DownStream сервисов
    }
}

// Микросервис B: Слушает событие
@Service
public class PaymentService {
    @KafkaListener(
        topics = "order-events",
        groupId = "payment-service-group"
    )
    public void handleOrderCreated(OrderCreatedEvent event) {
        // Асинхронно обрабатывает событие
        Payment payment = new Payment(
            event.getOrderId(),
            event.getAmount()
        );
        paymentRepository.save(payment);
        
        // При необходимости публикует свои события
        kafkaTemplate.send("payment-events", 
            new PaymentProcessedEvent(payment.getId()));
    }
}

// Микросервис C: Слушает события платежа
@Service
public class NotificationService {
    @KafkaListener(
        topics = "payment-events",
        groupId = "notification-service-group"
    )
    public void handlePaymentProcessed(PaymentProcessedEvent event) {
        // Отправляет уведомление пользователю
        emailService.sendPaymentConfirmation(event.getPaymentId());
    }
}

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

✅ Loose coupling — сервисы независимы
✅ High throughput — асинхронная обработка
✅ Resilience — если сервис упал, сообщения в очереди
✅ Scalability — легко добавить новых слушателей
✅ Event sourcing — полная история событий

Недостатки:

❌ Сложнее отладка (асинхронные потоки)
❌ Eventual consistency — консистентность со временем
❌ Обработка ошибок сложнее
❌ DLQ (Dead Letter Queue) для обработки ошибок

RabbitMQ / Message Queue

Траиционный message broker с гарантией доставки.

// Публикатор события
@Service
public class OrderService {
    @Autowired
    private RabbitTemplate rabbitTemplate;
    
    public Order createOrder(Order order) {
        order = orderRepository.save(order);
        
        rabbitTemplate.convertAndSend(
            "order-exchange",
            "order.created",
            new OrderCreatedEvent(order.getId(), order.getUserId())
        );
        
        return order;
    }
}

// Слушатель события
@Service
public class NotificationService {
    @RabbitListener(queues = "order-notification-queue")
    public void handleOrderCreated(OrderCreatedEvent event) {
        // Асинхронная обработка
        sendOrderConfirmationEmail(event.getUserId(), event.getOrderId());
    }
}

Когда использовать:

• Сложные workflow с множеством шагов
• Нужна гарантия доставки
• Требуется обработка ошибок и retry

3. Гибридный подход (Hybrid)

// Синхронный вызов для критичных данных
// (нужен прямой ответ)
@Service
public class OrderService {
    @Autowired
    private WebClient userServiceClient;
    
    @Autowired
    private KafkaTemplate<String, OrderCreatedEvent> kafka;
    
    public Order createOrder(Order order) {
        // 1. Синхронный вызов (нужно гарантировать)  
        User user = userServiceClient.get()
            .uri("/users/{id}", order.getUserId())
            .retrieve()
            .bodyToMono(User.class)
            .block();  // Ждём результат
        
        if (user == null) {
            throw new UserNotFoundException();
        }
        
        // 2. Сохраняем заказ
        order = orderRepository.save(order);
        
        // 3. Асинхронно публикуем событие
        // (не критично, если задержка)
        kafka.send("order-events", 
            new OrderCreatedEvent(order.getId(), order.getUserId()));
        
        return order;
    }
}

Сравнение подходов

Рекомендации

Используй REST/gRPC когда:

• Нужен прямой синхронный ответ
• Сервисы часто общаются
• Простая логика (2-3 сервиса)

Используй Kafka/RabbitMQ когда:

• Нужна высокая масштабируемость
• Сложные workflow с множеством сервисов
• Важна отказоустойчивость
• Можно допустить eventual consistency

Лучший подход: Комбинация

Критичные данные → REST/gRPC (синхронно)
События и уведомления → Kafka/RabbitMQ (асинхронно)