این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

بافر درخواست های HTTP با وظایف ابری

۱. مقدمه

Cloud Tasks یک سرویس صف‌بندی کاملاً مدیریت‌شده برای مدیریت اجرا، ارسال و تحویل تعداد زیادی از وظایف است.

Cloud Tasks به شما امکان می‌دهد بخش‌هایی از کار، به نام وظایف ، را که می‌توانند به طور مستقل انجام شوند (مثلاً وظیفه‌ای برای به‌روزرسانی ورودی پایگاه داده)، خارج از جریان اصلی برنامه خود جدا کنید و آنها را برای پردازش، به صورت ناهمزمان، با استفاده از هندلرهایی که ایجاد می‌کنید، ارسال کنید.

وظیفه‌ی تخلیه‌شده به یک صف اضافه می‌شود که وظیفه را تا زمان اجرای موفقیت‌آمیز یا عدم موفقیت، حفظ می‌کند. بر اساس پیکربندی، صف می‌تواند به عنوان یک کنترل جریان اعزام نیز عمل کند. شما صف را ایجاد و پیکربندی می‌کنید که سپس توسط سرویس Cloud Tasks مدیریت می‌شود. پس از اضافه شدن وظایف، صف، وظایف را اعزام می‌کند و اطمینان حاصل می‌کند که کارگران به طور قابل اعتمادی آنها را پردازش می‌کنند.

برخی از ویژگی‌های اصلی Cloud Tasks عبارتند از:

اهداف HTTP: وظایفی را اضافه کنید که هر سرویس HTTP را که روی Compute Engine، Google Kubernetes Engine، Cloud Run، Cloud Functions یا سیستم‌های داخلی اجرا می‌شود، به روشی ایمن و با استفاده از احراز هویت استاندارد OAuth/OIDC هدف قرار می‌دهند.
حذف داده‌های تکراری از وظایف : وظایفی که چندین بار اضافه شده‌اند، فقط یک بار ارسال می‌شوند.
تحویل تضمین‌شده : وظایف حداقل یک بار تحویل داده می‌شوند و اکثر وظایف دقیقاً یک بار تحویل داده می‌شوند.
کنترل‌های نرخ و تلاش مجدد: با تنظیم نرخ ارسال وظایف، حداکثر تعداد تلاش‌ها و حداقل زمان انتظار بین تلاش‌ها، اجرا را کنترل کنید.
زمان‌بندی آینده: کنترل زمان اجرای یک وظیفه.

در این آزمایشگاه کد، ابتدا نحوه ایجاد و استفاده از یک صف معمولی Cloud Tasks برای وظایف هدف HTTP را خواهید آموخت. سپس، نحوه استفاده از لغو HTTP URI در سطح صف و API جدید BufferTask را برای بافر کردن آسان‌تر درخواست‌های HTTP با Cloud Tasks خواهید آموخت.

آنچه یاد خواهید گرفت

نحوه ایجاد وظایف هدف HTTP.
نحوه ایجاد وظایف هدف HTTP با لغو جدید HTTP URI در سطح صف.
نحوه تغییر وظایف در حال انتظار با لغو جدید HTTP URI در سطح صف.
چگونه با استفاده از رابط برنامه‌نویسی کاربردی جدید BufferTask، درخواست‌های HTTP را راحت‌تر بافر کنیم؟

۲. تنظیمات و الزامات

تنظیم محیط خودتنظیم

وارد کنسول گوگل کلود شوید و یک پروژه جدید ایجاد کنید یا از یک پروژه موجود دوباره استفاده کنید. اگر از قبل حساب جیمیل یا گوگل ورک اسپیس ندارید، باید یکی ایجاد کنید .

نام پروژه، نام نمایشی برای شرکت‌کنندگان این پروژه است. این یک رشته کاراکتری است که توسط APIهای گوگل استفاده نمی‌شود. شما همیشه می‌توانید آن را به‌روزرسانی کنید.
شناسه پروژه در تمام پروژه‌های گوگل کلود منحصر به فرد است و تغییرناپذیر است (پس از تنظیم، قابل تغییر نیست). کنسول کلود به طور خودکار یک رشته منحصر به فرد تولید می‌کند؛ معمولاً برای شما مهم نیست که چیست. در اکثر آزمایشگاه‌های کد، باید شناسه پروژه خود را (که معمولاً با عنوان PROJECT_ID شناخته می‌شود) ارجاع دهید. اگر شناسه تولید شده را دوست ندارید، می‌توانید یک شناسه تصادفی دیگر ایجاد کنید. به عنوان یک جایگزین، می‌توانید شناسه خودتان را امتحان کنید و ببینید که آیا در دسترس است یا خیر. پس از این مرحله قابل تغییر نیست و در طول پروژه باقی می‌ماند.
برای اطلاع شما، یک مقدار سوم، شماره پروژه ، وجود دارد که برخی از APIها از آن استفاده می‌کنند. برای کسب اطلاعات بیشتر در مورد هر سه این مقادیر، به مستندات مراجعه کنید.

