Ta strona została przetłumaczona przez Cloud Translation API.

Buforuj żądania HTTP za pomocą Cloud Tasks

1. Wprowadzenie

Cloud Tasks to w pełni zarządzana usługa kolejek, która służy do zarządzania wykonywaniem, wysyłaniem i dostarczaniem dużej liczby zadań.

Cloud Tasks umożliwia wydzielenie części zadań nazywanych zadaniami, które można wykonywać niezależnie (np. zadanie aktualizacji wpisu w bazie danych) poza głównym przepływem aplikacji i wysłać je do przetworzenia asynchronicznie za pomocą utworzonych przez Ciebie modułów obsługi.

Wyładowane zadanie jest dodawane do kolejki, która utrzymuje je do czasu jego pomyślnego wykonania lub wystąpienia błędu. Zależnie od konfiguracji kolejka może też pełnić funkcję sterowania przepływem wysyłki. Następnie tworzysz i konfigurujesz kolejkę, którą zarządza usługa Cloud Tasks. Po dodaniu zadań kolejka wysyła je i dba o niezawodność przetwarzania przez instancje robocze.

Oto niektóre z głównych funkcji Cloud Tasks:

Cele HTTP: możesz w bezpieczny sposób dodawać zadania kierowane na dowolną usługę HTTP działającą w Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Functions oraz systemach lokalnych, korzystając ze standardowego uwierzytelniania OAuth/OIDC.
Usuwanie duplikatów zadań: zadania dodane wiele razy są wysyłane tylko raz.
Gwarantowana dostawa: zadania są gwarantowane co najmniej raz, a większość zadań jest wykonywana dokładnie raz.
Ustawienia częstotliwości i ponownych prób: określ częstotliwość wysyłania zadań, maksymalną liczbę prób i minimalny czas oczekiwania między próbami.
Planowanie w przyszłości: możesz kontrolować godzinę uruchamiania zadania.

Z tego ćwiczenia w Codelabs dowiesz się, jak utworzyć zwykłą kolejkę Cloud Tasks i używać jej do obsługi zadań docelowych HTTP. Następnie dowiesz się, jak zastąpić identyfikator URI HTTP na poziomie kolejki i jak korzystać z nowego interfejsu API BufferTask, by łatwiej buforować żądania HTTP za pomocą Cloud Tasks.

Czego się nauczysz

Jak tworzyć zadania docelowe HTTP.
Jak tworzyć zadania docelowe HTTP z nowym zastąpieniem identyfikatora URI HTTP na poziomie kolejki.
Jak zmienić oczekujące zadania za pomocą nowego zastąpienia identyfikatora URI HTTP na poziomie kolejki.
Jak łatwiej buforować żądania HTTP przy użyciu nowego interfejsu API BufferTask.

2. Konfiguracja i wymagania

Samodzielne konfigurowanie środowiska

Zaloguj się w konsoli Google Cloud i utwórz nowy projekt lub wykorzystaj już istniejący. Jeśli nie masz jeszcze konta Gmail ani Google Workspace, musisz je utworzyć.

Nazwa projektu jest wyświetlaną nazwą uczestników tego projektu. To ciąg znaków, który nie jest używany przez interfejsy API Google. W każdej chwili możesz ją zaktualizować.
Identyfikator projektu jest unikalny we wszystkich projektach Google Cloud i nie można go zmienić (po jego ustawieniu nie można go zmienić). Cloud Console automatycznie wygeneruje unikalny ciąg znaków. zwykle nieważne, co ona jest. W większości ćwiczeń w Codelabs musisz podać swój identyfikator projektu (zwykle identyfikowany jako PROJECT_ID). Jeśli nie podoba Ci się wygenerowany identyfikator, możesz wygenerować kolejny losowy. Możesz też spróbować własnych sił i sprawdzić, czy jest dostępna. Po wykonaniu tej czynności nie można jej już zmienić. Pozostanie ona przez cały czas trwania projektu.
Jest jeszcze trzecia wartość, numer projektu, z którego korzystają niektóre interfejsy API. Więcej informacji o wszystkich 3 wartościach znajdziesz w dokumentacji.

