Перейти на PRO

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

Тип вопроса: Архитектура Вероятность: 10% Категория: Java Разработчик

Ответ

Микросервисы взаимодействуют через стандартные протоколы, которые делятся на две основные категории: синхронные и асинхронные.

1. Синхронные протоколы (запрос-ответ)

  • HTTP/REST (JSON/XML)
    • Преимущества: Простота, человекочитаемость, кэширование, широкая поддержка.
    • Недостатки: Избыточность payload, более высокий latency. 
      // Пример REST-контроллера в Spring
@RestController
@RequestMapping("/api/orders")
public class OrderController {
@GetMapping("/{id}")
public ResponseEntity<Order> getOrder(@PathVariable Long id) {
    return ResponseEntity.ok(orderService.findById(id));
}
}
  • gRPC (HTTP/2 + Protocol Buffers)
    • Преимущества: Высокая производительность (бинарный Protobuf), потоковая передача, строгие контракты.
    • Недостатки: Сложнее в отладке, требуется генерация стабов. 
      // Пример .proto файла
service ProductService {
rpc GetProduct (ProductRequest) returns (ProductResponse);
}
  • GraphQL
    • Преимущества: Гибкость запросов (клиент сам определяет получаемые данные), избегает over/under-fetching.
    • Недостатки: Сложность на стороне сервера, проблемы с кэшированием.

2. Асинхронные протоколы (обмен сообщениями)

  • AMQP (RabbitMQ)
    • Модель: Брокер сообщений с очередями и обменниками (exchanges). Гарантированная доставка. 
      @RabbitListener(queues = "order.queue")
public void processOrder(OrderMessage order) {
// Асинхронная обработка заказа
}
  • Apache Kafka
    • Модель: Распределенный лог-ориентированный брокер. Высокая пропускная способность, хранение истории.
    • Используется для стриминга событий и построения event-driven архитектур.

Критерии выбора:

  • Требования к согласованности: Синхронные протоколы проще для строгой согласованности.
  • Производительность и масштабируемость: gRPC и Kafka обеспечивают высокий throughput.
  • Связность: Асинхронные протоколы уменьшают прямую зависимость между сервисами.

Ответ 18+ 🔞

Давайте разберем эту всю хуйню про то, как микросервисы друг с другом болтают. А то некоторые думают, что они там телепатически общаются, или через дымовые сигналы, блядь.

В общем, есть два главных лагеря, как они могут общаться: синхронно (прямо сейчас, и ждут ответа) и асинхронно (кинул сообщение и пошел дальше, ответ придет когда-нибудь). И у каждого подхода свои любимые игрушки-протоколы.

1. Синхронные протоколы (Типа «Эй, ты, ответь мне сейчас же!»)

  • HTTP/REST (JSON/XML)

    • Что хорошего: Всё просто, как три копейки. Человек может открыть и прочитать, что там летает. Кэширование работает. Его все знают и понимают. Стандарт де-факто для публичных апишек.
    • Что плохого: Данные (payload) часто жирные и избыточные, как тёща после праздников. Задержки (latency) могут быть повыше. 
      // Ну, типа, классический спринговый контроллер. Скучно, предсказуемо, но работает.
@RestController
@RequestMapping("/api/orders")
public class OrderController {
@GetMapping("/{id}")
public ResponseEntity<Order> getOrder(@PathVariable Long id) {
    return ResponseEntity.ok(orderService.findById(id));
}
}

  • gRPC (HTTP/2 + Protocol Buffers)

    • Что хорошего: О, это уже серьёзные пацаны! Высокая производительность, потому что данные бинарные (Protobuf). Может не просто запрос-ответ, а целые потоки гонять. Контракты строгие — сгенерировал из .proto файла и спи спокойно, несовместимость тебе не грозит.
    • Что плохого: Отлаживать — просто ёперный театр, не посмотришь в логах, что летает. Нужно эти стабы заранее генерировать, лишние телодвижения. 
      // Вот тебе контракт, детка. Чётко и ясно.
service ProductService {
rpc GetProduct (ProductRequest) returns (ProductResponse);
}

  • GraphQL

    • Что хорошего: Гибкость — просто пиздец! Клиент сам решает, какие поля и в каком объёме хочет получить. Никакого over-fetching (когда сервер отдаёт лишнее) или under-fetching (когда не хватает и надо делать десять запросов).
    • Что плохого: А вот на сервере ад начинается, блядь. Реализовать эту хуйню — та ещё головная боль. И с кэшированием традиционным проблемы — потому что запросы у всех разные, ебать.

2. Асинхронные протоколы (Типа «Кинь в чёрный ящик и забудь»)

  • AMQP (RabbitMQ)

    • Модель: Классический брокер сообщений. Есть очереди, есть обменники (exchanges), маршрутизация. Гарантирует, что сообщение не потеряется по дороге (пока не обработают). 
      // Сиди себе в сервисе, слушай очередь. Пришло сообщение — обработал.
@RabbitListener(queues = "order.queue")
public void processOrder(OrderMessage order) {
// Асинхронная обработка заказа
}

  • Apache Kafka

    • Модель: Это не просто очередь, это распределённый лог, ёпта! Сообщения не удаляются после чтения, они там хранятся. Пропускная способность — овердохуища. Идеально для стриминга событий и построения этих ваших модных event-driven архитектур, где все друг другу кидают события, а не дергают напрямую.

Ну и как же выбрать, спросишь ты? Да по обстоятельствам, чувак!

  • Нужна строгая согласованность прямо сейчас? Бери синхронную хуйню (REST/gRPC), тут проще.
  • Нужно гонять терабайты данных с минимальными задержками? Смотри в сторону gRPC или Kafka.
  • Хочешь, чтобы сервисы были слабо связаны и один упавший не клал всех остальных? Асинхронное общение — твой выбор, дружок. Кинул событие в очередь и спишь спокойно, потребитель разберётся, когда сможет.
© ХакСобесов, 2026
support@hacksobesov.com