В чем разница между Kafka и REST для обращения к сервису?

# Kafka vs REST для обращения к сервисам

Кафка и REST - это два совершенно разных подхода к коммуникации между сервисами. Это не одно и то же, и правильный выбор зависит от требований архитектуры.

REST API

REST (Representational State Transfer) - это синхронный протокол для обращения к удаленным сервисам через HTTP.

Характеристики:

• Синхронная коммуникация (request-response)
• Клиент ждет ответа
• Состояние HTTP (200, 404, 500 и т.д.)
• Основан на HTTP методах (GET, POST, PUT, DELETE)
• Статусные коды говорят о результате
• Точка-в-точку коммуникация

Пример REST запроса:

public class UserServiceClient {
    private final RestTemplate restTemplate;
    
    // Синхронный вызов - клиент ждет ответа
    public User getUser(String userId) {
        String url = "http://user-service:8080/api/v1/users/" + userId;
        
        try {
            ResponseEntity<User> response = restTemplate.getForEntity(
                url, 
                User.class
            );
            return response.getBody();
        } catch (RestClientException e) {
            // Обработка ошибки
            throw new ServiceException("Failed to get user", e);
        }
    }
    
    // Обновление через REST
    public void updateUser(String userId, User user) {
        String url = "http://user-service:8080/api/v1/users/" + userId;
        restTemplate.put(url, user);
    }
}

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

• Простота реализации
• Синхронный flow - сразу видны результаты
• Можно быстро проверить через curl/Postman
• Нет зависимостей (HTTP есть везде)
• Request/response модель понятна
• Low latency для простых операций
• Легко отладить

Недостатки REST:

• Тесная связанность (coupling) между сервисами
• Если сервис недоступен - вызывающий сервис падает
• Сложно масштабировать при большом трафике
• Нет гарантии доставки сообщения
• Нельзя обойти недоступный сервис
• Все зависят друг от друга синхронно
• Thundering herd проблема при отказе

Проблема REST в микросервисной архитектуре:

// Service A вызывает Service B, который вызывает Service C
orderService.createOrder(order) 
    -> paymentService.charge(amount)  // Синхронный вызов
        -> bankService.transfer(amount) // Еще один синхронный вызов

// Если bankService упадет - упадет весь цепочка!
// Заказ не создается, платеж не обрабатывается

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

• Синхронные операции где нужен результат сразу
• Публичные API
• Простые микросервисы
• Query операции (GET запросы)
• Когда сервисы очень близко по локации/сети

Kafka

Kafka - это асинхронный message broker для обмена событиями между сервисами.

Характеристики:

• Асинхронная коммуникация
• Event-driven архитектура
• Producer пишет сообщение в топик
• Consumer читает сообщение из топика
• Publish-Subscribe паттерн
• Гарантирует доставку
• Разделенная архитектура (decoupling)
• Масштабируемость

Пример Kafka использования:

// Order Service публикует событие
@Service
public class OrderService {
    @Autowired
    private KafkaTemplate<String, String> kafkaTemplate;
    
    public void createOrder(Order order) {
        // Сохраняем заказ
        orderRepository.save(order);
        
        // Асинхронно публикуем событие - не ждем ответа
        String orderJson = objectMapper.writeValueAsString(order);
        kafkaTemplate.send("orders-topic", order.getId(), orderJson);
        
        // Возвращаемся сразу, не дожидаясь обработки
    }
}

// Payment Service слушает события
@Component
public class PaymentEventListener {
    @KafkaListener(topics = "orders-topic", groupId = "payment-service")
    public void onOrderCreated(String orderJson) {
        Order order = objectMapper.readValue(orderJson, Order.class);
        
        // Асинхронно обрабатываем платеж
        try {
            paymentService.processPayment(order);
        } catch (Exception e) {
            // Можно повторить позже через retry механизм
            log.error("Failed to process payment", e);
        }
    }
}

// Shipping Service также может слушать
@Component
public class ShippingEventListener {
    @KafkaListener(topics = "orders-topic", groupId = "shipping-service")
    public void onOrderCreated(String orderJson) {
        Order order = objectMapper.readValue(orderJson, Order.class);
        shippingService.scheduleShipment(order);
    }
}

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

• Развязывает сервисы (decoupling)
• Асинхронность - лучшая производительность
• Высокая пропускная способность
• Гарантирует доставку (at-least-once, exactly-once)
• Можно переиндексировать/перепроцессировать
• История событий сохраняется
• Масштабируемость горизонтальная
• Resilience - если сервис упал, события ждут
• Event sourcing и CQRS паттерны

Недостатки Kafka:

• Сложнее для простых случаев
• Дополнительная инфраструктура (Kafka кластер)
• Если нужен результат сразу - не подходит
• Консистентность может быть eventual
• Сложнее отладить
• Требует переосмысления архитектуры

Event-Driven архитектура:

// Order Service публикует
orderService.createOrder(order) 
    -> kafkaTemplate.send("order-created", orderJson)

// Payment Service слушает асинхронно
paymentService.onOrderCreated(order) 
    -> Может упасть, восстановиться, переобработать

// Shipping Service слушает асинхронно
shippingService.onOrderCreated(order) 
    -> Работает независимо

// Notification Service слушает
notificationService.onOrderCreated(order) 
    -> Отправляет email

// Все параллельно, не зависят друг от друга!

Таблица сравнения

Сравнение сценариев

Сценарий 1: Пользователь заказывает товар

REST подход (проблемы):

orderController.createOrder() {
    1. Создаем заказ
    2. REST вызов к paymentService (ждем ответа) - может упасть
    3. REST вызов к shippingService (ждем ответа) - может упасть
    4. REST вызов к notificationService (ждем ответа) - может упасть
    // Если любой упадет - весь процесс падает!
    // Пользователь видит ошибку
}

Kafka подход (лучше):

orderService.createOrder() {
    1. Сохраняем заказ в БД
    2. Публикуем событие в Kafka (не ждем)
    3. Сразу возвращаем ответ пользователю
    
    // Асинхронно в фоне:
    paymentService слушает -> обрабатывает платеж
    shippingService слушает -> планирует доставку
    notificationService слушает -> отправляет письмо
    
    // Если один упадет - другие продолжают работать
    // События сохранены, можно переобработать
}

Сценарий 2: Получить профиль пользователя

REST (идеально):

GET /api/v1/users/{id}
// Синхронно получаем ответ сразу
Response: {"id": "123", "name": "John", ...}

Kafka (не подходит):

// Нельзя отправить запрос в Kafka и ждать синхронный ответ
// Это асинхронная архитектура!
// Пришлось бы делать сложные request-reply паттерны - излишне

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

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

• Нужен синхронный ответ
• Query операции (получение данных)
• Простые микросервисы
• Публичные API
• Нужна низкая latency для response
• Операции между 2-3 сервисами

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

• Event-driven архитектура
• Нужна асинхронность
• Множество сервисов реагируют на событие
• Нужна история событий
• Важна resilience и масштабируемость
• Операции могут быть отложены
• Нужна eventual consistency

Гибридный подход (лучший вариант):

// Query через REST (синхронно)
GET /api/v1/users/{id}

// Commands через Kafka (асинхронно)
POST /api/v1/orders // Сохраняет и публикует события

// REST для простого синхронного доступа
// Kafka для сложных асинхронных процессов

Заключение

REST и Kafka решают разные проблемы. REST идеален для синхронных query операций, а Kafka - для асинхронных event-driven систем. Современные архитектуры часто используют оба подхода: REST для API и query, Kafka для event-driven процессов и интеграции микросервисов.