jsonscraper

Google Cloud API Gateway obsługuje już strumieniowanie: co sprawdzić przed migracją

Publiczna wersja zapoznawcza obsługuje SSE, WebSockets, gRPC i strumieniowe odpowiedzi HTTP. Najważniejsza zmiana dla zespołu to konieczność utworzenia osobnej bramy i skonfigurowania czasu życia połączenia.

Polityka redakcyjna Zgłoś błąd

Strumieniowy backend utrzymuje otwarte połączenie i przesyła dane partiami: na przykład SSE może wysyłać tekst odpowiedzi modelu w miarę jej generowania, a WebSocket umożliwia dwukierunkową komunikację. 22 października 2026 r. Google ogłosiło publiczną wersję zapoznawczą strumieniowania w Cloud API Gateway. Brama może przekazywać takie odpowiedzi i stosować do żądań standardowe reguły uwierzytelniania oraz narzędzia monitorowania; do testów trzeba utworzyć nową bramę z włączonym trybem strumieniowym.

Artykuł: Google Cloud API Gateway obsługuje już strumieniowanie: co sprawdzić przed migracją
Podsumowanie: 22 października 2026 r. Google ogłosiło publiczną wersję zapoznawczą strumieniowania w Cloud API Gateway. Sprawdzamy obsługiwane protokoły, ustawienia zachowane w konfiguracji API oraz sposób testowania SSE lub WebSocket na nowej bramie.
Rola obrazu: okładka — główna idea
Sekcja: 
Temat wizualny: brama API Google Cloud przekazująca pakiety zdarzeń SSE i dwukierunkowe połączenie WebSocket do b
© jsonscraper · ilustracja wygenerowana przez AI

W ogłoszeniu Google wymieniono SSE, strumieniowe odpowiedzi HTTP i kodowanie transferu chunked, WebSockets oraz serwerowe i dwukierunkowe strumieniowanie gRPC. Odpowiedzi HTTP są przekazywane klientowi w miarę napływania z backendu, także w formacie NDJSON. Dzięki temu trasy strumieniowe mogą pozostać za tą samą bramą API Gateway, która obsługuje już zwykłe żądania.

Co zmienia się w API i infrastrukturze

Operacje strumieniowe nie wymagają osobnego opisu API ani specjalnych rozszerzeń specyfikacji. W wersji zapoznawczej tryb strumieniowy ustawia się podczas tworzenia bramy za pomocą flagi --enable-streaming. Google informuje, że nadal dostępne są kontrole kluczy API i JWT, uwierzytelnianie backendu przy użyciu konta usługi, routing oraz integracja z Cloud Logging i Cloud Monitoring.

Wersja zapoznawcza wprowadza również przewidywalną nazwę hosta opartą na identyfikatorze bramy, numerze projektu i regionie. Przykładowy format adresu to GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev. Można go wcześniej umieścić w konfiguracji klienta lub CI. Ponowne utworzenie bramy z tym samym identyfikatorem, projektem i regionem zachowuje ten adres.

Testowanie bez przełączania ruchu produkcyjnego

  1. Wybierz istniejący backend. Zacznij od endpointu, który już wysyła SSE lub strumieniową odpowiedź HTTP. Dzięki temu łatwiej oddzielić zachowanie bramy od zmian w aplikacji.
  2. Utwórz osobną bramę. Tryb strumieniowy włącza się podczas tworzenia; nie można zmienić trybu istniejącej bramy. Użyj testowego identyfikatora i odpowiedniego regionu.
  3. Skonfiguruj limit czasu backendu. W przypadku SSE i strumieniowania HTTP domyślny czas żądania wynosi 15 sekund; strumień zostaje zamknięty po upływie ustawionego limitu. W konfiguracji OpenAPI ustaw dla backendu parametr deadline odpowiedni do danego scenariusza: dokumentacja dopuszcza dla bramy strumieniowej wartość do 3600 sekund. Uwzględnij też własny timeout backendu — na przykład Cloud Run może zamknąć połączenie wcześniej.
  4. Sprawdź protokół backendu. gRPC wymaga HTTP/2 (h2), a WebSockets — HTTP/1.1. SSE i strumieniowanie HTTP działają z HTTP/1.1 lub HTTP/2; Google zaleca HTTP/2 w tych scenariuszach.
  5. Sprawdź, czy dane docierają. Upewnij się, że klient otrzymuje pierwsze zdarzenia przed zakończeniem całej odpowiedzi. W przypadku WebSocket sprawdź komunikację w obu kierunkach i zaplanuj ponowne łączenie klientów po zakończeniu połączenia.
  6. Zweryfikuj zasady i metryki. Sprawdź uwierzytelnianie, logi i limity żądań na trasie strumieniowej. Metryka request latency obejmuje pełny czas trwania strumienia, dlatego osobno mierz po stronie klienta czas do pierwszego zdarzenia i odstępy między zdarzeniami.

W przypadku WebSockets i gRPC domyślny limit czasu bez wymiany wiadomości wynosi 300 sekund; dla WebSocket nie stosuje się limitu krótszego niż 300 sekund, a połączenie i tak zostaje zakończone najpóźniej po 3600 sekundach. W przypadku SSE i strumieniowego HTTP obowiązuje ustawiony limit czasu rzeczywistego (wall-clock deadline). Dlatego długi czas request latency sam w sobie nie pokazuje, jak szybko użytkownik zobaczył pierwszy fragment.

Ograniczenia publicznej wersji zapoznawczej

W chwili uruchomienia trybu strumieniowego nie można włączyć w Cloud Console ani Terraform. Bramy z włączonym strumieniowaniem nie są też zgodne z HTTP(S) Load Balancing i Serverless NEG, więc niestandardowe domeny zależne od tego rozwiązania są niedostępne. Google wymienia te funkcje jako planowane rozszerzenia okresu wersji zapoznawczej. Przed zaplanowaniem routingu produkcyjnego i automatyzacji sprawdź dokumentację konfiguracji strumieniowania.

Praktyczny pierwszy krok to skierowanie nowej bramy do istniejącego strumieniowego backendu, jawne ustawienie limitu czasu i porównanie bezpośredniego połączenia z trasą przez bramę. Zespół sprawdzi w ten sposób zgodność protokołu, uwierzytelnianie i rzeczywisty czas do pierwszego zdarzenia bez zmiany kontraktu API ani ruchu produkcyjnego.

People

No people listed for this article yet.

Keep readingGitHub CLI dodaje wygasające tokeny OAuth: jak włączyć i sprawdzić integracje
Read the next article

Zmień lekturę w działającą integrację

Poznaj API danych społecznościowych jsonscraper, testuj zapytania i buduj kolejne procesy.

Poznaj API