Микросервисы на JavaScript: с нуля до первого сервиса за 20 минут

Онлайн-тренажер Python для начинающих

Изучайте Python легко и без перегрузки теорией. Решайте практические задачи с автоматической проверкой, получайте подсказки на русском языке и пишите код прямо в браузере — без необходимости что-либо устанавливать.

Начать курс

Микросервисы на JavaScript: с чего начать, чтобы не бросить через неделю

Вы когда-нибудь задумывались, почему крупные проекты вроде Netflix, Uber или Amazon перешли на микросервисы? Дело не в моде — это вопрос выживания. Когда ваш монолит весит 50 ГБ, а команда разработки — 100 человек, каждое изменение в коде превращается в русскую рулетку.

Но есть и хорошая новость: микросервисы на JavaScript — это не rocket science. Сегодня я покажу вам, как за 20 минут собрать рабочую архитектуру, которую не стыдно показать на собеседовании или положить в pet-проект.

Что такое микросервис простыми словами?

Представьте швейцарский нож. В монолитной архитектуре — это один большой нож со ста лезвиями. Сломалось одно — выбрасывай весь. Микросервисы — это набор отдельных ножей, каждый для своей задачи. Один сломался? Меняем только его.

Микросервис — это маленькое, автономное приложение, которое делает одну вещь, но делает её хорошо.

Почему JavaScript идеален для микросервисов?

  • Event Loop: асинхронность из коробки — идеально для I/O-bound задач
  • NPM: 2+ миллиона пакетов, готовая экосистема для всего
  • Node.js: легковесные процессы, быстрый запуск (50-100ms)
  • TypeScript: типизация, которая спасает в распределённых системах
  • Единый язык: фронтенд и бэкенд на JS — меньше контекстного переключения

С чего начать: практический roadmap

Шаг 1. Мастрид: Express + Docker

Забудьте про Kubernetes на старте. Вам нужен микросервис на Node.js, который можно запустить одной командой. Начнём с самого простого — сервиса-приветствия.

Создаём первый микросервис

// service-greeting/index.js
const express = require('express');
const app = express();
const PORT = process.env.PORT || 3000;

app.get('/api/hello', (req, res) => {
  res.json({ 
    message: 'Привет из микросервиса!',
    timestamp: new Date().toISOString(),
    service: 'greeting'
  });
});

app.listen(PORT, () => {
  console.log(`Greeting service running on port ${PORT}`);
});

Теперь обернём это в Docker:

# Dockerfile
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "index.js"]

Шаг 2. Docker Compose: оркестрация для бедных

Не бегите за Kubernetes. Для старта Docker Compose — ваш лучший друг. Создадим два сервиса и свяжем их.

# docker-compose.yml
version: '3.8'
services:
  greeting:
    build: ./service-greeting
    ports:
      - "3001:3000"
    environment:
      - PORT=3000

  users:
    build: ./service-users
    ports:
      - "3002:3000"
    environment:
      - PORT=3000
      - GREETING_SERVICE=http://greeting:3000

Шаг 3. Связываем сервисы: HTTP vs Message Broker

В микросервисной архитектуре на JavaScript есть два способа общения:

  • Синхронный (HTTP): просто, понятно, но создаёт зависимость
  • Асинхронный (RabbitMQ/Kafka): сложнее, но надёжнее

Пример HTTP-коммуникации между сервисами

// service-users/index.js
const express = require('express');
const axios = require('axios');
const app = express();

app.get('/api/user/:id', async (req, res) => {
  try {
    // Вызов другого микросервиса
    const greeting = await axios.get(
      `${process.env.GREETING_SERVICE}/api/hello`
    );
    
    res.json({
      userId: req.params.id,
      greeting: greeting.data.message
    });
  } catch (error) {
    res.status(500).json({ error: 'Service unavailable' });
  }
});

app.listen(3000);

Типичные ошибки новичков (и как их избежать)

Ошибка №1: Слишком маленькие сервисы

Если ваш «микросервис» занимается только валидацией email — это не микросервис, это функция. Микросервис должен быть достаточно большим, чтобы иметь смысл, и достаточно маленьким, чтобы его можно было переписать за две недели.

Ошибка №2: Общая база данных

Это убивает всю идею микросервисов. Каждый сервис — своя БД. Даже если это SQLite для старта. Нарушили это правило — получили распределённый монолит.

Ошибка №3: Игнорирование observability

Без логов и метрик вы слепы. Добавьте хотя бы morgan для HTTP-логов и prom-client для метрик:

const prometheus = require('prom-client');

// Счётчик запросов
const requestCounter = new prometheus.Counter({
  name: 'http_requests_total',
  help: 'Total number of HTTP requests',
  labelNames: ['method', 'route', 'status']
});

// Использование в middleware
app.use((req, res, next) => {
  res.on('finish', () => {
    requestCounter.inc({
      method: req.method,
      route: req.route?.path || 'unknown',
      status: res.statusCode
    });
  });
  next();
});

Когда микросервисы — это overkill?

Честно? В 80% случаев микросервисы не нужны. Если ваш проект — это:

  • Команда до 5 человек
  • Меньше 50 000 пользователей
  • Один домен (например, только блог)

...вам хватит монолита. Микросервисы — это решение проблем масштабирования, а не архитектурный тренд.

Реальный проект: что попробовать?

Лучший способ освоить микросервисы на JavaScript — написать что-то осмысленное. Вот идея для pet-проекта:

Сервис сокращения ссылок (URL shortener)

Разбейте на 3 микросервиса:

  1. API Gateway — точка входа, роутинг
  2. Link Service — создание и хранение ссылок
  3. Analytics Service — статистика переходов

Каждый сервис — отдельный репозиторий, отдельная БД (Redis для ссылок, PostgreSQL для аналитики).

Инструменты, которые реально нужны

Инструмент

Блоги

Рекомендаций по книгам