Микросервисы на 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 микросервиса:
- API Gateway — точка входа, роутинг
- Link Service — создание и хранение ссылок
- Analytics Service — статистика переходов
Каждый сервис — отдельный репозиторий, отдельная БД (Redis для ссылок, PostgreSQL для аналитики).
Инструменты, которые реально нужны
Инструмент
БлогиРекомендаций по книгамЧитайте также |
|---|