Обратный прокси и API-шлюз

Прямой прокси против обратного: на чьей они стороне

Эти двое — зеркальные отражения, и разница в том, на чьей стороне прокси.

Прямой прокси (forward proxy) стоит перед клиентами и представляет их интернету. Корпоративный egress-прокси, VPN, исходящий прокси скрапера — сервер на той стороне видит адрес прокси, а не клиента. Он существует, чтобы служить клиенту: кэширование, фильтрация контента, анонимность, контроль исходящего.

Обратный прокси (reverse proxy) стоит перед серверами и представляет их интернету. Клиенты подключаются к обратному прокси, думая, что это и есть сервер; он пересылает к одному из нескольких бэкендов за ним. Он существует, чтобы служить серверной стороне: прячет топологию, терминирует TLS, кэширует ответы, сжимает и балансирует нагрузку. Каждый балансировщик из прошлого урока — это обратный прокси с привинченной политикой выбора сервера; nginx, Envoy и HAProxy — канонические примеры.

Мнемоника: прямой прокси защищает и обслуживает тех, кто делает запросы; обратный прокси защищает и обслуживает тех, кто на них отвечает.

Что API-шлюз добавляет сверху

Обратный прокси двигает запросы. API-шлюз (API gateway) — это обратный прокси, взявший на себя сквозные заботы прикладного уровня — то, что иначе переписывал бы каждый сервис (хук). Стандартный набор:

• Аутентификация и авторизация — проверить токен / API-ключ один раз на периметре, чтобы каждый сервис доверял уже аутентифицированной личности, а не перепроверял.
• Rate-limit и квоты — троттлить по клиенту/ключу/маршруту, защищая бэкенды от злоупотреблений и шумных соседей.
• Маршрутизация — отображать публичные пути на внутренние сервисы (/orders → order-service), часто с версией (/v2/...).
• Агрегация / композиция — разветвить один клиентский вызов на несколько бэкендов и сшить ответы, чтобы мобильный клиент делал один запрос вместо шести.
• Терминация TLS — завершать HTTPS на периметре, чтобы внутренние хопы были дешевле (уровень композиции — см. трек networking про то, как устроено рукопожатие TLS; здесь важно лишь где оно заканчивается).
• Наблюдаемость и трансформации — логирование, заголовки трассировки, переписывание запроса/ответа, трансляция протокола (REST ↔ gRPC).

Ценность реальна: сквозная политика живёт в одном месте, применяется единообразно, а клиенты видят один связный API вместо твоей оргструктуры.

Шлюз как узкое место и SPOF

Всё, что шлюз централизует, он же и концентрирует. Каждый запрос к каждому сервису течёт через него, поэтому:

• Это единая точка отказа. Если шлюз упал или сконфигурирован неверно, все сервисы за ним недостижимы, независимо от их собственного здоровья (опечатка в 2 ночи из хука). Митигация — плейбук балансировщика: запускать шлюз как избыточный, горизонтально масштабируемый пул за собственным балансировщиком с health-checks — никогда как один инстанс.
• Это узкое место по пропускной способности. Весь трафик плюс вся работа на запрос (парсинг токена, поиски rate-limit, TLS, агрегация) ложится на один уровень, который теперь должен масштабироваться впереди всех бэкендов вместе взятых.
• Это налог на задержку. Он добавляет хоп и CPU на запрос к каждому вызову. Обычно мало, но реально, и это на критическом пути всего.
• Это затор деплоя. Если конфиг маршрутизации каждой команды живёт в шлюзе, команда шлюза становится узким местом для релизов — организационная версия технического SPOF.

Альтернатива: sidecar / service mesh

Централизованный шлюз — одна форма; service mesh (сервисная сетка) — другая. Вместо единого центрального уровня сетка запускает маленький прокси (sidecar, например Envoy) рядом с каждым инстансом сервиса. Сквозные заботы для трафика сервис-к-сервису (east-west) — mTLS, ретраи, таймауты, circuit breaking, балансировка, трассировка — переезжают в sidecar’ы, конфигурируясь централизованно, но исполняясь локально. Нет единого прокси, через который обязан протекать весь внутренний трафик, поэтому SPOF и узкое место центрального уровня для east-west-вызовов в основном растворяются; цена — операционная сложность (прокси на каждый под, control plane для управления) и небольшая задержка на хоп от локального прокси.

Эти двое на практике не «или-или»: шлюз обычно ведёт north-south трафик (клиенты → платформа: аутентификация, публичные rate-limit, публичная поверхность API), а сетка ведёт east-west (сервис → сервис: mTLS, ретраи, внутренняя маршрутизация). Тянись к сетке, когда внутренний трафик между множеством сервисов — это место твоих проблем надёжности и безопасности; тянись к шлюзу, когда проблема — представить один безопасный, связный API наружу.