Чем является Nginx при одном домене и нескольких экземплярах сайта?

Архитектура веб-сервера с Nginx и несколькими экземплярами сайта на одном домене

В контексте одного домена и нескольких экземпляров сайта (или приложений), Nginx выполняет ключевую роль обратного прокси-сервера (reverse proxy), балансировщика нагрузки (load balancer) и иногда маршрутизатора запросов (request router). Это не просто веб-сервер для статики, а центральный диспетчер, распределяющий трафик между различными backend-экземплярами.

Основная функция: Reverse Proxy и Load Balancing

Когда у вас есть несколько экземпляров одного сайта (например, микросервисы, несколько серверов приложения для масштабирования), Nginx становится единой точкой входа для всех пользователей. Он принимает запросы по одному домену (например, example.com) и перенаправляет их на внутренние серверы.

upstream backend {
    server backend1.example.internal:3000;
    server backend2.example.internal:3000;
    server backend3.example.internal:3000;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

В этом примере:

• upstream backend определяет группу (пул) backend-серверов.
• proxy_pass http://backend перенаправляет все запросы к этому пулу.
• Nginx автоматически распределяет запросы между указанными серверами, реализуя балансировку нагрузки.

Способы балансировки нагрузки

Nginx поддерживает несколько алгоритмов распределения запросов:

• Round Robin (по умолчанию): Запросы распределяются последовательно по очереди между серверами.
• Weighted Round Robin: Серверам можно назначить вес. Сервер с весом 5 получит в 5 раз больше запросов, чем сервер с весом 1.

upstream backend {
    server backend1.example.internal:3000 weight=3;
    server backend2.example.internal:3000 weight=1;
}

• Least Connections: Запрос отправляется на сервер с наименьшим количеством активных соединений. Эффективно для предотвращения перегрузки отдельных экземпляров.
• IP Hash: Клиентский IP хэшируется, и клиент всегда направляется на один и тот же backend-сервер (полезно для сохранения сессии без внешнего хранилища сессий).

Роль маршрутизатора запросов (Routing)

Если "экземпляры сайта" представляют собой разные сервисы или части приложения (например, API, админка, основное приложение), Nginx может маршрутизировать запросы по пути URL.

server {
    listen 80;
    server_name example.com;

    # Все запросы к API направляем на специальный пул серверов API
    location /api/ {
        proxy_pass http://api_backend;
    }

    # Запросы к админке на отдельный сервер
    location /admin/ {
        proxy_pass http://admin_backend;
    }

    # Основное приложение
    location / {
        proxy_pass http://main_app_backend;
    }
}

Преимущества такой архитектуры

• Масштабируемость: Можно легко добавлять новые экземпляры сайта в upstream-пул для обработки роста трафика.
• Отказоустойчивость: Если один экземпляр падает, Nginx продолжит направлять запросы на работающие серверы (можно настроить max_fails и fail_timeout для автоматического исключения неработающих серверов).
• Упрощение клиентской логики: Клиенты (браузеры, мобильные приложения) работают с одним доменом и endpoint, не заботясь о внутренней структуре.
• Централизованное управление: В Nginx можно единообразно настроить SSL/TLS, защиту от DDoS (rate limiting), кэширование, компрессию, логирование, что упрощает администрирование.

Дополнительные возможности Nginx в этой роли

• Кэширование: Nginx может кэшировать ответы от backend-серверов, значительно снижая нагрузку на них.

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m;
location / {
    proxy_cache my_cache;
    proxy_pass http://backend;
}

• Health Checks: Можно настроить активные или пассивные проверки здоровья серверов в пуле для автоматического исключения неответствующих экземпляров.
• SSL Termination: Nginx принимает HTTPS-запросы, декодирует их и передает уже обычные HTTP-запросы на backend, централизируя и упрощая управление сертификатами.

Пример реальной конфигурации для микросервисов

Представим, что сайт myapp.com состоит из трех микросервисов: User Service, Product Service и Frontend Service.

upstream user_service {
    server user1.internal:8001;
    server user2.internal:8001;
}

upstream product_service {
    server product1.internal:8002;
}

upstream frontend_service {
    server frontend1.internal:3000;
    server frontend2.internal:3000;
}

server {
    listen 443 ssl;
    server_name myapp.com;
    ssl_certificate /etc/ssl/myapp.crt;
    ssl_certificate_key /etc/ssl/myapp.key;

    # Маршрутизация по префиксам пути
    location /api/users {
        proxy_pass http://user_service;
    }

    location /api/products {
        proxy_pass http://product_service;
    }

    # Все остальные запросы - на фронтенд
    location / {
        proxy_pass http://frontend_service;
    }
}

Таким образом, при одном домене и нескольких экземплярах сайта, Nginx выступает как высокопроизводительный и гибкий диспетчер трафика, обеспечивающий балансировку нагрузки, маршрутизацию, отказоустойчивость и централизованное управление для всей системы. Это превращает его из простого веб-сервера в критически важный компонент архитектуры современного веб-приложения.