За счет чего масштабируется REST?

Масштабируемость REST API: принципы и практика

REST масштабируется благодаря statelessness, кешированию, стандартизации и распределённой архитектуре. Это позволяет обрабатывать миллионы запросов параллельно.

1. Statelessness (Отсутствие состояния на сервере)

Это основной принцип, позволяющий REST масштабироваться:

// Плохо: состояние на сервере
const sessions = {}; // Хранится в памяти одного сервера

app.post('/login', (req, res) => {
  // Сохраняем сессию в памяти
  sessions[req.body.username] = { loggedIn: true };
  res.send({ sessionId: 'abc123' });
});

app.get('/profile', (req, res) => {
  // Проверяем сессию
  if (sessions[req.body.username]) {
    res.send({ profile: 'data' });
  }
});

// Проблема: если сервер упал, все сессии потеряны
// Если масштабировать на несколько серверов, каждый имеет свои сессии
// Запросы от одного пользователя должны всегда идти на один сервер
// Это ограничивает масштабируемость

// Хорошо: JWT tokens (stateless)
app.post('/login', (req, res) => {
  const token = jwt.sign(
    { username: req.body.username },
    'secret',
    { expiresIn: '1h' }
  );
  res.send({ token });
});

app.get('/profile', (req, res) => {
  try {
    const decoded = jwt.verify(req.headers.authorization, 'secret');
    // Информация о пользователе в самом токене
    res.send({ profile: 'data for ' + decoded.username });
  } catch (e) {
    res.status(401).send('Unauthorized');
  }
});

// Преимущество: любой сервер может обработать запрос
// Не нужно синхронизировать состояние между серверами
// Можно добавить/удалить серверы без потери данных

2. Кеширование (Caching)

Kеширование уменьшает нагрузку на сервер и ускоряет ответы:

// HTTP Cache headers
app.get('/users/:id', (req, res) => {
  const user = getUserFromDB(req.params.id);
  
  // Браузер кеширует ответ на 1 час
  res.set('Cache-Control', 'public, max-age=3600');
  // ETag для валидации кеша
  res.set('ETag', hashUser(user));
  
  res.json(user);
});

// Браузер автоматически использует кеш
// Вместо HTTP запроса, если max-age не истёк

// Условный запрос (304 Not Modified)
// Если ETag не изменился, сервер возвращает 304
// Браузер использует закешированный ответ

// CDN кеширование (edge caching)
// CloudFlare, AWS CloudFront, Akamai

// Запрос идёт не на origin server, а на edge server (ближайший к клиенту)
// Origin: api.example.com
// Edge: us-west.cdn.example.com (копия данных)

// Результат: ответ за 10ms вместо 500ms
// И нагрузка на origin сервер в 100 раз ниже

3. Стандартизация и простота

REST использует стандартные HTTP методы — это позволяет использовать готовые инструменты:

// Стандартные CRUD операции
GET    /users       // Получить список
GET    /users/:id   // Получить одного
POST   /users       // Создать
PUT    /users/:id   // Обновить
DELETE /users/:id   // Удалить

// Преимущество:
// - Браузер может кешировать GET запросы
// - Proxy серверы понимают REST
// - Load balancer может распределять запросы
// - CDN может кешировать GET ответы
// - любые HTTP инструменты работают

4. Распределённая архитектура

// Горизонтальное масштабирование
// Вместо одного мощного сервера -> много простых серверов

// Load Balancer распределяет запросы
// Client -> Load Balancer -> [Server1, Server2, Server3, ...]

// Каждый сервер stateless, может обрабатывать любой запрос
// Если сервер упал, его нагрузка распределяется на другие
// Можно добавить ещё серверов в runtime

// Пример с Node.js cluster
const cluster = require('cluster');
const os = require('os');

if (cluster.isMaster) {
  const numWorkers = os.cpus().length;
  
  // Создаём worker процесс на каждый CPU core
  for (let i = 0; i < numWorkers; i++) {
    cluster.fork();
  }
  
  // Master распределяет входящие соединения между workers
} else {
  // Worker обрабатывает запросы
  app.listen(3000);
}

// Результат: использование всех CPU ядер, в 4-8 раз больше throughput

5. Базы данных: репликация и шардирование

// Реplication: несколько копий данных
// Master-Slave архитектура

Master DB (read/write) \
                        Slave DB 1 (read only)
                        Slave DB 2 (read only)
                        Slave DB 3 (read only)

// Запрос на чтение идёт на любой Slave
// Запрос на запись идёт на Master и реплицируется на Slaves

const pool = mysql.createPool([
  {
    connectionId: 1,
    host: 'master.db.com',
    canRetry: false,
    priority: 1 // Для write
  },
  {
    connectionId: 2,
    host: 'slave1.db.com',
    canRetry: true,
    priority: 2 // Для read
  },
  {
    connectionId: 3,
    host: 'slave2.db.com',
    canRetry: true,
    priority: 2 // Для read
  }
]);

// Шардирование: данные разбиты на куски
// Вместо: 1 DB с 1 млрд записей
// Используем: 10 DB с 100 млн записей каждая

// Пользователь -> определяем shard -> ищем в одной DB
const getUserShard = (userId) => {
  const shardNumber = userId % 10; // 0-9
  return `db-shard-${shardNumber}`;
};

