В каких сценариях используется синхронное взаимодействие между микросервисами?

«В каких сценариях используется синхронное взаимодействие между микросервисами?» — вопрос из категории Архитектура, который задают на 10% собеседований Java Разработчик. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Синхронное взаимодействие (обычно по протоколу HTTP/REST или gRPC) используется, когда сервису-инициатору требуется немедленный и гарантированный ответ от другого сервиса для продолжения своей работы.

Типичные сценарии:

  1. Валидация и проверка: Требуется подтверждение от авторитетного сервиса.
    • Пример: Проверка наличия товара на складе перед созданием заказа.
    • Пример: Верификация платежных данных банковским сервисом.
  2. Получение актуальных данных: Запрос информации, которая необходима для формирования ответа клиенту.
    • Пример: Получение текущего баланса пользователя для отображения.
    • Пример: Запрос деталей продукта из каталога для страницы заказа.
  3. Оркестрация с жестким порядком: Когда операции должны выполняться строго последовательно и следующая зависит от результата предыдущей.

Пример на Spring Cloud OpenFeign (REST-клиент):

// 1. Клиент для вызова Inventory Service
@FeignClient(name = "inventory-service")
public interface InventoryClient {
    @GetMapping("/api/inventory/{productId}")
    Boolean isInStock(@PathVariable String productId);
}

// 2. Использование в Order Service
@RestController
public class OrderController {
    @Autowired
    private InventoryClient inventoryClient;

    @PostMapping("/orders")
    public ResponseEntity<Order> createOrder(@RequestBody OrderRequest request) {
        // СИНХРОННЫЙ ВЫЗОВ: Ждем ответа о наличии товара
        if (!inventoryClient.isInStock(request.getProductId())) {
            return ResponseEntity.badRequest().body(null);
        }
        // Продолжаем обработку заказа
        Order newOrder = orderService.create(request);
        return ResponseEntity.ok(newOrder);
    }
}

Важное замечание: Синхронные вызовы создают жесткую временную связь и риск каскадных отказов. Для фоновых или длительных операций предпочтительнее асинхронные паттерны (обмен сообщениями через брокер, событийный подход).