Google PCD: Проектирование API, интеграция и событийно-ориентированная разработка — Руководство по подготовке

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

Часть Google Professional Cloud Developer — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Google, или пройдите тесты на время на ExamRoll.io.

Обзор

Современная интеграция приложений в Google Cloud сочетает в себе хорошо спроектированные синхронные API с отказоустойчивыми асинхронными и событийно-ориентированными паттернами. Цель состоит в том, чтобы обеспечить четкие контракты, строгую идентификацию, последовательную обработку ошибок и операционные элементы управления, которые поддерживают низкую задержку и высокую доступность даже в условиях сбоев, масштабирования или изменений. В этом разделе рассматриваются выбор протоколов и API, шлюзы и аутентификация, маршрутизация сообщений и событий, фоновые задачи, оркестрация, идентификация и доверие между сервисами, паттерны надежности, безопасные веб-хуки и безопасное развитие схем.

Проектирование и управление API

Выберите правильный протокол:

REST: Удобен для человека, кэшируется через HTTP, отлично подходит для публичных и партнерских API. Используйте ресурсо-ориентированный дизайн, стандартные методы, ETags и HATEOAS только тогда, когда это действительно ценно. Компромисс: менее точные контракты, чем у protobuf; потенциальная избыточная/недостаточная выборка данных.
gRPC: Контракты на основе Protobuf, двунаправленная потоковая передача, эффективный бинарный транспорт; отлично подходит для внутренних вызовов между сервисами с низкой задержкой. Компромисс: поддержка в браузерах требует gRPC-Web; наблюдаемость и совместимость для публичных клиентов могут быть сложнее.
GraphQL: Гибкие запросы, которые сокращают количество обращений к серверу для составных представлений. Компромисс: сложные резолверы, риски проблемы N+1, трудности с кэшированием и нюансы контроля доступа.

Версионирование и пагинация:

Предпочитайте аддитивные, обратно совместимые изменения. Используйте мажорные версии в URI (например, /v1) и минорные ревизии через поля и флаги функций. Объявляйте о прекращении поддержки с четкими сроками.
Для пагинации используйте стабильные курсоры или nextPageToken, чтобы избежать несогласованных страниц при изменениях данных; избегайте использования смещения (offset) для больших наборов данных.

Валидация и ошибки:

Используйте OpenAPI для схем запросов/ответов REST и правила валидации protobuf для gRPC.
Применяйте единую модель ошибок: сопоставляйте с каноническими кодами состояния HTTP; для gRPC используйте google.rpc.Status (code, message, details). Включайте машиночитаемые причины ошибок и идентификатор корреляции. Избегайте утечки внутренних деталей.

Варианты управления API:

API Gateway: Легковесный управляемый шлюз для бэкендов на OpenAPI/gRPC (Cloud Run, Cloud Functions, GKE, Compute Engine). Поддерживает аутентификацию, ключи API, валидацию JWT, квоты. Хорошо подходит для бессерверных архитектур и простых панелей управления.
Cloud Endpoints (ESPv2): Развертывается вместе с вашим сервисом; поддерживает транскодирование OpenAPI или gRPC, аутентификацию, квоты и метрики. Хорош, когда предпочтительно совместное размещение прокси с рабочей нагрузкой.
Apigee: Полноценное управление жизненным циклом API с расширенными политиками (защита от всплесков трафика, квоты, медиация, трансформация, провайдеры OAuth, монетизация, портал для разработчиков). Лучший выбор для сложных партнерских экосистем и управления трафиком север-юг.

Аутентификация и квоты:

Для конечных пользователей: OAuth 2.0 или Firebase Authentication; для сервисов: ID-токены, подписанные Google (OIDC), или токены сервисного аккаунта OAuth (2-legged).
Применяйте квоты и защиту от всплесков трафика (spike arrest) как можно ближе к клиентам (Apigee) и для каждого потребителя (по ключам API или учетным данным клиента), чтобы защитить бэкенды.

Минимальный пример OpenAPI для API Gateway с бэкендом на Cloud Run и 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

