Что такое Stateful подход к разработке сервиса?

Что такое Stateful подход к разработке сервиса?

Stateful подход — это парадигма проектирования программного обеспечения, при которой сервис или приложение сохраняет состояние (state) между различными запросами или сессиями. Это означает, что сервис "помнит" данные о взаимодействиях с клиентом, такие как информация о пользовательской сессии, промежуточные результаты вычислений, данные о транзакциях или контекст выполнения. Состояние хранится в памяти процесса, на диске или в специализированных хранилищах, и каждый последующий запрос может зависеть от предыдущих.

Ключевые характеристики Stateful сервисов

• Зависимость от контекста: Обработка запроса зависит от сохранённого состояния, созданного ранее. Например, корзина покупок в интернет-магазине "помнит" добавленные товары.
• Привязка к экземпляру (Sticky Sessions): Запросы от одного клиента должны, как правило, попадать на тот же самый экземпляр сервиса (сервер, процесс, pod в Kubernetes), где хранится его состояние. Это часто требует использования механизмов балансировки нагрузки с поддержкой сессий (session affinity).
• Сложность горизонтального масштабирования: Добавление новых экземпляров сервиса усложняется, так как состояние, хранимое в памяти одного экземпляра, недоступно для других. Необходимо либо обеспечивать привязку клиентов, либо использовать внешние общие хранилища состояния.
• Повышенные требования к отказоустойчивости: Потеря экземпляра сервиса (из-за сбоя, перезагрузки) может привести к потере состояния всех его клиентов, если состояние не реплицировано или не сохранено надёжно.

Пример Stateful сервиса на Go

Рассмотрим упрощённый пример сервиса аутентификации с сессиями, где состояние (активные сессии) хранится в памяти.

package main

import (
    "fmt"
    "net/http"
    "sync"
    "time"
)

// Session представляет собой состояние пользовательской сессии.
type Session struct {
    Username string
    Expiry   time.Time
}

// IsExpired проверяет, истекло ли время жизни сессии.
func (s Session) IsExpired() bool {
    return s.Expiry.Before(time.Now())
}

// SessionStore — in-memory хранилище состояния сессий.
type SessionStore struct {
    sessions map[string]Session // map[sessionID]Session
    mu       sync.RWMutex       // Для безопасного конкурентного доступа
}

// NewSessionStore создаёт новое хранилище сессий.
func NewSessionStore() *SessionStore {
    return &SessionStore{
        sessions: make(map[string]Session),
    }
}

// Set сохраняет сессию в хранилище (сохраняем состояние).
func (ss *SessionStore) Set(sessionID string, session Session) {
    ss.mu.Lock()
    defer ss.mu.Unlock()
    ss.sessions[sessionID] = session
}

// Get получает сессию по ID (читаем состояние).
func (ss *SessionStore) Get(sessionID string) (Session, bool) {
    ss.mu.RLock()
    defer ss.mu.RUnlock()
    session, exists := ss.sessions[sessionID]
    return session, exists
}

var store = NewSessionStore()

func loginHandler(w http.ResponseWriter, r *http.Request) {
    username := r.FormValue("username")
    // В реальном приложении здесь должна быть проверка пароля.

    // Создаём новое состояние — сессию.
    sessionID := fmt.Sprintf("session_%d", time.Now().UnixNano())
    newSession := Session{
        Username: username,
        Expiry:   time.Now().Add(24 * time.Hour),
    }

    // Сохраняем состояние в памяти сервиса.
    store.Set(sessionID, newSession)

    // Отправляем sessionID клиенту (например, в куки).
    http.SetCookie(w, &http.Cookie{
        Name:    "session_id",
        Value:   sessionID,
        Expires: newSession.Expiry,
    })
    fmt.Fprintf(w, "Вы вошли как %s. SessionID: %s", username, sessionID)
}

func profileHandler(w http.ResponseWriter, r *http.Request) {
    // Извлекаем состояние на основе запроса клиента.
    cookie, err := r.Cookie("session_id")
    if err != nil {
        http.Error(w, "Сессия не найдена", http.StatusUnauthorized)
        return
    }

    session, exists := store.Get(cookie.Value)
    if !exists || session.IsExpired() {
        http.Error(w, "Сессия устарела или не существует", http.StatusUnauthorized)
        return
    }

    // Используем сохранённое состояние для формирования ответа.
    fmt.Fprintf(w, "Привет, %s! Это ваш профиль.", session.Username)
}

func main() {
    http.HandleFunc("/login", loginHandler)
    http.HandleFunc("/profile", profileHandler)
    fmt.Println("Сервер запущен на :8080")
    http.ListenAndServe(":8080", nil)
}

Анализ примера:

• SessionStore является stateful-компонентом. Он хранит состояние (активные сессии) в памяти (map[string]Session).
• loginHandler создаёт и сохраняет состояние для нового пользователя.
• profileHandler извлекает состояние по sessionID из куки и использует его для персонализации ответа. Запрос клиента не самодостаточен — ему требуется ранее созданное состояние.
• Проблемы:

    *   Если сервис перезапустить, все сессии в памяти будут потеряны.
    *   Если запустить два экземпляра этого сервиса за балансировщиком, сессия, созданная на первом экземпляре, не будет найдена на втором, что приведёт к ошибке аутентификации. Для решения этой проблемы в Stateful-архитектурах часто используются **внешние хранилища данных**, такие как **Redis** или **Memcached**, которые разделяются между всеми экземплярами сервиса.

Типичные сценарии использования Stateful подхода

• Сессии пользователя в веб-приложениях.
• Корзины покупок в e-commerce.
• Долгие фоновые процессы или вычисления, где необходимо хранить промежуточные результаты (например, рендеринг видео, сложные финансовые расчёты).
• Стриминг данных (например, WebSocket-соединения), где необходимо поддерживать постоянное соединение и контекст диалога.
• Традиционные реляционные базы данных (PostgreSQL, MySQL) — классические Stateful-системы, хранящие данные на диске.

Противоположность: Stateless подход

В противоположность Stateful, Stateless подход предполагает, что каждый запрос клиента содержит всю необходимую информацию для его обработки. Сервис не хранит состояние между запросами. Это значительно упрощает горизонтальное масштабирование (любой экземпляр может обработать любой запрос) и повышает отказоустойчивость (потеря экземпляра не ведёт к потере данных клиента). Состояние, если оно необходимо, выносится во внешние системы (базы данных, кэши, брокеры сообщений). Современные микросервисные архитектуры чаще стремятся к Stateless дизайну сервисов, оставляя Stateful только для специализированных компонентов (БД, кэши, стриминговые движки).

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