Почему был выбран механизм балансировки сессий вместо использования JWT?

Сравнение механизмов балансировки сессий и JWT-токенов

Выбор между балансировкой сессий и JWT (JSON Web Tokens) зависит от требований к архитектуре, производительности и безопасности приложения. В нашем случае выбор сессий с балансировкой был обусловлен несколькими ключевыми факторами.

Архитектурные требования и состояние приложения

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

• Хранение состояния на сервере критически важно для бизнес-логики
• Необходимы сложные сессионные данные: корзина покупок, многоэтапные формы, временные расчеты
• Существуют строгие требования к инвалидации сессий в реальном времени

// Пример сессионных данных в нашем приложении
$_SESSION['user'] = [
    'id' => 12345,
    'role' => 'premium',
    'cart' => [
        'items' => [...],
        'total' => 999.99,
        'discounts' => [...]
    ],
    'checkout_step' => 2,
    'temporary_data' => [...]
];

Преимущества балансировки сессий в нашем контексте

1. Мгновенная инвалидация сессий

   • Возможность немедленно разлогинить пользователя при подозрительной активности
   • Централизованное управление сессиями через административную панель

2. Безопасность и контроль

   • Серверный контроль всех сессионных данных
   • Защита от replay-атак через серверную валидацию
   • Полный аудит действий пользователя

3. Работа с файловой системой и кэшем

   • Использование Redis/Memcached для хранения сессий с высокой доступностью
   • Возможность сложных выборок по сессионным данным

// Конфигурация сессий в нашем проекте
ini_set('session.save_handler', 'redis');
ini_set('session.save_path', 'tcp://redis:6379?auth=secret&database=0');

// Механизм привязки сессии к IP для безопасности
function bindSessionToIp($sessionId, $userIp) {
    $fingerprint = hash('sha256', $sessionId . $userIp . SECRET_KEY);
    $_SESSION['security']['fingerprint'] = $fingerprint;
    $_SESSION['security']['ip'] = $userIp;
}

Почему JWT не подошел для нашего случая

1. Требования к сессионным данным превышали рекомендуемый размер JWT (обычно до 4KB)
2. Отсутствие мгновенной инвалидации - для отзыва JWT требуется сложная инфраструктура blacklist'ов
3. Сложность реализации для наших сценариев:
   • Многоуровневые роли и разрешения
   • Временные ограничения на определенные действия
   • Кросс-доменные сценарии отсутствовали

// Проблемы с JWT в нашем контексте
// 1. Раздутые токены при сложных данных
$payload = [
    'user' => $userData, // 2-3KB данных
    'permissions' => [...], // +1KB
    'cart' => [...], // +5KB - ПРЕВЫШЕНИЕ!
];

// 2. Проблемы с отзывом токена
class JwtBlacklist {
    private $redis;
    
    public function revokeToken($jti, $exp) {
        // Хранение blacklist почти как сессий
        $this->redis->setex("blacklist:$jti", $exp - time(), '1');
    }
}

Балансировка и кластеризация

Для обеспечения отказоустойчивости мы реализовали:

1. Sticky sessions на уровне балансировщика (Nginx + HAProxy)
2. Репликацию Redis для сессионных данных между дата-центрами
3. Ленивую загрузку сессий для оптимизации производительности

# Конфигурация Nginx для sticky sessions
upstream backend {
    hash $cookie_phpsessid consistent;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

Компромиссы и альтернативы

Мы осознаем недостатки нашего подхода:

• Сложность масштабирования горизонтально
• Зависимость от центрального хранилища сессий
• Дополнительные сетевые запросы к хранилищу сессий

Однако для нашего целевого трафика (100-500k активных пользователей) и бизнес-требований этот подход оказался оптимальным. Мы предусмотрели возможность миграции на гибридную модель в будущем, где JWT будут использоваться для API, а сессии - для основного веб-приложения.

Заключение

Выбор механизма балансировки сессий вместо JWT был архитектурным решением, основанным на конкретных требованиях проекта: необходимость сложных серверных состояний, требований к безопасности и инвалидации, а также отсутствия потребности в полностью статус-лесс архитектуре. Каждый подход имеет свои сильные стороны, и выбор зависит от конкретного контекста приложения.