Następnie musisz włączyć płatności w Cloud Console, aby korzystać z zasobów Cloud/interfejsów API. Ukończenie tego ćwiczenia z programowania nic nie kosztuje. Aby wyłączyć zasoby w celu uniknięcia naliczania opłat po zakończeniu tego samouczka, możesz usunąć utworzone zasoby lub projekt. Nowi użytkownicy Google Cloud mogą skorzystać z programu bezpłatnego okresu próbnego o wartości 300 USD.

Uruchamianie Cloud Shell

Google Cloud można obsługiwać zdalnie z laptopa, ale w ramach tego ćwiczenia z programowania wykorzystasz Google Cloud Shell – środowisko wiersza poleceń działające w chmurze.

W konsoli Google Cloud kliknij ikonę Cloud Shell na górnym pasku narzędzi:

Uzyskanie dostępu do środowiska i połączenie się z nim powinno zająć tylko kilka chwil. Po zakończeniu powinno pojawić się coś takiego:

Ta maszyna wirtualna ma wszystkie potrzebne narzędzia dla programistów. Zawiera stały katalog domowy o pojemności 5 GB i działa w Google Cloud, znacząco zwiększając wydajność sieci i uwierzytelnianie. Wszystkie zadania w ramach tego ćwiczenia z programowania można wykonywać w przeglądarce. Nie musisz niczego instalować.

3. Utwórz zwykłą kolejkę dla zadań docelowych HTTP

Z tego pierwszego kroku dowiesz się, jak utworzyć zwykłą kolejkę Cloud Tasks i dodać do niej zadania HTTP, aby kierować ją na usługę Cloud Run.

Czym są docelowe zadania HTTP?

Docelowe zadania HTTP mogą być kierowane na dowolną usługę HTTP działającą w Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Functions lub systemach lokalnych w bezpieczny sposób przy użyciu standardowego uwierzytelniania OAuth/OIDC.

Wdrażanie usługi Cloud Run

Najpierw upewnij się, że wymagane interfejsy API są włączone:

gcloud services enable \
  cloudtasks.googleapis.com \
  run.googleapis.com

Wdróż usługę Cloud Run, która będzie miejscem docelowym zadań HTTP:

SERVICE1=hello1
REGION=us-central1

gcloud run deploy $SERVICE1 \
  --allow-unauthenticated \
  --image=gcr.io/cloudrun/hello \
  --region=$REGION

Tworzenie kolejki w Cloud Tasks

Utwórz zwykłą kolejkę w Cloud Tasks:

QUEUE1=http-queue
LOCATION=us-central1

gcloud tasks queues create $QUEUE1 --location=$LOCATION

Tymczasowo wstrzymaj kolejkę, aby obserwować tworzone zadania HTTP:

gcloud tasks queues pause $QUEUE1 --location=$LOCATION

4. Tworzenie i testowanie zadania HTTP

W tym kroku utworzysz zadanie HTTP, które będzie kierowane na utworzoną wcześniej kolejkę.

Tworzenie zadania HTTP

Zadania HTTP możesz tworzyć za pomocą gcloud:

gcloud tasks create-http-task \
    --queue=$QUEUE1 \
    --location=$LOCATION \
    --url=$SERVICE1_URL \
    --method=GET

Opcjonalnie: możesz też utworzyć zadanie HTTP za pomocą bibliotek klienta. Możesz na przykład zobaczyć w Program.cs przykładowy kod w języku C#, w którym żądanie HTTP jest zapakowane w Task i TaskRequest przed wysłaniem do Cloud Tasks za pomocą CloudTasksClient:

var taskRequest = new CreateTaskRequest
{
    Parent = new QueueName(projectId, location, queue).ToString(),
    Task = new Task
    {
        HttpRequest = new HttpRequest
        {
            HttpMethod = HttpMethod.Get,
            Url = url
        }
    }
};

var client = CloudTasksClient.Create();
var response = client.CreateTask(taskRequest);

Aby utworzyć zadanie i dodać je do kolejki, uruchom je w ten sposób:

dotnet run $PROJECT_ID $LOCATION $QUEUE1 $SERVICE1_URL

Testowanie zadania HTTP

W tej chwili zadanie jest tworzone, ale nie jest jeszcze wykonywane, ponieważ kolejka jest wstrzymana. Możesz to sprawdzić, wyświetlając listę kolejek:

gcloud tasks queues list --location=$LOCATION

Kolejka powinna wyświetlać się w stanie PAUSED:

QUEUE_NAME  STATE
http-queue  PAUSED

Wznów kolejkę:

gcloud tasks queues resume $QUEUE --location=$LOCATION

Sprawdź logi usługi Cloud Run:

gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=$SERVICE1" --limit 1

Usługa Cloud Run powinna otrzymać żądanie HTTP GET z Cloud Tasks:

httpRequest:
  latency: 0.227597158s
  protocol: HTTP/1.1
  remoteIp: 35.243.23.192
  requestMethod: GET
  requestSize: '415'
  requestUrl: https://hello1-idcwffc3yq-uc.a.run.app/
  responseSize: '5510'
  serverIp: 216.239.32.53
  status: 200
  userAgent: Google-Cloud-Tasks

5. Tworzenie kolejki z konfiguracją routingu

W tym kroku dowiesz się, jak utworzyć kolejkę Cloud Tasks z konfiguracją routingu, aby dodać zastąpienie identyfikatora URI HTTP przy użyciu funkcji Konfiguracja routingu zadań na poziomie kolejki. Następnie dodaj do niej zadania HTTP, aby kierować je na pierwszą usługę Cloud Run, i obserwuj, że konfiguracja routingu zastępuje identyfikator URI, aby kierować zadania do drugiej usługi Cloud Run.

Czym jest konfiguracja routingu zadań na poziomie kolejki?

Konfiguracja routingu zadań na poziomie kolejki zmienia routing zadań HTTP dla całej kolejki dla wszystkich zadań oczekujących i nowych. Ułatwia to tworzenie zadań, ponieważ cel HTTP nie musi być ustawiany na poziomie zadania. Zapewnia to większą kontrolę dostawcy usług, ponieważ może on ustawić miejsce docelowe dla wszystkich zadań w kolejce (np. kierować ruch do innego backendu, jeśli pierwotny backend nie działa).

Na poziomie kolejki można ustawić następującą konfigurację:

Nagłówki: jeśli określisz je na poziomie kolejki, nagłówki ustawione na poziomie kolejki zostaną uzupełnione dla wszystkich zadań w kolejce.
Metoda HTTP: metoda HTTP określona na poziomie kolejki zastępuje metodę HTTP dla wszystkich zadań w kolejce.
Identyfikator URI elementu docelowego: host, ścieżka, zapytanie, port, schemat (HTTP lub HTTPS) można zastąpić pojedynczo.
Authorization: jeśli konfiguracja OIDC/OAuth zostanie określona na poziomie kolejki, zastąpi konfigurację OIDC/OAuth na poziomie zadania.

Wdrażanie drugiej usługi Cloud Run

Wdróż drugą usługę Cloud Run, która później będzie służyć jako miejsce docelowe zastępowania identyfikatora URI HTTP:

SERVICE2=hello2
REGION=us-central1

gcloud run deploy $SERVICE2 \
  --allow-unauthenticated \
  --image=gcr.io/cloudrun/hello \
  --region=$REGION

Zapisz hosta adresu URL usługi na później:

SERVICE2_URL=$(gcloud run services describe $SERVICE2 --region $REGION --format 'value(status.url)')
SERVICE2_HOST=$(echo $SERVICE2_URL | sed 's,http[s]*://,,g')

Tworzenie kolejki Cloud Tasks z konfiguracją routingu

Utwórz kolejkę z konfiguracją routingu z zastąpieniem identyfikatora URI HTTP dla drugiej usługi Cloud Run.

QUEUE2=http-queue-uri-override

gcloud beta tasks queues create $QUEUE2 \
  --http-uri-override=host:$SERVICE2_HOST \
  --location=$LOCATION