Асинхронный обмен сообщениями и событиями

Основы Pub/Sub:

Темы и подписки разделяют издателей и потребителей. Доставка осуществляется по принципу “как минимум один раз”; могут возникать дубликаты и изменения порядка.
Используйте подтверждения (acknowledgments) и продлевайте сроки подтверждения (ack deadlines) при длительной обработке; применяйте управление потоком на стороне клиента (flow control), чтобы избежать избыточной нагрузки на память.
Упорядочивание: включите упорядочивание сообщений и предоставьте ключ упорядочивания, чтобы гарантировать доставку в нужном порядке для каждого ключа; по возможности используйте одного активного издателя на ключ.
Недоставленные сообщения: настройте темы недоставленных сообщений (dead-letter topics) для изоляции “вредоносных” сообщений (‘poison messages’) и предотвращения бесконечных повторных попыток; отслеживайте и разбирайте их.

Создание темы, подписки и 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

Логика потребителя: реализуйте идемпотентные обработчики и дедупликацию (например, по messageId или ключу идемпотентности на уровне приложения); повторяйте временные ошибки с экспоненциальной задержкой; перемещайте невосстановимые сообщения в DLQ и оповещайте об этом.

Eventarc и CloudEvents:

Eventarc маршрутизирует события от сервисов Google Cloud, пользовательских источников и Audit Logs в Cloud Run, Cloud Functions или GKE. События используют конверт CloudEvents (id, source, type, subject, time).
Фильтруйте по атрибутам (type, subject, location) на уровне триггера, чтобы уменьшить шум и затраты. Используйте выделенные сервисные аккаунты для соблюдения принципа минимальных привилегий.

Создание триггера Eventarc для финализации объекта в 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

Компромиссы:

Pub/Sub оптимизирован для модели pull и отказоустойчив при высокой пропускной способности; Eventarc упрощает маршрутизацию от производителей, которых вы не контролируете, и использует push-доставку в ваш сервис со стандартизированными метаданными.
Для строгого порядка или жестких ограничений на затраты рассмотрите возможность партиционирования и ограничения скорости на стороне издателей; для веерной рассылки (fanout) с очень низкой задержкой тщательно настраивайте параллелизм подписчиков.

Оркестрация, фоновые задачи и длительные процессы

Cloud Tasks:

Очереди с push-доставкой для надежного выполнения фоновых HTTP-вызовов. Устанавливайте для каждой очереди скорость отправки и количество одновременных выполнений, чтобы защитить бэкенды. Настраивайте повторные попытки с экспоненциальной задержкой и максимальным количеством попыток.
Обеспечьте идемпотентность с помощью детерминированного имени задачи или заголовка Idempotency-Key и выполняйте дедупликацию на стороне сервера. Отвечайте быстро (2xx) и, при необходимости, выполняйте тяжелую работу асинхронно.

Создание очереди с ограничением скорости и повторными попытками:

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:

Оркестрирует многошаговые бизнес-процессы с использованием HTTP и коннекторов Google Cloud. Моделируйте компенсирующие действия (паттерн Saga) для частичных сбоев; избегайте распределенных транзакций.
Используйте тайм-ауты на уровне шагов и политики повторных попыток; сохраняйте состояние между попытками, чтобы можно было возобновить работу после сбоев. Опрашивайте длительные операции и отменяйте их по истечении крайнего срока.

Схема компенсации:

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}

Операционные рекомендации:

Предпочитайте Cloud Tasks для фоновых HTTP-запросов по принципу “отправил и забыл” (‘fire-and-forget’) с точным контролем скорости для одного сервиса. Используйте Pub/Sub для веерной рассылки и множества потребителей. Используйте Workflows, когда необходимо координировать несколько вызовов с логикой ветвления и компенсации.

Идентификация, надежность и интеграции

Идентификация и передача токенов между сервисами:

