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

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

В анонсе Google перечислены SSE, потоковая передача HTTP-ответов и кодирование передачи по частям, WebSockets, а также серверная и двусторонняя потоковая передача gRPC. HTTP-ответы, в том числе NDJSON, передаются клиенту по мере поступления от backend. Это позволяет оставить потоковые маршруты за тем же 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. Настройте deadline backend. Для SSE и потоковой передачи HTTP стандартный срок запроса составляет 15 секунд; поток закрывается по истечении заданного срока. В конфигурации OpenAPI укажите для backend значение deadline, подходящее вашему сценарию: для потокового шлюза документация допускает срок до 3600 секунд. Учитывайте и собственный тайм-аут 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 действует заданный срок по настенным часам. Поэтому высокая длительность request latency сама по себе не показывает, насколько быстро пользователь увидел первый фрагмент.

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

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

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