Google PCD: Projektowanie API, integracja oraz programowanie sterowane zdarzeniami — Przewodnik do nauki

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Część Google Professional Cloud Developer — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Google, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Nowoczesna integracja aplikacji w Google Cloud łączy dobrze zaprojektowane synchroniczne API z odpornymi wzorcami asynchronicznymi i sterowanymi zdarzeniami. Celem jest zapewnienie jasnych kontraktów, silnej tożsamości, spójnej obsługi błędów i mechanizmów operacyjnych, które utrzymują niskie opóźnienia i wysoką dostępność nawet w warunkach awarii, skalowania czy zmian. Ta sekcja omawia wybór protokołów i API, bramki i uwierzytelnianie, przesyłanie komunikatów i routing zdarzeń, zadania w tle, orkiestrację, tożsamość i zaufanie między usługami, wzorce niezawodności, bezpieczne webhooki oraz bezpieczną ewolucję schematów.

Projektowanie i zarządzanie API

Wybierz odpowiedni protokół:

REST: Przyjazny dla człowieka, możliwy do buforowania przez HTTP, doskonały dla publicznych i partnerskich API. Stosuj projekt zorientowany na zasoby, standardowe metody, ETags i HATEOAS tylko wtedy, gdy przynosi to wartość. Kompromis: mniej precyzyjne kontrakty niż w protobuf; potencjalne pobieranie zbyt dużej lub zbyt małej ilości danych (over/under-fetching).
gRPC: Kontrakty Protobuf, dwukierunkowy streaming, wydajny transport binarny; doskonale pasuje do wewnętrznych wywołań między serwisami o niskim opóźnieniu. Kompromis: wsparcie w przeglądarkach wymaga gRPC-Web; obserwowalność i kompatybilność dla publicznych klientów mogą być trudniejsze.
GraphQL: Elastyczne zapytania, które redukują liczbę zapytań zwrotnych (round-trips) dla złożonych widoków. Kompromis: złożone resolvery, ryzyko problemu N+1, wyzwania związane z buforowaniem i niuanse kontroli dostępu.

Wersjonowanie i paginacja:

Preferuj addytywne, wstecznie kompatybilne zmiany. Używaj wersjonowania głównego opartego na URI (np. /v1), a dla mniejszych rewizji stosuj pola i flagi funkcyjne (feature flags). Wycofuj (deprecate) z jasno określonym harmonogramem.
Stronicuj przy użyciu stabilnych kursorów lub nextPageToken, aby uniknąć niespójnych stron w warunkach dużej zmienności danych (churn); unikaj paginacji opartej na offsecie dla dużych zbiorów danych.

Walidacja i błędy:

Używaj OpenAPI do walidacji schematów żądań/odpowiedzi REST oraz reguł walidacji protobuf dla gRPC.
Przyjmij spójny model błędów: mapuj na kanoniczne kody statusu HTTP; dla gRPC używaj google.rpc.Status (code, message, details). Dołączaj parsowalne maszynowo przyczyny błędów i identyfikator korelacji. Unikaj ujawniania wewnętrznych szczegółów implementacji.

Opcje zarządzania API:

API Gateway: Lekka, zarządzana bramka dla backendów OpenAPI/gRPC (Cloud Run, Cloud Functions, GKE, Compute Engine). Obsługuje uwierzytelnianie, klucze API, walidację JWT, limity (quotas). Dobra dla rozwiązań serverless i prostych płaszczyzn sterowania.
Cloud Endpoints (ESPv2): Wdrażany razem z Twoją usługą; obsługuje transkodowanie OpenAPI lub gRPC, uwierzytelnianie, limity i metryki. Dobre rozwiązanie, gdy preferowane jest umieszczenie proxy razem z obciążeniem roboczym.
Apigee: Pełne zarządzanie cyklem życia API z zaawansowanymi politykami (tłumienie nagłych skoków ruchu (spike arrest), limity, mediacja, transformacja, dostawcy OAuth, monetyzacja, portal deweloperski). Najlepsze dla złożonych ekosystemów partnerskich i kontroli ruchu północ-południe (north-south).

Uwierzytelnianie i limity (quotas):

