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. Повторное создание шлюза с теми же идентификатором, проектом и регионом сохраняет этот адрес.

Проверка без переключения производственного трафика

1. Выберите существующий backend. Начните с конечной точки, которая уже отправляет SSE или потоковый HTTP-ответ: так вы отделите поведение шлюза от изменений приложения.
2. Создайте отдельный шлюз. Потоковый режим включается при создании; изменить режим существующего шлюза нельзя. Используйте тестовый идентификатор и подходящий регион.
3. Настройте срок ожидания 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. Сверьте политики и метрики. Проверьте аутентификацию, журналы и ограничения запросов на потоковом маршруте. Метрика задержки запроса отражает полную длительность потока, поэтому отдельно измеряйте на клиенте время до первого события и интервалы между событиями.

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

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

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

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