const user = await getFromDB(getUserShard(userId), userId);

// Результат:
// - Каждая DB работает с меньшим объёмом данных
// - Запросы выполняются быстрее (меньше индексов)
// - Можно распределить на разные физические серверы
// - Линейное масштабирование

6. Асинхронная обработка

// Синхронный API: ждём ответ
// Request -> Process -> Response
// Если процесс долгий, все ресурсы блокированы

// Асинхронный API:
// Request -> Queue -> Response (202 Accepted)
// Worker обрабатывает из очереди
// Клиент проверяет статус по ID

app.post('/send-email', (req, res) => {
  // Не отправляем письмо синхронно
  // Добавляем в очередь
  emailQueue.push({
    to: req.body.email,
    subject: 'Hello',
    body: 'Message'
  });
  
  res.status(202).json({ taskId: 'task-123' });
});

app.get('/tasks/:id', (req, res) => {
  const task = getTaskStatus(req.params.id);
  res.json(task); // { status: 'pending' } или { status: 'completed' }
});

// Преимущество:
// - API ответил быстро (202 response)
// - Серверные ресурсы не блокированы
// - Можно обработать в очереди медленно
// - Масштабируется лучше

7. Версионирование API

// Версионирование в URL
GET /api/v1/users       // Старый API
GET /api/v2/users       // Новый API

// Преимущество для масштабируемости:
// - Можно разворачивать разные версии на разных серверах
// - Постепенная миграция клиентов с v1 на v2
// - Не нужно обновлять всё сразу
// - Разные версии могут обращаться к разным БД

// Load Balancer маршрутизирует по версии
// /api/v1/* -> [Old Servers]
// /api/v2/* -> [New Servers]

8. Практический пример: масштабируемая архитектура

// Полная система для обработки 10,000 RPS

// Frontend (CDN)
Client -> CloudFlare CDN (кеширует GET запросы)

// API Layer (Stateless)
           |
           +-> Load Balancer (распределяет запросы)
                |
                +-> API Server 1 (Node.js, stateless)
                +-> API Server 2 (Node.js, stateless)
                +-> API Server 3 (Node.js, stateless)
                +-> API Server N (Node.js, stateless)

// Database Layer
           |
           +-> Master DB (для write, в памяти кеш)
                |
                +-> Slave DB 1 (для read)
                +-> Slave DB 2 (для read)
                +-> Slave DB 3 (для read)

// Cache Layer (Redis)
API -> Redis (кеш часто запрашиваемых данных)
Redis -> [Master, Slave]

// Queue (для асинхронной обработки)
API -> RabbitMQ/Kafka
RabbitMQ -> [Worker 1, Worker 2, ..., Worker N]

// Monitoring & Logging
ELK Stack (Elasticsearch, Logstash, Kibana)

9. Ограничения и throttling

// Rate limiting: ограничить количество запросов
const rateLimit = require('express-rate-limit');

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 минут
  max: 100 // max 100 requests per windowMs
});

app.use('/api/', limiter);

// Помогает:
// - Защитить от DDoS атак
// - Справедливое распределение ресурсов
// - Предсказуемая нагрузка на сервер

// Более сложный лимит (через Redis)
const RedisStore = require('rate-limit-redis');
const redis = require('redis');

const limiter = rateLimit({
  store: new RedisStore({
    client: redis.createClient(),
    prefix: 'rl:' // rate limit prefix
  }),
  windowMs: 60000,
  max: 1000
});

// Все серверы видят единый счётчик в Redis

10. Мониторинг и метрики

// Чтобы масштабировать, нужно знать узкие места

// Метрики для мониторинга:
// - Requests per second (RPS)
// - Average response time
// - Error rate
// - Database query time
// - Cache hit rate
// - CPU/Memory usage per server

const metrics = {
  totalRequests: 0,
  totalErrors: 0,
  avgResponseTime: 0
};

app.use((req, res, next) => {
  const start = Date.now();
  
  res.on('finish', () => {
    metrics.totalRequests++;
    if (res.statusCode >= 400) {
      metrics.totalErrors++;
    }
    const duration = Date.now() - start;
    metrics.avgResponseTime = 
      (metrics.avgResponseTime + duration) / 2;
  });
  
  next();
});

// Отправить в систему мониторинга (Prometheus, Grafana)
setInterval(() => {
  prometheus.gauge('api_total_requests', metrics.totalRequests);
  prometheus.gauge('api_errors', metrics.totalErrors);
  prometheus.gauge('api_avg_response_ms', metrics.avgResponseTime);
}, 10000);

Итог: как REST масштабируется

REST масштабируется благодаря:

1. Statelessness — каждый сервер может обработать запрос
2. HTTP кеширование — уменьшает нагрузку на сервер
3. CDN — распределённая сеть серверов
4. Горизонтальное масштабирование — добавляем серверы
5. Репликация БД — распределяем нагрузку на чтение
6. Шардирование БД — распределяем нагрузку на запись
7. Асинхронная обработка — не блокируем ресурсы
8. Load Balancing — распределяем трафик
9. Версионирование — независимое развитие
10. Мониторинг — находим узкие места

На практике система с правильной REST архитектурой может обрабатывать от 1,000 до 1,000,000+ запросов в секунду.