Dla użytkowników końcowych: OAuth 2.0 lub Firebase Authentication; dla usług: podpisane przez Google tokeny ID (OIDC) lub tokeny OAuth konta serwisowego (2-legged).
Wymuszaj limity (quotas) i tłumienie nagłych skoków ruchu (spike arrest) blisko klientów (Apigee) oraz per konsument (klucze API lub poświadczenia klienta), aby chronić backendy.

Minimalny przykład OpenAPI dla API Gateway z backendem Cloud Run i OIDC:

openapi: 3.0.0
info: {title: orders, version: 1.0.0}
paths:
  /v1/orders:
    get:
      security: [{firebase: []}]
      x-google-backend: {address: https://orders-xyz-uc.a.run.app}
      responses: {"200": {description: OK}}
components:
  securitySchemes:
    firebase:
      type: http
      scheme: bearer
      bearerFormat: JWT
      x-google-issuer: https://securetoken.google.com/PROJECT_ID
      x-google-audiences: PROJECT_ID

Asynchroniczne przesyłanie komunikatów i zdarzeń

Podstawy Pub/Sub:

Tematy i subskrypcje oddzielają wydawców (publishers) od konsumentów (consumers). Dostarczanie jest co najmniej jednokrotne (at-least-once); mogą wystąpić duplikaty i zmiany kolejności.
Używaj potwierdzeń (acknowledgments) i wydłużaj termin potwierdzenia (ack deadline), gdy przetwarzanie jest długie; stosuj kontrolę przepływu po stronie klienta (client flow control), aby uniknąć presji na pamięć.
Kolejność: włącz kolejkowanie komunikatów i podaj klucz porządkujący (ordering key), aby zagwarantować dostarczanie w kolejności dla danego klucza; w miarę możliwości utrzymuj jednego aktywnego wydawcę na klucz.
Komunikaty nieprzetwarzalne (Dead letters): skonfiguruj tematy typu dead-letter, aby zawierały komunikaty-trucizny (poison messages) i zapobiegały niekończącym się ponowieniom; monitoruj je i analizuj.

Utwórz temat, subskrypcję i DLQ:

gcloud pubsub topics create orders
gcloud pubsub topics create orders-dlq
gcloud pubsub subscriptions create orders-sub \
  --topic=orders \
  --dead-letter-topic=orders-dlq \
  --max-delivery-attempts=5 \
  --ack-deadline=30

Logika konsumenta: zaimplementuj idempotentne handlery i deduplikację (np. po messageId lub kluczu idempotencji na poziomie aplikacji); ponawiaj próby przy błędach przejściowych z wycofywaniem wykładniczym (backoff); przenoś nienaprawialne komunikaty do DLQ i generuj alerty.

Eventarc i CloudEvents:

Eventarc kieruje zdarzenia z usług Google Cloud, niestandardowych źródeł i Dzienników Audytu (Audit Logs) do Cloud Run, Cloud Functions lub GKE. Zdarzenia używają koperty CloudEvents (id, source, type, subject, time).
Filtruj według atrybutów (type, subject, location) na poziomie triggera, aby zredukować szum i koszty. Używaj dedykowanych kont serwisowych w celu zapewnienia zasady najmniejszych uprawnień (least privilege).

Utwórz trigger Eventarc dla finalizacji obiektu w Cloud Storage:

gcloud eventarc triggers create index-new-objects \
  --destination-run-service=media-indexer \
  --destination-run-region=us-central1 \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=my-assets-bucket" \
  --service-account=eventarc-router@PROJECT_ID.iam.gserviceaccount.com

Kompromisy:

Pub/Sub jest zoptymalizowany pod kątem modelu pull i odporny na wysoką przepustowość; Eventarc upraszcza routing od producentów, których nie kontrolujesz, i używa modelu push do Twojej usługi ze standardowymi metadanymi.
Aby uzyskać ścisłą kolejność lub twarde limity kosztów, rozważ partycjonowanie i ograniczanie szybkości (rate-limiting) po stronie wydawców; dla bardzo niskich opóźnień przy rozsyłaniu (fanout), ostrożnie dostosuj współbieżność subskrybentów.

Orkiestracja, zadania w tle i procesy długotrwałe

Cloud Tasks:

Kolejki typu push do niezawodnych wywołań HTTP w tle. Ustaw szybkość wysyłania (dispatch rate) i współbieżność dla każdej kolejki, aby chronić backendy. Skonfiguruj ponowienia z wykładniczym wycofywaniem (exponential backoff) i maksymalną liczbą prób.
Zapewnij idempotencję za pomocą deterministycznej nazwy zadania lub nagłówka Idempotency-Key i deduplikuj po stronie serwera. Odpowiadaj szybko (kod 2xx) i w razie potrzeby wykonuj ciężką pracę asynchronicznie.

Utwórz kolejkę z limitami szybkości i ponowieniami:

gcloud tasks queues create payments-queue \
  --max-dispatches-per-second=50 \
  --max-concurrent-dispatches=200 \
  --max-attempts=10 \
  --min-backoff=5s \
  --max-backoff=300s

Workflows:

Orkiestruje wieloetapowe procesy biznesowe za pomocą złącz (connectors) HTTP i Google Cloud. Modeluj akcje kompensujące (wzorzec saga) dla częściowych niepowodzeń; unikaj transakcji rozproszonych.
Używaj limitów czasowych (timeouts) i polityk ponowień na poziomie kroku; utrwalaj stan między ponowieniami, aby móc wznowić działanie po awarii. Odpytuj (poll) długo działające operacje i anuluj je po przekroczeniu terminu.

Szkic kompensacji:

main:
  params: [orderId]
  steps:
  - charge:
      call: http.post
      args: {url: ${paymentsUrl}/charge, auth: {type: OIDC}, body: {orderId: ${orderId}}}
      result: chargeRes
  - reserveInventory:
      try:
        steps:
        - reserve:
            call: http.post
            args: {url: ${inventoryUrl}/reserve, auth: {type: OIDC}, body: {orderId: ${orderId}}}
      except:
        as: e
        steps:
        - refund:
            call: http.post
            args: {url: ${paymentsUrl}/refund, auth: {type: OIDC}, body: {paymentId: ${chargeRes.body.id}}}
        - raise: ${e}

Wskazówki operacyjne:

Preferuj Cloud Tasks dla zadań HTTP w tle typu „wystrzel i zapomnij” (fire-and-forget) z precyzyjną kontrolą szybkości do jednej usługi. Używaj Pub/Sub do rozsyłania (fanout) i obsługi wielu konsumentów. Używaj Workflows, gdy musisz koordynować kilka wywołań z logiką warunkową i kompensacją.

Tożsamość, niezawodność i integracje

Tożsamość między usługami i propagacja tokenów:

Obciążenia (workloads) w Cloud Run/Functions/Compute Engine/GKE powinny używać kont serwisowych z zasadą najmniejszych uprawnień. W GKE używaj Workload Identity, aby uniknąć poświadczeń na poziomie węzła.
W przypadku komunikacji między usługami Cloud Run, wywołuj je z tokenem ID, którego pole audience odpowiada docelowemu adresowi URL. Propaguj tożsamość tylko wtedy, gdy usługa podrzędna (downstream) musi działać w imieniu wywołującego; w przeciwnym razie używaj konta serwisowego usługi wywoływanej.

Pobieranie tokenu ID w Cloud Run:

AUD="https://inventory-xyz-uc.a.run.app"
TOKEN=$(curl -s -H "Metadata-Flavor: Google" \
  "http://metadata/computeMetadata/v1/instance/service-accounts/default/identity?audience=${AUD}")
curl -H "Authorization: Bearer ${TOKEN}" "${AUD}/v1/check"

Zależności synchroniczne i odporność na awarie:

Ustawiaj timeouty klienta niższe niż timeouty usług nadrzędnych (upstream); przydzielaj budżet czasowy na każdy przeskok (hop). Ponawiaj tylko operacje idempotentne, stosując obcięte wykładnicze ponawianie (truncated exponential backoff) z losowym opóźnieniem (jitter). Unikaj burz ponowień, ograniczając całkowity czas ponawiania.
Używaj mechanizmów circuit breaker, aby szybko przerywać operacje (fail fast), gdy usługa nadrzędna jest w złej kondycji; w GKE/Apigee/Envoy możesz skonfigurować maksymalną liczbę oczekujących żądań, wykluczanie instancji po awarii i sondy kondycji. Zapewnij sensowne rozwiązania zapasowe lub pogarszaj jakość usługi w kontrolowany sposób (graceful degradation).
Mapuj błędy przejściowe (429, 408, 500–503) na zachowania umożliwiające ponowienie; traktuj błędy 4xx (inne niż 408/429) jako niepodlegające ponowieniu.

Webhooki i integracje z systemami zewnętrznymi:

Weryfikuj żądania przychodzące za pomocą nagłówka z sygnaturą HMAC i współdzielonym kluczem (shared secret) lub podpisanego tokenu JWT; dla wyższego poziomu pewności użyj mTLS. Przechowuj sekrety w Secret Manager i regularnie je rotuj.
Szybko potwierdzaj odbiór; dodawaj zadania do kolejki w Cloud Tasks lub publikuj w Pub/Sub, aby odseparować ciężkie przetwarzanie. Ograniczaj liczbę zapytań (rate limiting) dla przychodzących adresów IP lub kluczy, aby chronić backendy.
Wychodzące webhooki: dołączaj nagłówek Idempotency-Key, aby umożliwić bezpieczne ponowienia, oraz weryfikuj zdalne certyfikaty TLS i nazwy hostów.

Ewolucja schematu i kompatybilność:

REST/JSON: dodawanie nowych pól jest bezpieczne; nigdy nie zmieniaj przeznaczenia, typu ani znaczenia istniejących pól. Oznaczaj pola jako przestarzałe (deprecated) i utrzymuj je przez określony czas.
Protobuf/gRPC: nigdy nie używaj ponownie numerów pól; używaj zarezerwowanych tagów; preferuj pola opcjonalne; domyślne wartości i semantyka obecności pól mają znaczenie dla kompatybilności.
Zdarzenia: dołączaj pole dataVersion i utrzymuj stabilność atrybutów CloudEvents; zarezerwuj miejsce na rozszerzenia. W przypadku Pub/Sub rozważ użycie Pub/Sub Schema (Avro/Protobuf) do walidacji w momencie publikacji.
Testowanie: używaj testów kontraktowych sterowanych przez konsumenta (consumer-driven contract tests), emulatorów (Pub/Sub, Datastore/Firestore) lub izolowanych projektów oraz wdrożeń kanarkowych (canary releases). Uruchamiaj testy integracyjne w CI, używając środowisk efemerycznych i realistycznych limitów (quotas), aby wykryć ukryte błędy.

Bezpieczeństwo i limity (quotas) na wszystkich poziomach stosu:

Wymuszaj uwierzytelnianie na brzegu sieci (edge) (API Gateway/Apigee/Endpoints) oraz w samej usłudze. Stosuj limity na klienta (per-consumer quotas) i mechanizmy spike arrest. Monitoruj skoki błędów 401/403 oraz wskaźniki błędów 429, aby dostosować polityki ponowień klienta i limity.
Loguj identyfikatory żądań (request IDs) we wszystkich komponentach i propaguj nagłówki śledzenia (Traceparent lub X-Cloud-Trace-Context) w celu zapewnienia obserwacji end-to-end.

Praktyczny scenariusz problemowy

Firma AcmeRetail buduje na Google Cloud usługę click-to-collect (zamów i odbierz). Aplikacja internetowa oparta na React wywołuje publiczne API w celu składania zamówień; usługi backendowe muszą rezerwować towar, pobierać płatności i powiadamiać sklepy. Zespół potrzebuje API o niskim opóźnieniu, niezawodnego przetwarzania w tle, aktualizacji sterowanych zdarzeniami oraz bezpiecznego wycofywania zmian w przypadku częściowych awarii.

Podejście:

Udostępnij publiczne API REST za pomocą API Gateway umieszczonego przed usługą zamówień w Cloud Run.

Uzasadnienie: REST z JSON jest prosty dla przeglądarek; API Gateway waliduje tokeny JWT z Firebase Auth, wymusza stosowanie kluczy API i limitów na klienta oraz kończy połączenie na brzegu sieci. Cloud Run automatycznie skaluje się wraz ze skokami ruchu.

Zaimplementuj komunikację między usługami za pomocą gRPC dla wewnętrznych gorących ścieżek (hot paths) (zamówienia do systemu inwentaryzacji, cennik).

Uzasadnienie: gRPC zmniejsza narzut na serializację i zapewnia ścisłe kontrakty. Użyj Workload Identity (GKE) lub kont serwisowych (Cloud Run) oraz OIDC między usługami. Timeouty są ustawione na 300 ms z dwoma ponowieniami i losowym opóźnieniem (jitter) dla idempotentnych odczytów.

Użyj Workflows do orkiestracji sagi zamówienia: pobranie płatności, rezerwacja towaru, utworzenie zadania odbioru; wykonanie akcji kompensujących w przypadku awarii.

Uzasadnienie: Scentralizowana orkiestracja zarządza długotrwałymi krokami i kompensacjami. Jeśli rezerwacja się nie powiedzie, Workflows uruchamia zwrot pieniędzy i zwraca kod 409 do klienta.

Publikuj zdarzenia domenowe do tematów Pub/Sub orders i inventory dla konsumentów podrzędnych (analityka, powiadomienia dla sklepów).

Uzasadnienie: Dystrybucja do wielu odbiorców (fanout) bez ścisłego powiązania. Subskrybenci implementują idempotencję na podstawie orderId. Subskrypcje mają tematy dead-letter z max-delivery-attempts=10, a alerty uruchamiają się przy wzroście liczby wiadomości w kolejce DLQ.

Uruchamiaj powiadomienia dla sklepów za pomocą Eventarc do usługi powiadamiającej w Cloud Run w odpowiedzi na odpowiednie zmiany w Cloud Storage i Firestore.

Uzasadnienie: Eventarc kieruje tylko potrzebne zdarzenia za pomocą filtrów atrybutów; CloudEvents zapewnia spójne metadane. Usługa powiadamiająca wysyła komunikaty do zewnętrznych dostawców SMS/e-mail za pomocą Cloud Tasks, aby kontrolować częstotliwość i ponowienia.

Obsługuj webhooki od dostawcy płatności za pomocą dedykowanego punktu końcowego w Cloud Run, poprzedzonego API Gateway, weryfikując sygnatury HMAC i używając Cloud Tasks do przetwarzania.

Uzasadnienie: Szybkie potwierdzenie z kodem 200 zmniejsza liczbę ponowień ze strony dostawcy; Tasks zapewnia ponowienia z wykładniczym czasem oczekiwania. Sekrety są przechowywane w Secret Manager; ciała żądań są walidowane względem schematu OpenAPI.

Wdróż wzorce niezawodności: mechanizmy circuit breaker w Apigee lub Envoy dla wywołań wychodzących do dostawcy płatności; timeouty klienta ustawione poniżej SLA dostawcy; ponowienia z obciętym wykładniczym czasem oczekiwania (truncated exponential backoff) dla błędów 429/5xx.

Uzasadnienie: Zapobiega awariom kaskadowym i burzom ponowień, respektuje limity systemów zewnętrznych i przekształca przejściowe przeciążenie w kontrolowane pogorszenie jakości usługi (graceful degradation).

Zastosuj kontrolę ewolucji schematu: Protobuf dla wewnętrznych usług gRPC z zarezerwowanymi polami; odpowiedzi REST używają addytywnych zmian w JSON; Pub/Sub wykorzystuje walidację schematu Protobuf w momencie publikacji.

Uzasadnienie: Utrzymuje kompatybilność z konsumentami. Testy kontraktowe i integracyjne są uruchamiane w Cloud Build przy każdym scaleniu (merge); wdrożenia kanarkowe (canary deploys) bezpiecznie walidują zmiany na rzeczywistym ruchu.

Obserwuj i operuj: propaguj nagłówki śledzenia między API Gateway a usługami; eksportuj metryki z Cloud Logging dotyczące wskaźników błędów i rozmiaru DLQ; ustawiaj alerty na wypalenie budżetu błędu (SLO burn) oraz anomalie w błędach 429/5xx.

Uzasadnienie: Szybkie wykrywanie regresji, problemów z limitami lub incydentów u dostawców; inżynierowie SRE mogą szybko dostosowywać limity i polityki ponowień.

← Compute · Wszystkie domeny · Dane aplikacji →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →