Что такое масштабирование в Node.js

Да ты посмотри, какая тема интересная подъехала — масштабирование в Node.js! Это ж как с машиной: можно один движок форсировать до небес, а можно целый автопарк гонять. И то, и другое работает, но мозги надо включать, а не просто хуярить код.

Вот смотри, первый способ — вертикальное масштабирование. По-простому: берешь один сервер и начинаешь его накачивать, как качка в зале. Больше ядер, больше оперативки. В Node.js это особенно заходит, потому что он асинхронный, небось, и может одним процессом на все ядра работать, если правильно настроить. Но тут есть подвох — рано или поздно упрешься в потолок железа, и цены на такие сервера будут такие, что ебушки-воробушки.

// Использование всех доступных CPU ядер
const cluster = require('cluster');
const os = require('os');

if (cluster.isMaster) {
  const numCPUs = os.cpus().length;
  console.log(`Master ${process.pid} is running`);
  console.log(`Forking for ${numCPUs} CPUs`);

  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`Worker ${worker.process.pid} died`);
    cluster.fork(); // Автоматический рестарт
  });
} else {
  // Код воркера
  require('./app.js');
}

Второй способ — горизонталка. Это когда ты не один могучий сервер, а овердохуища одинаковых, но маленьких. Запустил их кучу и раздаешь нагрузку между ними, как умный бармен в переполненном баре. Главное правило здесь — приложение должно быть stateless. Никакого состояния в памяти! Все сессии, кеш — во внешние хранилища, типа Redis. А то получится пиздопроебибна: пользователь зашел на один сервер, а его сессия осталась на другом, и он сам от себя охуел.

// Stateless архитектура для горизонтального масштабирования
const express = require('express');
const app = express();

// Все состояние хранится во внешних сервисах
const Redis = require('ioredis');
const redis = new Redis(process.env.REDIS_URL);

// Сессии в Redis, а не в памяти
const session = require('express-session');
const RedisStore = require('connect-redis')(session);

app.use(session({
  store: new RedisStore({ client: redis }),
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false
}));

// Кеширование в Redis
app.get('/api/data', async (req, res) => {
  const cacheKey = `data:${req.query.id}`;
  const cached = await redis.get(cacheKey);

  if (cached) {
    return res.json(JSON.parse(cached));
  }

  const data = await fetchDataFromDB(req.query.id);
  await redis.setex(cacheKey, 300, JSON.stringify(data)); // TTL 5 минут
  res.json(data);
});

Дальше — микросервисы. Это когда твое монолитное чудовище режешь на отдельные, мелкие сервисы, которые общаются между собой через события или HTTP. Красота в том, что каждый можно масштабировать отдельно. Но, чувак, доверия ебать ноль к этой схеме, если не продумать коммуникацию. Получится не архитектура, а манда с ушами, где все друг другу синхронно звонят и всё падает цепной реакцией.

// Сервис A (пользователи)
const userService = express();
userService.post('/users', async (req, res) => {
  // Создание пользователя
  const user = await createUser(req.body);

  // Асинхронное событие для других сервисов
  const amqp = require('amqplib');
  const connection = await amqp.connect(process.env.RABBITMQ_URL);
  const channel = await connection.createChannel();

  await channel.assertExchange('user-events', 'topic', { durable: true });
  channel.publish('user-events', 'user.created', 
    Buffer.from(JSON.stringify(user))
  );

  res.status(201).json(user);
});

// Сервис B (нотификации) подписывается на события
const notificationService = express();
// ... подписка на RabbitMQ события

А если в приложении есть тяжелые вычисления, которые блокируют event loop, то тебе прямая дорога в Worker Threads. Выносишь всю эту математику в отдельный поток, чтобы главный поток продолжал быстро отвечать на запросы. Иначе твой API будет тормозить, как хуй в пальто зимой.

const { Worker, isMainThread, parentPort } = require('worker_threads');

if (isMainThread) {
  // Главный поток - обработка HTTP запросов
  module.exports = function processHeavyTask(data) {
    return new Promise((resolve, reject) => {
      const worker = new Worker(__filename, {
        workerData: data
      });

      worker.on('message', resolve);
      worker.on('error', reject);
      worker.on('exit', (code) => {
        if (code !== 0) {
          reject(new Error(`Worker stopped with exit code ${code}`));
        }
      });
    });
  };
} else {
  // Worker thread - тяжелые вычисления
  const { workerData } = require('worker_threads');
  const result = performHeavyComputation(workerData);
  parentPort.postMessage(result);
}

Ну и куда же без балансировщика нагрузки в продакшене? Ты же не будешь вручную решать, на какой сервер пускать пользователя. Ставишь перед своим кластером Nginx и настраиваешь. Он умный, он распределит.

# Nginx конфигурация
upstream node_backend {
  least_conn; # Балансировка по наименьшему количеству соединений
  server 127.0.0.1:3001;
  server 127.0.0.1:3002;
  server 127.0.0.1:3003;
  keepalive 32;
}

server {
  location / {
    proxy_pass http://node_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
  }
}

А теперь самое важное — мои советы, выстраданные на практике. Э бошка думай, прежде чем лепить архитектуру.

1. Начинай с вертикалки. Это быстрее и проще. Накачал сервер, посмотрел, как летает. Если не хватает — тогда уже думай про горизонталку и микросервисы.
2. Используй PM2. Эта штука для продакшена просто ядрёна вошь. Запустил, настроил, она тебе и процессы перезапустит при падении, и логи красивые покажет.

   pm2 start app.js -i max --name "api"
   pm2 save
   pm2 startup

3. Мониторинг — это всё. Без него ты как слепой кот. Не знаешь, где узкое место, почему латенси ползет вверх. Настрой метрики, смотри на графики.

   const promClient = require('prom-client');
   const httpRequestDuration = new promClient.Histogram({
     name: 'http_request_duration_seconds',
     help: 'Duration of HTTP requests in seconds',
     labelNames: ['method', 'route', 'code'],
     buckets: [0.1, 0.5, 1, 2, 5]
   });
   
   // Экспорт метрик для Prometheus
   app.get('/metrics', async (req, res) => {
     res.set('Content-Type', promClient.register.contentType);
     res.end(await promClient.register.metrics());
   });

4. В облаке настрой автоматическое масштабирование. Чтобы при росте нагрузки само поднимало новые инстансы, а когда спадет — гасило лишние. Экономия, мать его.

И следи за ключевыми метриками, чувак: лаг ивент лупа, потребление памяти, скорость и задержка запросов, процент ошибок, загрузка процессора. Если что-то из этого пошло вразнос — значит, пора волнение ебать и лезть в настройки масштабирования.