Рабочие нагрузки в Cloud Run/Functions/Compute Engine/GKE должны использовать сервисные аккаунты с минимально необходимыми привилегиями. В GKE используйте Workload Identity, чтобы избежать использования учетных данных на уровне узлов.
Для вызовов между сервисами Cloud Run используйте ID-токен, у которого поле audience соответствует URL-адресу целевого сервиса. Передавайте идентификационные данные только тогда, когда нижестоящий сервис должен действовать от имени вызывающего; в противном случае используйте сервисный аккаунт вызываемого сервиса.

Получение ID-токена в 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"

Синхронные зависимости и отказоустойчивость:

Устанавливайте таймауты на клиенте ниже, чем таймауты вышестоящих сервисов; закладывайте бюджет времени на каждый переход (hop). Повторяйте только идемпотентные операции, используя усеченную экспоненциальную выдержку (truncated exponential backoff) с джиттером. Избегайте штормов повторных запросов, ограничивая общее время на повторные попытки.
Используйте прерыватели цепи (circuit breakers) для быстрого отказа, когда вышестоящий сервис неработоспособен; в GKE/Apigee/Envoy можно настроить максимальное количество ожидающих запросов, исключение узла при сбое и проверки работоспособности. Предусмотрите разумные запасные варианты или обеспечьте плавную деградацию.
Сопоставляйте временные ошибки (429, 408, 500–503) с поведением, допускающим повторные попытки; рассматривайте ошибки 4xx (кроме 408/429) как не подлежащие повторению.

Веб-хуки и интеграции со сторонними системами:

Проверяйте входящие запросы с помощью заголовка с HMAC-подписью и общим секретом или подписанного JWT; для более высокой надежности используйте mTLS. Храните секреты в Secret Manager и регулярно их ротируйте.
Быстро подтверждайте получение; ставьте в очередь в Cloud Tasks или публикуйте в Pub/Sub, чтобы отделить ресурсоемкую обработку. Ограничивайте частоту запросов для входящих IP-адресов или ключей, чтобы защитить бэкенды.
Исходящие веб-хуки: включайте заголовок Idempotency-Key для безопасных повторных попыток и проверяйте удаленные TLS-сертификаты и имена хостов.

Эволюция схемы и совместимость:

REST/JSON: добавление новых полей безопасно; никогда не переназначайте и не изменяйте тип/значение существующих полей. Помечайте поля как устаревшие и продолжайте поддерживать их в течение определенного периода.
Protobuf/gRPC: никогда не используйте повторно номера полей; используйте зарезервированные теги; отдавайте предпочтение опциональным полям; семантика значений по умолчанию и наличия поля важна для совместимости.
События: включайте dataVersion и сохраняйте атрибуты CloudEvents стабильными; зарезервируйте место для расширений. При использовании Pub/Sub рассмотрите возможность применения Pub/Sub Schema (Avro/Protobuf) для валидации на этапе публикации.
Тестирование: используйте контрактное тестирование на стороне потребителя (consumer-driven contract tests), эмуляторы (Pub/Sub, Datastore/Firestore) или изолированные проекты, а также канареечные развертывания. Запускайте интеграционные тесты в CI, используя эфемерные окружения и реалистичные квоты, чтобы выявить скрытые сбои.

Безопасность и квоты на всех уровнях стека:

Применяйте аутентификацию на границе сети (API Gateway/Apigee/Endpoints) и на уровне сервиса. Применяйте квоты для каждого потребителя и защиту от всплесков трафика (spike arrest).
Отслеживайте всплески ошибок 401/403 и частоту ошибок 429, чтобы настраивать экспоненциальную выдержку на клиентах и квоты.
Логируйте идентификаторы запросов во всех компонентах и передавайте заголовки трассировки (Traceparent или X-Cloud-Trace-Context) для сквозной наблюдаемости.

Практический сценарий

Компания AcmeRetail создает сервис «закажи и забери» (click-to-collect) на платформе Google Cloud. Веб-приложение на React вызывает публичный API для размещения заказов; бэкенд-сервисы должны резервировать товары на складе, проводить оплату и уведомлять магазины. Команде требуются API с низкой задержкой, надежная фоновая обработка, обновления на основе событий и безопасный откат при частичных сбоях.

