Транспорты микросервисов: TCP, Redis, NATS, Kafka

Микросервис — это app на transport, а не на HTTP

Микросервис Nest — это тот же AppModule, что ты уже пишешь, забутстраппленный так, чтобы слушать на transport, а не на HTTP-сервере. Ты вызываешь createMicroservice с transport и options; transport сменный, и хендлеры твоих контроллеров остаются байт в байт теми же, когда ты переезжаешь с TCP на Kafka.

import { NestFactory } from '@nestjs/core';
import { Transport, MicroserviceOptions } from '@nestjs/microservices';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.createMicroservice<MicroserviceOptions>(AppModule, {
    transport: Transport.TCP, // меняй на REDIS / NATS / RMQ / KAFKA, хендлеры не трогаются
    options: { host: '0.0.0.0', port: 3001 },
  });
  await app.listen();
}
bootstrap();

Хендлеры бывают двух видов, и это различие — важнейшая идея урока. @MessagePattern(pattern) — это запрос–ответ: возвращаемое значение хендлера (или Observable) сериализуется обратно вызывающему, а transport сопоставляет ответ с запросом через correlation id. @EventPattern(event) — это fire-and-forget: он реагирует на то, что случилось, и не возвращает ничего — канала ответа нет вообще.

import { Controller } from '@nestjs/common';
import { MessagePattern, EventPattern, Payload } from '@nestjs/microservices';

@Controller()
export class OrdersController {
  // запрос–ответ: вызывающий ждёт это возвращаемое значение
  @MessagePattern({ cmd: 'order.total' })
  total(@Payload() ids: number[]): number {
    return ids.reduce((sum, id) => sum + priceOf(id), 0);
  }

  // fire-and-forget: «это случилось»; ответа никто не ждёт
  @EventPattern('order.placed')
  async onOrderPlaced(@Payload() order: OrderDto): Promise<void> {
    await this.billing.charge(order); // никакое значение никуда не отправляется
  }
}

На стороне вызывающего ClientProxy зеркалит это разделение: send() для @MessagePattern, emit() для @EventPattern. send() возвращает холодный Observable — ничего не отправляется, пока ты не подпишешься, и стрим эмитит ответ — так что это для «мне нужен ответ». emit() публикует событие и не ждёт его — это для «это случилось, реагируй, если тебе важно».

import { Injectable, Inject } from '@nestjs/common';
import { ClientProxy } from '@nestjs/microservices';
import { firstValueFrom } from 'rxjs';

@Injectable()
export class OrdersService {
  constructor(@Inject('ORDERS') private readonly client: ClientProxy) {}

  // send: возвращает Observable ответа; дождись его ради значения
  total(ids: number[]) {
    return firstValueFrom(this.client.send<number>({ cmd: 'order.total' }, ids));
  }

  // emit: опубликовал и пошёл дальше; ответа не ждём
  placed(order: OrderDto) {
    this.client.emit('order.placed', order); // fire-and-forget
  }
}

Выбор transport — это выбор о доставке

Каждый transport говорит на одном и том же API хендлеров, так что решение никогда не про синтаксис — оно про семантику доставки: персистит ли broker сообщение, может ли восстановившийся consumer его переиграть, гарантирован ли порядок, какую пропускную способность он держит. TCP и Redis pub/sub просты и быстры, но теряют; RabbitMQ и Kafka долговечны, но заставляют платить за это идемпотентностью. Когда видишь постмортем «события потерялись при деплое» — именно с этой таблицы начинается разбор.

Два факта из этой таблицы несут сеньорский вес. Первый: at-least-once (RabbitMQ, Kafka) означает передоставку, а значит, твой consumer может отработать дважды на одном сообщении — поэтому он обязан быть идемпотентным, иначе ты спишешь с карты дважды. Второй: Kafka упорядочивает сообщения только внутри партиции, не по всему топику: события одного orderId остаются упорядоченными, только если попадают в одну партицию (ключуй по orderId), а consumer group раскидывает партиции по инстансам ради параллелизма, сохраняя порядок в пределах партиции. Запрос–ответ в Kafka тоже есть, но тяжелее — клиент должен вызвать subscribeToResponseOf(topic), чтобы ответы приходили в выделенный reply-топик и сопоставлялись назад по correlation id.

// Kafka-микросервис: список broker'ов и consumer group
const app = await NestFactory.createMicroservice<MicroserviceOptions>(AppModule, {
  transport: Transport.KAFKA,
  options: {
    client: { brokers: ['localhost:9092'] },
    consumer: { groupId: 'billing-consumer' }, // group => партиции делятся между подами
  },
});

Гибридные приложения: HTTP и transport разом

HTTP редко выбрасывают. Гибридное приложение — это обычное HTTP-приложение, которое ещё слушает как микросервис: ты делаешь connectMicroservice один или несколько transport’ов, затем startAllMicroservices() перед listen(). Один и тот же процесс обслуживает REST и реагирует на события broker’а.

const app = await NestFactory.create(AppModule);
app.connectMicroservice<MicroserviceOptions>({
  transport: Transport.KAFKA,
  options: { client: { brokers: ['localhost:9092'] }, consumer: { groupId: 'orders' } },
});
await app.startAllMicroservices(); // начинаем потреблять события
await app.listen(3000);            // и продолжаем обслуживать HTTP