در مرحله بعد، برای استفاده از منابع/API های ابری، باید پرداخت صورتحساب را در کنسول ابری فعال کنید . اجرای این آزمایشگاه کد هزینه زیادی نخواهد داشت، اگر اصلاً هزینه‌ای داشته باشد. برای خاموش کردن منابع به منظور جلوگیری از پرداخت صورتحساب پس از این آموزش، می‌توانید منابعی را که ایجاد کرده‌اید یا پروژه را حذف کنید. کاربران جدید Google Cloud واجد شرایط برنامه آزمایشی رایگان ۳۰۰ دلاری هستند.

شروع پوسته ابری

اگرچه می‌توان از راه دور و از طریق لپ‌تاپ، گوگل کلود را مدیریت کرد، اما در این آزمایشگاه کد، از گوگل کلود شل ، یک محیط خط فرمان که در فضای ابری اجرا می‌شود، استفاده خواهید کرد.

از کنسول گوگل کلود ، روی آیکون Cloud Shell در نوار ابزار بالا سمت راست کلیک کنید:

آماده‌سازی و اتصال به محیط فقط چند لحظه طول می‌کشد. وقتی تمام شد، باید چیزی شبیه به این را ببینید:

این ماشین مجازی با تمام ابزارهای توسعه‌ای که نیاز دارید، مجهز شده است. این ماشین مجازی یک دایرکتوری خانگی پایدار ۵ گیگابایتی ارائه می‌دهد و روی فضای ابری گوگل اجرا می‌شود که عملکرد شبکه و احراز هویت را تا حد زیادی بهبود می‌بخشد. تمام کارهای شما در این آزمایشگاه کد را می‌توان در یک مرورگر انجام داد. نیازی به نصب چیزی ندارید.

۳. ایجاد یک صف منظم برای وظایف هدف HTTP

در این مرحله اول، یاد خواهید گرفت که چگونه یک صف وظایف ابری معمولی ایجاد کنید و وظایف HTTP را به آن اضافه کنید تا یک سرویس Cloud Run را هدف قرار دهید.

وظایف هدف HTTP چیست؟

وظایف هدف HTTP می‌توانند هر سرویس HTTP که روی Compute Engine، Google Kubernetes Engine، Cloud Run، Cloud Functions یا سیستم‌های داخلی اجرا می‌شود را به روشی ایمن و با استفاده از احراز هویت استاندارد OAuth/OIDC هدف قرار دهند.

یک سرویس Cloud Run راه‌اندازی کنید

ابتدا مطمئن شوید که API های مورد نیاز فعال هستند:

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

یک سرویس Cloud Run راه‌اندازی کنید که به عنوان هدف وظایف HTTP عمل کند:

SERVICE1=hello1
REGION=us-central1

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

ایجاد صف وظایف ابری

یک صف وظایف ابری منظم ایجاد کنید:

QUEUE1=http-queue
LOCATION=us-central1

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

صف انتظار را موقتاً متوقف کنید تا بتوانید وظایف HTTP را هنگام ایجاد مشاهده کنید:

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

۴. یک وظیفه HTTP ایجاد و آزمایش کنید

در این مرحله، یک وظیفه HTTP ایجاد خواهید کرد تا صفی را که قبلاً ایجاد کرده‌اید، هدف قرار دهد.

ایجاد یک وظیفه HTTP

شما می‌توانید وظایف HTTP را با استفاده از gcloud ایجاد کنید:

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

اختیاری: شما همچنین می‌توانید یک وظیفه HTTP با کتابخانه‌های کلاینت ایجاد کنید. برای مثال، می‌توانید Program.cs را برای یک نمونه C# بررسی کنید که در آن یک درخواست HTTP قبل از ارسال به Cloud Tasks با CloudTasksClient ، در یک Task و یک TaskRequest قرار می‌گیرد:

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);

می‌توانید آن را به صورت زیر اجرا کنید تا وظیفه را ایجاد و به صف وظایف اضافه کنید:

dotnet run $PROJECT_ID $LOCATION $QUEUE1 $SERVICE1_URL

تست وظیفه HTTP

در این مرحله، وظیفه ایجاد شده است اما هنوز اجرا نشده است، زیرا صف متوقف شده است. می‌توانید این موضوع را با فهرست کردن صف‌ها تأیید کنید:

gcloud tasks queues list --location=$LOCATION

باید صف را در حالت PAUSED ببینید:

QUEUE_NAME  STATE
http-queue  PAUSED

صف را از سر بگیرید:

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

گزارش‌های سرویس Cloud Run را بررسی کنید:

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

باید ببینید که سرویس Cloud Run یک درخواست HTTP GET از 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

۵. ایجاد یک صف با پیکربندی مسیریابی

در این مرحله، یاد خواهید گرفت که چگونه یک صف Cloud Tasks با پیکربندی مسیریابی ایجاد کنید تا با استفاده از ویژگی Queue-level Task Routing Configuration، یک HTTP URI override اضافه کنید. سپس وظایف HTTP را به آن اضافه خواهید کرد تا اولین سرویس Cloud Run را هدف قرار دهید و مشاهده خواهید کرد که پیکربندی مسیریابی، URI را برای مسیریابی وظایف به سرویس Cloud Run دوم override می‌کند.

پیکربندی مسیریابی وظایف در سطح صف چیست؟

پیکربندی مسیریابی وظایف در سطح صف، مسیریابی وظایف HTTP را برای کل صف برای همه وظایف در حال انتظار و جدید تغییر می‌دهد. این امر ایجاد وظایف را آسان‌تر می‌کند زیرا نیازی به تنظیم هدف HTTP در سطح وظیفه نیست و کنترل بیشتری را به ارائه‌دهنده خدمات منتقل می‌کند زیرا آنها می‌توانند هدف همه وظایف را در یک صف تعیین کنند (مثلاً اگر backend اصلی از کار افتاده باشد، ترافیک را به backend دیگری هدایت کنند).

پیکربندی زیر را می‌توان در سطح صف تنظیم کرد:

سرآیندها : سرآیندهای سطح صف، وقتی در سطح صف مشخص شوند، سرآیندهای همه وظایف موجود در صف را اضافه می‌کنند.
متد HTTP : متد HTTP وقتی در سطح صف مشخص شود، متد HTTP را برای همه وظایف موجود در صف لغو می‌کند.
URI هدف : میزبان، مسیر، پرس‌وجو، پورت، طرح (HTTP یا HTTPS) می‌توانند به صورت جداگانه بازنویسی شوند.
مجوز : پیکربندی OIDC/OAuth در صورت مشخص شدن در سطح صف، پیکربندی OIDC/OAuth در سطح وظیفه را لغو می‌کند.

یک سرویس Cloud Run دوم راه‌اندازی کنید

یک سرویس Cloud Run دوم راه‌اندازی کنید که بعداً به عنوان هدف HTTP URI override عمل خواهد کرد:

SERVICE2=hello2
REGION=us-central1

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

میزبان آدرس اینترنتی سرویس را برای بعد ذخیره کنید:

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

ایجاد صف وظایف ابری با پیکربندی مسیریابی

یک صف با پیکربندی مسیریابی با لغو HTTP URI برای سرویس Cloud Run دوم ایجاد کنید.

QUEUE2=http-queue-uri-override

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

توجه داشته باشید که لغو URI به سرویس دوم Cloud Run اشاره دارد. هر وظیفه HTTP که به صف اضافه شود، میزبان URI اصلی آن لغو خواهد شد. می‌توانید پیکربندی صف را مشاهده کنید:

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

باید ببینید که httpTarget دارای یک uriOverride است که به میزبان سرویس دوم اشاره می‌کند:

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

صف انتظار را موقتاً متوقف کنید تا بتوانید وظایف HTTP را هنگام ایجاد مشاهده کنید:

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

۶. یک وظیفه HTTP برای صف با پیکربندی مسیریابی ایجاد و آزمایش کنید

در این مرحله، شما یک وظیفه HTTP برای هدف قرار دادن سرویس اول ایجاد خواهید کرد و مشاهده خواهید کرد که URI آن توسط صف برای اشاره به سرویس دوم لغو می‌شود.

ایجاد یک وظیفه HTTP

یک وظیفه HTTP با URL سرویس اول ایجاد کنید:

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

تست وظیفه HTTP

صف را از سر بگیرید:

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

باید ببینید که سرویس Cloud Run دوم (نه اول) به دلیل لغو، یک درخواست HTTP GET از Cloud Tasks دریافت کرده است:

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

۷. وظایف در حال انتظار را با پیکربندی مسیریابی تغییر دهید

همچنین می‌توانید از پیکربندی مسیریابی برای تغییر HTTP URI تمام وظایف در حال انتظار در یک صف استفاده کنید. این کار در صورتی مفید است که سرویس backend از کار بیفتد و بخواهید به سرعت به سرویس دیگری مسیریابی کنید. بیایید ببینیم که در این مرحله چگونه کار می‌کند.

دوباره صف را متوقف کنید:

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

یک وظیفه HTTP با google.com به عنوان URL وظیفه ایجاد کنید:

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

وظیفه در حالت انتظار است زیرا صف متوقف شده است.

حالا، HTTP URI override را به‌روزرسانی کنید تا به اولین سرویس اشاره کند. این کار میزبان وظیفه در حال انتظار را از google.com به میزبان سرویس اول override می‌کند:

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

صف را از سر بگیرید:

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

باید ببینید که اولین سرویس Cloud Run به دلیل لغو (به جای google.com ) یک درخواست HTTP GET از Cloud Tasks دریافت کرده است:

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

۸. ایجاد یک صف برای BufferTask API

معمولاً شما با استفاده از API وظایف (Tasks API) یا از کتابخانه‌های کلاینت gcloud یا Tasks، وظایف (tasks) را ایجاد می‌کنید. این کار برنامه‌ها را مجبور می‌کند تا درخواست‌های HTTP را با استفاده از کتابخانه‌های کلاینت در Tasks قرار دهند و همچنین باعث ایجاد وابستگی بین برنامه‌ها و کتابخانه‌های کلاینت Tasks می‌شود.

در این مرحله، خواهید دید که چگونه می‌توانید از قابلیت لغو HTTP URI در سطح صف و API جدید BufferTask برای ایجاد آسان‌تر وظایف HTTP target با ارسال یک درخواست HTTP استفاده کنید. هر برنامه‌ای که بتواند درخواست‌های HTTP ارسال کند، اکنون می‌تواند وظایف HTTP target را ایجاد کند.

رابط برنامه‌نویسی کاربردی BufferTask چیست؟

API مربوط به CreateTask روش قدیمی ایجاد Taskها است و از کلاینت می‌خواهد که یک شیء Task را به API ارسال کند و تمام فیلدهای مورد نیاز را تنظیم کند.

BufferTask API یک ویژگی جدید است که به کاربران اجازه می‌دهد بدون نیاز به ارائه هرگونه پیکربندی وظیفه (HTTP URL، هدرها، مجوزها) یک وظیفه HTTP ایجاد کنند و به شما این امکان را می‌دهند که به سادگی یک پیام یا بدنه درخواست خود را به Buffer API ارسال کنید.

این امر ادغام آسان‌تر با سرویس‌ها را امکان‌پذیر می‌کند، زیرا اکنون می‌توان وظایف ابری را بدون نیاز به تغییر کد در سمت کلاینت، در مقابل سرویس شما مستقر کرد. هر درخواست HTTP دلخواه که به API BufferTask ارسال شود، به عنوان یک شیء Task بسته‌بندی شده و به مقصد تعیین شده در سطح صف تحویل داده می‌شود.

برای استفاده از رابط برنامه‌نویسی کاربردی BufferTask، صف باید پیکربندی Target URI را داشته باشد، یا به عبارت دیگر، ویژگی Queue-level Routing Configuration پیش‌نیاز استفاده از رابط برنامه‌نویسی کاربردی BufferTask است.

ایجاد صف وظایف ابری با پیکربندی مسیریابی

یک صف با پیکربندی مسیریابی که به اولین سرویسی که در مرحله قبل مستقر کردیم اشاره می‌کند، ایجاد کنید:

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

صف انتظار را موقتاً متوقف کنید تا بتوانید وظایف HTTP را هنگام ایجاد مشاهده کنید:

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

۹. بافر کردن درخواست‌های HTTP با BufferTask API

در این مرحله، شما درخواست‌های ساده HTTP GET یا POST را با BufferTask API بافر خواهید کرد. در پشت صحنه، Cloud Tasks این درخواست‌های HTTP را در وظایف HTTP با تنظیمات پیکربندی مسیریابی پیش‌فرض صف قرار می‌دهد.

ابتدا، برای دریافت یک توکن دسترسی وارد سیستم شوید و برخی متغیرها را تنظیم کنید:

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"

ایجاد یک وظیفه HTTP

یک وظیفه HTTP با BufferTask API ایجاد کنید. توجه کنید که چگونه این یک درخواست HTTP GET ساده بدون نیاز به ایجاد یک وظیفه است:

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

یک وظیفه HTTP دیگر با HTTP POST و یک بدنه ایجاد کنید:

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

اختیاری: شما همچنین می‌توانید یک وظیفه HTTP با کتابخانه‌های کلاینت ایجاد کنید. برای مثال، می‌توانید Program.cs را برای یک نمونه C# بررسی کنید که در آن یک درخواست HTTP GET مستقیماً به API BufferTask ارسال می‌شود بدون اینکه مجبور باشید آن را در یک Task قرار دهید یا به کتابخانه کلاینت برای 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}");
}

شما می‌توانید آن را به صورت زیر اجرا کنید:

dotnet run $PROJECT_ID $LOCATION $QUEUE3 $ACCESS_TOKEN

رابط برنامه‌نویسی کاربردی BufferTask وظیفه ایجاد یک Task از درخواست‌های HTTP را بر عهده می‌گیرد و URL را از تنظیمات پیکربندی مسیریابی صف برای URI اضافه می‌کند.

تست وظیفه HTTP

صف را از سر بگیرید:

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

باید ببینید که سرویس Cloud Run درخواست‌های HTTP GET و POST را از 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

۱۰. تبریک

تبریک می‌گویم، شما codelab را تمام کردید!

به عنوان یک پیگیری، می‌توانید Cloud Tasks را به عنوان یک بافر بین Pub/Sub و Cloud Run امتحان کنید تا یک مثال واقعی از چگونگی کمک این ویژگی‌های جدید Cloud Tasks به ایجاد آسان یک صف بافر بین سرویس‌ها را ببینید.

پاکسازی (اختیاری)

برای جلوگیری از تحمیل هزینه‌ها، بهتر است منابع را پاکسازی کنید.

اگر به پروژه نیازی ندارید، می‌توانید به سادگی آن را حذف کنید:

gcloud projects delete $PROJECT_ID

اگر به پروژه نیاز دارید، می‌توانید منابع را به صورت جداگانه حذف کنید.

سرویس‌های Cloud Run را حذف کنید:

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

صف‌های وظایف ابری را حذف کنید:

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

آنچه ما پوشش داده‌ایم

نحوه ایجاد وظایف هدف HTTP.
نحوه ایجاد وظایف هدف HTTP با لغو جدید HTTP URI در سطح صف.
نحوه تغییر وظایف در حال انتظار با لغو جدید HTTP URI در سطح صف.
چگونه با استفاده از رابط برنامه‌نویسی کاربردی جدید BufferTask، درخواست‌های HTTP را راحت‌تر بافر کنیم؟

بافر درخواست های HTTP با وظایف ابری با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.

۱. مقدمه

آنچه یاد خواهید گرفت

۲. تنظیمات و الزامات

تنظیم محیط خودتنظیم

شروع پوسته ابری

۳. ایجاد یک صف منظم برای وظایف هدف HTTP

وظایف هدف HTTP چیست؟

یک سرویس Cloud Run راه‌اندازی کنید

ایجاد صف وظایف ابری

۴. یک وظیفه HTTP ایجاد و آزمایش کنید

ایجاد یک وظیفه HTTP

تست وظیفه HTTP

۵. ایجاد یک صف با پیکربندی مسیریابی

پیکربندی مسیریابی وظایف در سطح صف چیست؟

یک سرویس Cloud Run دوم راه‌اندازی کنید

ایجاد صف وظایف ابری با پیکربندی مسیریابی

۶. یک وظیفه HTTP برای صف با پیکربندی مسیریابی ایجاد و آزمایش کنید

ایجاد یک وظیفه HTTP

تست وظیفه HTTP

۷. وظایف در حال انتظار را با پیکربندی مسیریابی تغییر دهید

۸. ایجاد یک صف برای BufferTask API

رابط برنامه‌نویسی کاربردی BufferTask چیست؟

ایجاد صف وظایف ابری با پیکربندی مسیریابی

۹. بافر کردن درخواست‌های HTTP با BufferTask API

ایجاد یک وظیفه HTTP

تست وظیفه HTTP

۱۰. تبریک

پاکسازی (اختیاری)

آنچه ما پوشش داده‌ایم

بافر درخواست های HTTP با وظایف ابری