Подход:

Открыть публичный REST API через API Gateway, который будет работать перед сервисом заказов на Cloud Run.

Обоснование: REST с JSON прост для браузеров; API Gateway проверяет JWT от Firebase Auth, применяет API-ключи и квоты для каждого клиента и терминирует TLS на границе сети. Cloud Run автоматически масштабируется при всплесках трафика.

Реализовать вызовы между сервисами с помощью gRPC для внутренних «горячих» путей (от сервиса заказов к сервисам инвентаризации, ценообразования).

Обоснование: gRPC уменьшает накладные расходы на сериализацию и обеспечивает строгие контракты. Использовать Workload Identity (в GKE) или сервисные аккаунты (в Cloud Run) и OIDC для взаимодействия между сервисами. Таймауты установлены на 300 мс с двумя повторными попытками и джиттером для идемпотентных операций чтения.

Использовать Workflows для оркестрации саги заказа: списать оплату, зарезервировать товар, создать задачу на самовывоз; выполнить компенсирующие транзакции при сбое.

Обоснование: Централизованная оркестрация управляет длительными шагами и компенсациями. Если резервирование не удается, Workflows инициирует возврат средств и возвращает клиенту ошибку 409.

Публиковать доменные события в топики Pub/Sub orders и inventory для нижестоящих потребителей (аналитика, уведомления для магазинов).

Обоснование: Веерная рассылка без жесткой связи. Подписчики реализуют идемпотентность по ключу orderId. У подписок есть темы недоставленных сообщений (dead-letter topics) с max-delivery-attempts=10, и настроены оповещения на рост DLQ.

Инициировать уведомления для магазинов через Eventarc, направляя их в сервис-уведомитель на Cloud Run при соответствующих изменениях в Cloud Storage и Firestore.

Обоснование: Eventarc маршрутизирует только нужные события, используя фильтры по атрибутам; CloudEvents обеспечивает согласованность метаданных. Уведомитель отправляет сообщения сторонним SMS/Email-провайдерам, используя Cloud Tasks для контроля частоты и повторных попыток.

Обрабатывать веб-хуки от платежного провайдера с помощью выделенной конечной точки на Cloud Run, расположенной за API Gateway, проверяя HMAC-подписи и используя Cloud Tasks для обработки.

Обоснование: Быстрый ответ 200 OK сокращает количество повторных попыток от провайдера; Tasks обеспечивает повторные попытки с экспоненциальной выдержкой. Секреты хранятся в Secret Manager; тела запросов валидируются по схеме OpenAPI.

Внедрить паттерны надежности: прерыватели цепи (circuit breakers) в Apigee или Envoy для исходящих вызовов к платежному провайдеру; клиентские таймауты установлены ниже SLA провайдера; повторные попытки с усеченной экспоненциальной выдержкой для ошибок 429/5xx.

Обоснование: Предотвращает каскадные сбои и штормы повторных запросов, соблюдает лимиты сторонних систем и превращает временную перегрузку в плавную деградацию.

Внедрить контроль эволюции схем: Protobuf для внутреннего gRPC с зарезервированными полями; в REST-ответах использовать аддитивные изменения JSON; в Pub/Sub использовать валидацию схемы Protobuf на этапе публикации.

Обоснование: Поддерживает совместимость с потребителями. Контрактные и интеграционные тесты запускаются в Cloud Build при каждом слиянии веток; канареечные развертывания безопасно проверяют работу на реальном трафике.

Наблюдать и эксплуатировать: передавать заголовки трассировки между API Gateway и сервисами; экспортировать метрики из Cloud Logging для отслеживания частоты ошибок и размера DLQ; настроить оповещения на исчерпание бюджета ошибок SLO и аномалии с ошибками 429/5xx.

Обоснование: Быстрое обнаружение регрессий, проблем с квотами или инцидентов у провайдера; SRE-инженеры могут оперативно настраивать квоты и политики повторных запросов.

← Вычислительные ресурсы · Все домены · Данные приложений →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →