Какие существуют подходы к коммуникации между микросервисами?

Коммуникацию между микросервисами можно разделить на два основных типа: синхронную и асинхронную.

1. Синхронная коммуникация (прямой вызов)

Один сервис делает запрос и ждет ответа от другого. Если второй сервис недоступен, операция завершается ошибкой.

• REST/HTTP: Самый популярный подход. Использует стандартные HTTP-методы (GET, POST и т.д.) и текстовые форматы (чаще всего JSON).
  • Плюсы: Простота, универсальность, человекочитаемость.
  • Минусы: Относительно медленный, избыточность текстового формата.

    // Клиент делает прямой HTTP-запрос
    resp, err := http.Get("http://user-service/users/123")

• gRPC: Высокопроизводительный фреймворк от Google. Использует бинарный протокол Protocol Buffers и HTTP/2.
  • Плюсы: Скорость, строгая типизация контрактов (.proto файлы), поддержка стриминга.
  • Минусы: Бинарный формат не читаем человеком, требует генерации кода.

    // Клиент вызывает удаленную процедуру
    conn, _ := grpc.Dial("user-service:50051", grpc.WithInsecure())
    client := pb.NewUserServiceClient(conn)
    user, _ := client.GetUser(ctx, &pb.GetUserRequest{Id: "123"})

2. Асинхронная коммуникация (через брокер сообщений)

Сервисы общаются через посредника (брокер), отправляя и получая сообщения. Это разрывает прямую зависимость между сервисами.

• Брокеры сообщений (RabbitMQ, Kafka, NATS): Сервис-отправитель публикует сообщение в очередь или топик, а сервис-получатель подписывается на него.
  • Плюсы: Отказоустойчивость (если получатель недоступен, сообщение останется в очереди), слабая связанность (decoupling), масштабируемость.
  • Минусы: Усложнение архитектуры за счет нового компонента (брокера).

    // Отправка сообщения в RabbitMQ
    err := ch.Publish(
    "orders_exchange", // exchange
    "order.created",   // routing key
    false,             // mandatory
    false,             // immediate
    amqp.Publishing{
        ContentType: "application/json",
        Body:        []byte(body),
    })

Выбор подхода