Pamiętaj, że zastąpienie identyfikatora URI odnosi się do drugiej usługi Cloud Run. Wszystkie zadania HTTP dodane do kolejki będą miały zastąpione pierwotny identyfikator URI hosta. Konfigurację kolejki możesz sprawdzić:

gcloud beta tasks queues describe $QUEUE2 --location=$LOCATION

Pole httpTarget powinno zawierać atrybut uriOverride wskazujący hosta drugiej usługi:

httpTarget:
  uriOverride:
    host: hello2-idcwffc3yq-uc.a.run.app
    pathOverride: {}
    queryOverride: {}
...

Tymczasowo wstrzymaj kolejkę, aby obserwować tworzone zadania HTTP:

gcloud tasks queues pause $QUEUE2 --location=$LOCATION

6. Tworzenie i testowanie zadania HTTP dla kolejki z konfiguracją routingu

W tym kroku utworzysz zadanie HTTP kierowane na pierwszą usługę i zobaczysz, że jej identyfikator URI jest zastępowany przez kolejkę, by wskazać drugą usługę.

Tworzenie zadania HTTP

Utwórz zadanie HTTP z adresem URL pierwszej usługi:

gcloud tasks create-http-task \
    --queue=$QUEUE2 \
    --location=$LOCATION \
    --url=$SERVICE1_URL \
    --method=GET

Testowanie zadania HTTP

Wznów kolejkę:

gcloud tasks queues resume $QUEUE2 --location=$LOCATION

Powinna pojawić się informacja, że druga (nie pierwsza) usługa Cloud Run otrzymała żądanie HTTP GET z Cloud Tasks z powodu zastąpienia:

gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=$SERVICE2" --limit 1

---
httpRequest:
  latency: 0.228982142s
  protocol: HTTP/1.1
  remoteIp: 35.187.132.84
  requestMethod: GET
  requestSize: '426'
  requestUrl: https://hello2-idcwffc3yq-uc.a.run.app/
  responseSize: '5510'
  serverIp: 216.239.34.53
  status: 200
  userAgent: Google-Cloud-Tasks

7. Zmień oczekujące zadania za pomocą konfiguracji routingu

Konfiguracji routingu możesz też użyć do zmiany identyfikatora URI HTTP wszystkich zadań oczekujących w kolejce. Jest to przydatne, jeśli usługa backendu ulegnie awarii i chcesz szybko przekierować ją do innej usługi. Na tym etapie sprawdzimy, jak to działa.

Ponownie wstrzymaj kolejkę:

gcloud tasks queues pause $QUEUE2 --location=$LOCATION

Utwórz zadanie HTTP z adresem URL google.com zadania:

gcloud tasks create-http-task \
    --queue=$QUEUE2 \
    --location=$LOCATION \
    --url=https://www.google.com \
    --method=GET

Zadanie jest w stanie oczekiwania, ponieważ kolejka jest wstrzymana.

Teraz zaktualizuj zastąpienie identyfikatora URI HTTP, by wskazywało pierwszą usługę. Spowoduje to zastąpienie hosta oczekującego zadania z google.com na hosta pierwszej usługi:

SERVICE1_URL=$(gcloud run services describe $SERVICE1 --region $REGION --format 'value(status.url)')
SERVICE1_HOST=$(echo $SERVICE1_URL | sed 's,http[s]*://,,g')

gcloud beta tasks queues update $QUEUE2 \
  --http-uri-override=host:$SERVICE1_HOST \
  --location=$LOCATION

Wznów kolejkę:

gcloud tasks queues resume $QUEUE2 --location=$LOCATION

Powinna pojawić się informacja, że pierwsza usługa Cloud Run otrzymała żądanie HTTP GET z Cloud Tasks z powodu zastąpienia (zamiast google.com):

gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=$SERVICE1" --limit 1
---
httpRequest:
  latency: 0.228982142s
  protocol: HTTP/1.1
  remoteIp: 35.187.132.84
  requestMethod: GET
  requestSize: '426'
  requestUrl: https://hello1-idcwffc3yq-uc.a.run.app/
  responseSize: '5510'
  serverIp: 216.239.34.53
  status: 200
  userAgent: Google-Cloud-Tasks

8. Tworzenie kolejki dla interfejsu BufferTask API

Zwykle tworzysz zadania przy użyciu interfejsu Tasks API z bibliotek klienta gcloud lub Listy zadań. Obciąża to aplikacje dodawaniem żądań HTTP do Listy zadań za pomocą bibliotek klienta. Powoduje to również zależność między aplikacjami i bibliotekami klienta Listy zadań.

W tym kroku pokażemy, jak korzystać z zastępowania identyfikatora URI HTTP na poziomie kolejki oraz z nowego interfejsu API BufferTask, by łatwiej tworzyć docelowe zadania HTTP przez wysłanie żądania HTTP. Każda aplikacja, która może wysyłać żądania HTTP, może teraz tworzyć zadania docelowe HTTP.

Czym jest interfejs API BufferTask?

Interfejs CreateTask API to stary sposób tworzenia Listy zadań i wymaga od klienta wysłania obiektu Task do interfejsu API ze wszystkimi ustawionymi polami wymaganymi.

BufferTask API to nowa funkcja, która pozwala użytkownikom tworzyć zadania HTTP bez konieczności podawania żadnej konfiguracji zadania (adresu URL HTTP, nagłówków, autoryzacji). Dzięki temu wystarczy wysłać wiadomość lub treść żądania do interfejsu Buffer API.

Ułatwia to integrację z usługami, ponieważ Cloud Tasks można teraz wdrażać z poziomu usługi bez konieczności wprowadzania zmian w kodzie po stronie klienta. Każde żądanie HTTP wysłane do interfejsu BufferTask API zostanie opakowane jako obiekt Task i dostarczone do miejsca docelowego ustawionego na poziomie kolejki.

Aby można było korzystać z interfejsu BufferTask API, kolejka musi mieć skonfigurowaną konfigurację docelowego identyfikatora URI, czyli konfigurację routingu na poziomie kolejki jest wymaganym wstępnym warunkiem korzystania z interfejsu BufferTask API.

Tworzenie kolejki Cloud Tasks z konfiguracją routingu

Utwórz kolejkę z konfiguracją routingu wskazującą pierwszą usługę wdrożoną w poprzednim kroku:

SERVICE1=hello1
SERVICE1_URL=$(gcloud run services describe $SERVICE1 --region $REGION --format 'value(status.url)')
SERVICE1_HOST=$(echo $SERVICE1_URL | sed 's,http[s]*://,,g')
QUEUE3=http-queue-uri-override-buffer

gcloud beta tasks queues create $QUEUE3 \
  --http-uri-override=host:$SERVICE1_HOST \
  --location=$LOCATION

Tymczasowo wstrzymaj kolejkę, aby obserwować tworzone zadania HTTP:

gcloud tasks queues pause $QUEUE3 --location=$LOCATION

9. Buforowanie żądań HTTP przy użyciu interfejsu BufferTask API

W tym kroku buforujesz proste żądania HTTP GET lub POST za pomocą interfejsu BufferTask API. Pod osłoną Cloud Tasks będzie dodawać te żądania HTTP do zadań HTTP przy użyciu domyślnych ustawień routingu kolejki.

Najpierw zaloguj się, aby uzyskać token dostępu i ustawić kilka zmiennych:

gcloud auth application-default login
ACCESS_TOKEN=$(gcloud auth application-default print-access-token)
PROJECT_ID=$(gcloud config get-value project)
TASKS_QUEUES_API="https://cloudtasks.googleapis.com/v2beta3/projects/$PROJECT_ID/locations/$LOCATION/queues"

Tworzenie zadania HTTP

utworzyć zadanie HTTP za pomocą interfejsu BufferTask API, Zwróć uwagę, że jest to proste żądanie HTTP GET bez konieczności tworzenia zadania:

curl -X GET "$TASKS_QUEUES_API/$QUEUE3/tasks:buffer" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

