Проектирование инфраструктуры, DevOps-пайплайны и чистый веб-код

Когда веб-сервер начинает обрабатывать свыше 10,000 запросов в секунду (RPS), стандартная конфигурация nginx.conf из дистрибутива перестает справляться. Возникают таймауты 502/504, исчерпываются файловые дескрипторы, а ядро системы захлебывается в обработке сетевых пакетов. В этой статье мы пошагово разберем калибровку Nginx и сетевого стека Linux для достижения максимальной пропускной способности.

1. Тюнинг системных дескрипторов и worker-процессов

По умолчанию Nginx использует модель обработки событий на основе epoll в Linux. Основной параметр масштабирования — директива worker_processes. Рекомендуется ставить ее в значение auto, чтобы Nginx привязывался к числу доступных физических ядер CPU. Однако без правильного задания лимита дескрипторов worker_rlimit_nofile пул соединений упрется в потолок.

# Основной блок конфигурации nginx.conf
user nginx;
worker_processes auto;
worker_rlimit_nofile 65535;
pid /var/run/nginx.pid;

events {
    worker_connections 16384;
    use epoll;
    multi_accept on;
}

2. Буферизация и сброс пакетов на диск

Чтобы избежать медленной дисковой подсистемы при отдаче статики и снизить context switching между процессами, крайне важно активировать отправку через системный вызов sendfile, а также отключить буферизацию заголовков TCP через комбинацию опций tcp_nopush и tcp_nodelay:

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # Тайм-ауты соединений (предотвращение медленных атак)
    keepalive_timeout 30;
    client_header_timeout 10;
    client_body_timeout 10;
    send_timeout 10;

    # Размеры буферов для избежания I/O swap на диск
    client_body_buffer_size 128k;
    client_max_body_size 10m;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;
}

3. Gzip и сжатие на лету

Не устанавливайте степень сжатия gzip_comp_level выше 5 или 6. Прирост экономии трафика между уровнями 6 и 9 составляет доли процента, при этом утилизация центрального процессора возрастает почти экспоненциально.

За последние пару лет спецификации CSS сделали гигантский скачок вперед. Эра обязательного использования SASS/SCSS постепенно уходит в прошлое. Нативные вложенные стили (Native CSS Nesting), псевдокласс :has() (родительский селектор) и контейнерные запросы @container поддерживаются всеми современными браузерами и полностью меняют подход к архитектуре UI-компонентов.

1. Псевдокласс :has() как долгожданный родительский селектор

Раньше для стилизации родительской карточки в зависимости от состояния чекбокса или наличия изображения внутри требовался JavaScript. Теперь эта логика описывается чисто декларативно на уровне таблицы стилей:

/* Стилизовать карточку, если внутри нее есть выделенный элемент формы */
.user-card:has(input[type="checkbox"]:checked) {
    border-color: #58a6ff;
    background-color: rgba(56, 139, 253, 0.05);
    box-shadow: 0 0 0 2px #58a6ff;
}

/* Изменение сетки, если в блоке отсутствует сайдбар */
.page-layout:not(:has(.sidebar)) {
    grid-template-columns: 1fr;
    max-width: 800px;
}

2. Нативная вложенность (CSS Nesting)

Больше не нужны сборщики для написания вложенных правил селекторов. Стандартная спецификация W3C теперь полностью поддерживает синтаксис с амперсандом &:

.interactive-card {
    padding: 1.5rem;
    background: #161b22;

    &:hover {
        background: #21262d;

        & .card-title {
            color: #58a6ff;
        }
    }

    & > .card-badge {
        font-size: 0.75rem;
        font-weight: 600;
    }
}

Создание продакшн-образов контейнеров часто грешит типичными ошибками: огромный размер итогового артефакта (более 1 Гб для простого Node.js или Go сервиса), запуск приложений из-под root-пользователя и игнорирование слоев кэша при сборке в CI/CD пайплайнах.

1. Многоэтапная сборка (Multi-stage builds)

Главное правило микросервисного подхода — рабочий образ (production runtime) не должен содержать компиляторов, заголовочных файлов библиотек, менеджеров пакетов и исходного кода приложения. В runtime-образ копируется исключительно скомпилированный бинарный файл.

# --- ЭТАП 1: Компиляция приложения ---
FROM golang:1.24-alpine AS builder
WORKDIR /app

# Кэшируем загрузку зависимостей отдельно
COPY go.mod go.sum ./
RUN go mod download

# Копируем исходники и собираем статический бинарник
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-w -s" -o /server ./cmd/api

# --- ЭТАП 2: Минимальный production-образ ---
FROM alpine:3.20
WORKDIR /app

# Создание непривилегированного пользователя для запуска
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

COPY --from=builder /server /app/server

EXPOSE 8080
ENTRYPOINT ["/app/server"]

2. Порядок инструкций и сохранение кэша слоев

Docker кэширует каждый промежуточный слой. Если вы скопируете всю рабочую директорию COPY . . до выполнения команды установки зависимостей (например, npm install или pip install), то любое малейшее изменение текстового файла приведет к полной переустановке пакетов при каждой сборке. Всегда копируйте дескрипторы зависимостей (package.json, requirements.txt) первыми.