Google Cloud API Gateway добавил потоковую передачу: что проверить перед миграцией

Потоковый backend держит соединение открытым и передаёт данные частями: например, SSE может отправлять текст ответа модели по мере генерации, а WebSocket — вести обмен в обе стороны. 22 октября 2026 года Google объявила публичное превью потоковой передачи в Cloud API Gateway. Шлюз может пропускать такие ответы и применять к запросам привычные правила аутентификации и средства наблюдаемости; для проверки потребуется создать новый шлюз с включённым потоковым режимом.

В анонсе Google перечислены SSE, HTTP response streaming и chunked transfer encoding, WebSockets, а также серверная и двусторонняя потоковая передача gRPC. HTTP-ответы передаются клиенту по мере поступления от backend, включая NDJSON. Это позволяет оставить потоковые маршруты за тем же API Gateway, который уже обслуживает обычные запросы.

Что меняется в API и инфраструктуре

Для потоковых операций не требуется отдельное описание API или специальные расширения в спецификации. В превью потоковый режим задаётся при создании шлюза флагом --enable-streaming. Google указывает, что сохраняются проверки API key и JWT, аутентификация backend через service account, маршрутизация и интеграция с Cloud Logging и Cloud Monitoring.

Превью также вводит предсказуемое имя хоста на основе идентификатора шлюза, номера проекта и региона. Например, формат адреса — GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev. Его можно заранее подставить в конфигурацию клиента или CI. Повторное создание шлюза с теми же идентификатором, проектом и регионом сохраняет этот адрес.

Проверка без переключения production-трафика

1. Выберите существующий backend. Начните с endpoint, который уже отправляет SSE или потоковый HTTP-ответ: это поможет отделить поведение шлюза от изменений приложения.
2. Создайте отдельный шлюз. Включение потока фиксируется при создании; изменить режим существующего шлюза нельзя. Используйте тестовый идентификатор и подходящий регион.
3. Настройте backend deadline. Для SSE и потоковой передачи HTTP стандартный срок запроса составляет 15 секунд; поток закрывается, когда истекает заданный срок. В OpenAPI-конфигурации задайте для backend deadline, подходящий вашему сценарию: для потокового шлюза документация допускает значение до 3600 секунд. Учитывайте также собственный timeout backend — например, Cloud Run может закрыть соединение раньше.
4. Проверьте протокол backend. Для gRPC требуется HTTP/2 (h2), для WebSockets — HTTP/1.1. SSE и потоковая передача HTTP работают с HTTP/1.1 или HTTP/2; Google рекомендует HTTP/2 для этих сценариев.
5. Проверьте поступление данных. Убедитесь, что клиент получает первые события до завершения полного ответа. Для WebSocket проверьте обмен в обоих направлениях; продумайте переподключение клиентов после завершения соединения.
6. Сверьте политики и метрики. Проверьте аутентификацию, журналы и ограничения запросов на потоковом маршруте. Метрика request latency отражает полную длительность потока, поэтому отдельно измеряйте время до первого события и интервалы между событиями на клиенте.

Для WebSockets и gRPC документация задаёт интервал без сообщений в 300 секунд по умолчанию; для WebSocket срок менее 300 секунд не применяется, а соединение в любом случае завершается не позднее чем через 3600 секунд. Для SSE и потокового HTTP действует заданный wall-clock deadline. Поэтому долгий график request latency сам по себе не показывает, насколько быстро пользователь увидел первый фрагмент.

Ограничения публичного превью

При запуске потоковый режим нельзя включить через Cloud Console или Terraform. Также шлюзы с включённой потоковой передачей несовместимы с HTTP(S) Load Balancing и Serverless NEG, поэтому пользовательские домены, зависящие от этой схемы, недоступны. Google перечисляет такие возможности как будущие дополнения периода превью. Перед планированием production-маршрутизации и автоматизации сверяйте документацию по настройке streaming.

Практический первый шаг — направить новый шлюз на существующий потоковый backend, явно настроить deadline и сравнить прямое подключение с маршрутом через шлюз. Так команда проверит совместимость протокола, аутентификацию и реальное время до первого события, не меняя контракт API и production-трафик.