Utwórz kolejne zadanie HTTP z HTTP POST i treścią:

curl -X POST "$TASKS_QUEUES_API/$QUEUE3/tasks:buffer" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -d "{'message': 'Hello World'}"

Opcjonalnie: możesz też utworzyć zadanie HTTP za pomocą bibliotek klienta. Możesz na przykład zobaczyć w Program.cs przykładowy kod w języku C#, w którym żądanie HTTP GET jest wysyłane bezpośrednio do interfejsu BufferTask API bez konieczności pakowania go do Task czy użycia biblioteki klienta Cloud Tasks:

var BufferTaskApiUrl = $"https://cloudtasks.googleapis.com/v2beta3/projects/{ProjectId}/locations/{Location}/queues/{Queue}/tasks:buffer";

using (var client = new HttpClient())
{
    client.DefaultRequestHeaders.Add("Authorization", $"Bearer {AccessToken}");
    var response = await client.GetAsync(BufferTaskApiUrl);
    var content = await response.Content.ReadAsStringAsync();
    Console.WriteLine($"Response: {content}");
}

Możesz go uruchomić w ten sposób:

dotnet run $PROJECT_ID $LOCATION $QUEUE3 $ACCESS_TOKEN

Interfejs BufferTask API tworzy zadanie na podstawie żądań HTTP i dodaje do identyfikatora URI adres URL z ustawień konfiguracji routingu kolejki.

Testowanie zadania HTTP

Wznów kolejkę:

gcloud tasks queues resume $QUEUE3 --location=$LOCATION

Usługa Cloud Run powinna otrzymać żądania HTTP GET i POST z Cloud Tasks:

gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=$SERVICE1" --limit 4

---
httpRequest:
  latency: 0.002279292s
  protocol: HTTP/1.1
  remoteIp: 35.243.23.42
  requestMethod: POST
  requestSize: '777'
  requestUrl: https://hello1-idcwffc3yq-uc.a.run.app/
  responseSize: '5450'
  serverIp: 216.239.32.53
  status: 200
  userAgent: Google-Cloud-Tasks
...
httpRequest:
  latency: 0.228982142s
  protocol: HTTP/1.1
  remoteIp: 35.187.132.84
  requestMethod: GET
  requestSize: '426'
  requestUrl: https://hello1-idcwffc3yq-uc.a.run.app/
  responseSize: '5510'
  serverIp: 216.239.34.53
  status: 200
  userAgent: Google-Cloud-Tasks

10. Gratulacje

Gratulacje. Udało Ci się ukończyć ćwiczenia z programowania.

Na koniec możesz wypróbować Cloud Tasks jako bufor między Pub/Sub a Cloud Run, aby zobaczyć praktyczny przykład tego, jak te nowe funkcje Cloud Tasks mogą pomóc w łatwym tworzeniu kolejki bufora między usługami.

Czyszczenie (opcjonalnie)

Aby uniknąć opłat, warto wyczyścić zasoby.

Jeśli nie potrzebujesz projektu, możesz go po prostu usunąć:

gcloud projects delete $PROJECT_ID

Jeśli potrzebujesz projektu, możesz usuwać zasoby pojedynczo.

Usuń usługi Cloud Run:

gcloud run services delete $SERVICE1 --region $REGION
gcloud run services delete $SERVICE2 --region $REGION

Usuń kolejki Cloud Tasks:

gcloud tasks queues delete $QUEUE1 --location=$LOCATION
gcloud tasks queues delete $QUEUE2 --location=$LOCATION
gcloud tasks queues delete $QUEUE3 --location=$LOCATION

Omówione zagadnienia

Jak tworzyć zadania docelowe HTTP.
Jak tworzyć zadania docelowe HTTP z nowym zastąpieniem identyfikatora URI HTTP na poziomie kolejki.
Jak zmienić oczekujące zadania za pomocą nowego zastąpienia identyfikatora URI HTTP na poziomie kolejki.
Jak łatwiej buforować żądania HTTP przy użyciu nowego interfejsu API BufferTask.