Anda dapat merujuk ke praktik terbaik yang tercantum di sini saat mengatur layanan menggunakan Alur Kerja.
Daftar ini bukanlah daftar lengkap rekomendasi dan tidak mengajarkan dasar-dasar cara menggunakan Alur Kerja. Dokumen ini mengasumsikan bahwa Anda sudah memiliki pemahaman umum tentang lanskap Google Cloud dan Workflow secara keseluruhan. Untuk informasi selengkapnya, lihat Google Cloud Framework Arsitektur dan Ringkasan alur kerja.
Memilih pola komunikasi yang optimal
Saat mendesain arsitektur microservice untuk men-deploy beberapa layanan, Anda dapat memilih dari pola komunikasi berikut:
Komunikasi layanan ke layanan langsung
Komunikasi berbasis peristiwa tidak langsung (juga dikenal sebagai koreografi)
Konfigurasi, koordinasi, dan pengelolaan otomatis (juga dikenal sebagai orkestrasi)
Pastikan untuk mempertimbangkan manfaat dan kekurangan setiap opsi sebelumnya dan pilih pola yang optimal untuk kasus penggunaan Anda. Misalnya, komunikasi layanan ke layanan langsung mungkin lebih mudah diterapkan daripada opsi lain, tetapi layanan Anda akan terikat erat. Sebaliknya, arsitektur berbasis peristiwa memungkinkan Anda mengaitkan layanan secara longgar; namun, pemantauan dan proses debug mungkin lebih rumit. Terakhir, orkestrator pusat seperti Alur Kerja, meskipun kurang fleksibel, memungkinkan Anda mengoordinasikan komunikasi antar-layanan tanpa penggabungan yang ketat dari komunikasi layanan ke layanan langsung, atau kerumitan peristiwa yang dikoreografi.
Anda juga dapat menggabungkan pola komunikasi. Misalnya, dalam orkestrasi berbasis peristiwa, layanan yang terkait erat dikelola dalam orkestrasi yang dipicu oleh peristiwa. Demikian pula, Anda dapat mendesain sistem dengan satu orkestrasi yang menghasilkan pesan Pub/Sub ke sistem orkestrasi lainnya.
Tips umum
Setelah Anda memutuskan untuk menggunakan Alur Kerja sebagai orkestrator layanan, perhatikan tips bermanfaat berikut.
Menghindari URL hard code
Anda dapat mendukung alur kerja yang portabel di beberapa lingkungan dan lebih mudah dikelola dengan menghindari URL hardcode. Anda dapat melakukannya dengan cara berikut:
Tentukan URL sebagai argumen runtime.
Hal ini dapat membantu saat alur kerja Anda dipanggil melalui library klien atau API. (Namun, hal ini tidak akan berfungsi jika alur kerja Anda dipicu oleh peristiwa dari Eventarc dan satu-satunya argumen yang dapat diteruskan adalah payload peristiwa.)
Contoh
main: params: [args] steps: - init: assign: - url1: ${args.urls.url1} - url2: ${args.urls.url2}
Saat menjalankan alur kerja, Anda dapat menentukan URL. Misalnya:
gcloud workflows run multi-env --data='{"urls":{"url1": "URL_ONE", "url2": "URL_TWO"}}'
Gunakan variabel lingkungan dan buat alur kerja yang dikonfigurasi secara dinamis bergantung pada lingkungan tempat alur kerja tersebut di-deploy. Atau, buat alur kerja yang dapat digunakan kembali sebagai template dan dikonfigurasi sesuai dengan variabel lingkungan yang dikelola secara terpisah.
Gunakan teknik penggantian yang memungkinkan Anda membuat satu file definisi alur kerja, tetapi deploy varian menggunakan alat yang mengganti placeholder dalam alur kerja Anda. Misalnya, Anda dapat menggunakan Cloud Build untuk men-deploy alur kerja dan di file konfigurasi Cloud Build, tambahkan langkah untuk mengganti URL placeholder dalam alur kerja.
Contoh
steps: ‐ id: 'replace-urls' name: 'gcr.io/cloud-builders/gcloud' entrypoint: bash args: - -c - | sed -i -e "s~REPLACE_url1~$_URL1~" workflow.yaml sed -i -e "s~REPLACE_url2~$_URL2~" workflow.yaml ‐ id: 'deploy-workflow' name: 'gcr.io/cloud-builders/gcloud' args: ['workflows', 'deploy', 'multi-env-$_ENV', '--source', 'workflow.yaml']
Kemudian, Anda dapat mengganti nilai variabel pada waktu build. Contoh:
gcloud builds submit --config cloudbuild.yaml \ --substitutions=_ENV=staging,_URL1="URL_ONE",_URL2="URL_TWO"
Untuk mengetahui informasi selengkapnya, lihat Mengirim build melalui CLI dan API.
Atau, Anda dapat menggunakan Terraform untuk menyediakan infrastruktur dan menentukan file konfigurasi yang membuat alur kerja untuk setiap lingkungan menggunakan variabel input.
Contoh
variable "project_id" { type = string } variable "url1" { type = string } variable "url2" { type = string } locals { env = ["staging", "prod"] } # Define and deploy staging and production workflows resource "google_workflows_workflow" "multi-env-workflows" { for_each = toset(local.env) name = "multi-env-${each.key}" project = var.project_id region = "us-central1" source_contents = templatefile("${path.module}/workflow.yaml", { url1 : "${var.url1}-${each.key}", url2 : "${var.url2}-${each.key}" }) }
Saat dideklarasikan di modul root konfigurasi, variabel dapat diberi nilai dengan sejumlah cara. Misalnya
terraform apply -var="project_id=PROJECT_ID" -var="url1=URL_ONE" -var="url2=URL_TWO"
Gunakan konektor Secret Manager untuk menyimpan URL dengan aman di Secret Manager dan mengambilnya.
Menggunakan langkah bertingkat
Setiap alur kerja harus memiliki minimal satu langkah.
Secara default, Alur Kerja memperlakukan langkah-langkah seolah-olah berada dalam daftar
terurut dan menjalankannya satu per satu hingga semua langkah telah berjalan. Secara logis,
beberapa langkah harus dikelompokkan bersama dan Anda dapat menggunakan blok steps
untuk menyusun
serangkaian langkah. Hal ini praktis karena memungkinkan Anda mengarahkan ke langkah atomik
yang benar untuk memproses serangkaian langkah.
Contoh
main: params: [input] steps: - callWikipedia: steps: - checkSearchTermInInput: switch: - condition: ${"searchTerm" in input} assign: - searchTerm: ${input.searchTerm} next: readWikipedia - getCurrentDate: call: http.get args: url: https://timeapi.io/api/Time/current/zone?timeZone=Europe/Amsterdam result: currentDate - setFromCallResult: assign: - searchTerm: ${currentDate.body.dayOfWeek} - readWikipedia: call: http.get args: url: https://en.wikipedia.org/w/api.php query: action: opensearch search: ${searchTerm} result: wikiResult - returnOutput: return: ${wikiResult.body[1]}
Menggabungkan ekspresi
Semua ekspresi harus dimulai dengan
$
dan diapit dalam tanda kurung kurawal:
${EXPRESSION}
Untuk menghindari masalah penguraian YAML, Anda dapat menggabungkan ekspresi dalam tanda kutip. Misalnya, ekspresi yang berisi titik dua dapat menyebabkan perilaku yang tidak terduga saat titik dua ditafsirkan sebagai menentukan peta. Anda dapat mengatasi masalah ini dengan menggabungkan ekspresi YAML dalam tanda petik tunggal:
'${"Name: " + myVar}'
Anda juga dapat menggunakan ekspresi yang mencakup beberapa baris. Misalnya, Anda mungkin perlu menggabungkan kueri SQL dalam tanda kutip saat menggunakan konektor BigQuery Worklow.
Contoh
- runQuery: call: googleapis.bigquery.v2.jobs.query args: projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")} body: useLegacySql: false useQueryCache: false timeoutMs: 30000 # Find top 100 titles with most views on Wikipedia query: ${ "SELECT TITLE, SUM(views) FROM `bigquery-samples.wikipedia_pageviews." + table + "` WHERE LENGTH(TITLE) > 10 GROUP BY TITLE ORDER BY SUM(VIEWS) DESC LIMIT 100" } result: queryResult
Untuk seluruh definisi alur kerja, lihat Menjalankan beberapa tugas BigQuery secara paralel.
Menggunakan panggilan deklaratif
Gunakan Alur Kerja untuk memanggil layanan dari alur kerja itu sendiri dan menangani hasilnya, serta untuk menjalankan tugas sederhana seperti melakukan panggilan HTTP. Alur kerja dapat memanggil layanan, mengurai respons, dan membuat input untuk layanan terhubung lainnya. Dengan memanggil layanan, Anda dapat menghindari kerumitan pemanggilan tambahan, dependensi tambahan, dan layanan yang memanggil layanan. Pertimbangkan untuk mengganti layanan yang bebas dari logika bisnis dengan panggilan API deklaratif dan gunakan Workflows untuk mengabstraksi kompleksitas.
Namun, Anda harus membuat layanan untuk melakukan pekerjaan yang terlalu rumit untuk Alur Kerja; misalnya, menerapkan logika bisnis yang dapat digunakan kembali, komputasi kompleks, atau transformasi yang tidak didukung oleh ekspresi Alur Kerja dan library standarnya. Kasus yang rumit biasanya lebih mudah diterapkan dalam kode, bukan menggunakan YAML atau JSON dan sintaksis Alur Kerja.
Hanya simpan yang Anda butuhkan
Kontrol penggunaan memori agar Anda tidak mengalami
batas resource atau error yang menunjukkan
hal ini seperti ResourceLimitError
, MemoryLimitExceededError
, atau
ResultSizeLimitExceededError
.
Pilih dengan cermat apa yang Anda simpan dalam variabel, dengan memfilter dan hanya menyimpan yang Anda butuhkan. Jika layanan menampilkan payload yang terlalu besar, gunakan fungsi terpisah untuk melakukan panggilan bagi Anda dan hanya menampilkan yang diperlukan.
Anda dapat mengosongkan memori dengan menghapus variabel. Misalnya, Anda mungkin ingin mengosongkan memori yang diperlukan untuk langkah berikutnya. Atau, Anda mungkin memiliki panggilan dengan hasil yang tidak Anda minati, dan Anda dapat menghapus hasil tersebut sepenuhnya.
Anda dapat menghapus variabel dengan menetapkan null
. Di YAML, Anda juga dapat menetapkan
nilai kosong atau ~
ke variabel. Hal ini mengidentifikasi memori yang dapat diklaim kembali
tanpa masalah.
Contoh
- step: assign: - bigVar:
Menggunakan subalur kerja dan alur kerja eksternal
Anda dapat menggunakan sub-alur kerja untuk menentukan bagian logika atau serangkaian langkah yang ingin Anda panggil beberapa kali, sehingga menyederhanakan definisi alur kerja. Subalur kerja mirip dengan fungsi atau rutinitas dalam bahasa pemrograman. Fungsi ini dapat menerima parameter dan menampilkan nilai, sehingga Anda dapat membuat alur kerja yang lebih kompleks dengan rentang aplikasi yang lebih luas.
Perhatikan bahwa subalur kerja bersifat lokal untuk definisi alur kerja Anda dan tidak dapat digunakan kembali dalam alur kerja lain. Namun, Anda dapat memanggil alur kerja dari alur kerja lain. Konektor Alur Kerja dapat membantu Anda melakukannya. Untuk mengetahui informasi selengkapnya, lihat ringkasan konektor untuk Workflow Executions API dan Workflows API.
Menggunakan konektor Workflows
Alur kerja menyediakan sejumlah konektor yang memudahkan akses ke produk Google Cloud lain dalam alur kerja. Konektor menyederhanakan layanan panggilan karena menangani pemformatan permintaan untuk Anda, menyediakan metode dan argumen sehingga Anda tidak perlu mengetahui detail Google Cloud API. Konektor juga memiliki perilaku bawaan untuk menangani percobaan ulang dan operasi yang berjalan lama sehingga Anda dapat menghindari iterasi dan menunggu panggilan selesai; konektor akan menanganinya untuk Anda.
Jika Anda perlu memanggil Google Cloud API, periksa terlebih dahulu untuk mengetahui apakah konektor Alur Kerja untuk API tersebut ada. Selain itu, jika tidak melihat konektor untuk produk Google Cloud , Anda dapat memintanya.
Pelajari cara menggunakan konektor, dan untuk referensi mendetail tentang konektor yang tersedia, lihat Referensi konektor.
Menjalankan langkah alur kerja secara paralel
Meskipun Alur Kerja dapat menjalankan langkah secara berurutan, Anda juga dapat menjalankan langkah independen secara paralel. Dalam beberapa kasus, hal ini dapat mempercepat eksekusi alur kerja Anda secara signifikan. Untuk mengetahui informasi selengkapnya, lihat Menjalankan langkah alur kerja secara paralel.
Menerapkan percobaan ulang dan pola saga
Rancang alur kerja yang tangguh dan dapat menangani kegagalan layanan sementara dan permanen. Error untuk Alur Kerja mungkin muncul, misalnya, oleh permintaan, fungsi, konektor HTTP yang gagal, atau dihasilkan oleh kode alur kerja Anda sendiri. Tambahkan penanganan error dan percobaan ulang sehingga kegagalan dalam satu langkah tidak menyebabkan seluruh alur kerja gagal.
- Anda dapat memunculkan error kustom
menggunakan sintaksis
raise
. - Anda dapat menangkap error menggunakan
blok
try/except
. - Anda dapat mencoba ulang langkah menggunakan blok
try/retry
dan menentukan jumlah maksimum upaya percobaan ulang.
Beberapa transaksi bisnis mencakup beberapa layanan sehingga Anda memerlukan mekanisme untuk menerapkan transaksi yang mencakup layanan. Pola desain saga adalah cara untuk mengelola konsistensi data di seluruh microservice dalam skenario transaksi terdistribusi. Saga adalah urutan transaksi yang memublikasikan peristiwa untuk setiap transaksi dan memicu transaksi berikutnya. Jika transaksi gagal, saga akan menjalankan transaksi kompensasi yang melawan kegagalan sebelumnya dalam urutan. Coba Tutorial Ulang dan Pola Saga dalam Alur Kerja di GitHub.
Menggunakan callback untuk menunggu
Callback memungkinkan eksekusi alur kerja menunggu layanan lain membuat permintaan ke endpoint callback; permintaan tersebut akan melanjutkan eksekusi alur kerja.
Dengan callback, Anda dapat memberi sinyal ke alur kerja bahwa peristiwa yang ditentukan telah terjadi, dan menunggu peristiwa tersebut tanpa polling. Misalnya, Anda dapat membuat alur kerja yang memberi tahu Anda saat produk kembali tersedia atau saat item telah dikirim; atau alur kerja yang menunggu untuk mengizinkan interaksi manusia seperti meninjau pesanan atau memvalidasi terjemahan. Anda juga dapat menunggu peristiwa menggunakan callback dan pemicu Eventarc.
Melakukan orkestrasi tugas yang berjalan lama
Jika perlu menjalankan workload pemrosesan batch yang berjalan lama, Anda dapat menggunakan Batch atau tugas Cloud Run, dan Anda dapat menggunakan Alur Kerja untuk mengelola layanan. Hal ini memungkinkan Anda menggabungkan keunggulan serta menyediakan dan mengatur seluruh proses secara efisien.
Batch adalah layanan terkelola sepenuhnya yang memungkinkan Anda menjadwalkan, memasukkan dalam antrean, dan menjalankan beban kerja batch pada instance virtual machine (VM) Compute Engine. Anda dapat menggunakan konektor Alur Kerja untuk Batch untuk menjadwalkan dan menjalankan tugas Batch. Untuk mengetahui detailnya, coba tutorial.
Tugas Cloud Run digunakan untuk menjalankan kode yang melakukan pekerjaan (tugas) dan berhenti ketika pekerjaan tersebut selesai. Alur kerja memungkinkan Anda menjalankan tugas Cloud Run sebagai bagian dari alur kerja untuk melakukan pemrosesan data yang lebih kompleks atau mengatur sistem tugas yang ada. Coba tutorial yang menunjukkan cara menggunakan Workflows untuk menjalankan tugas Cloud Run.
Membuat container untuk tugas yang berjalan lama
Anda dapat mengotomatiskan eksekusi penampung yang berjalan lama menggunakan Alur Kerja dan Compute Engine. Misalnya, Anda dapat mengemas tugas yang berjalan lama sehingga dapat berjalan di mana saja, lalu menjalankan penampung di VM Compute Engine selama durasi maksimum eksekusi alur kerja (satu tahun).
Dengan menggunakan Alur Kerja, Anda dapat mengotomatiskan pembuatan VM, pengoperasian penampung di VM, dan penghapusan VM. Hal ini memungkinkan Anda menggunakan server dan menjalankan container, tetapi menghilangkan kompleksitas pengelolaan keduanya, dan dapat membantu jika Anda mengalami batasan waktu saat menggunakan layanan seperti fungsi Cloud Run atau Cloud Run. Coba tutorial Container yang berjalan lama dengan Alur Kerja dan Compute Engine di GitHub.
Menjalankan alat command line dari Alur Kerja
Cloud Build adalah layanan yang menjalankan build Anda di Google Cloud sebagai serangkaian langkah build, dengan setiap langkah build dijalankan di container Docker. Menjalankan langkah build serupa dengan menjalankan perintah dalam skrip.
Google Cloud CLI menyertakan alat command line gcloud
, bq
, dan kubectl
, tetapi tidak ada cara langsung untuk menjalankan perintah gcloud CLI dari Alur Kerja. Namun, Cloud Build menyediakan image container yang menyertakan gcloud CLI. Anda dapat menjalankan perintah gcloud CLI di penampung tersebut dari langkah Cloud Build, dan Anda dapat membuat langkah tersebut di Alur Kerja menggunakan konektor Cloud Build.
Contoh
Jalankan gcloud
dalam alur kerja:
Run kubectl
in a workflow:
Menggunakan Terraform untuk membuat alur kerja
Terraform adalah alat infrastruktur sebagai kode yang memungkinkan Anda membuat, mengubah, dan meningkatkan infrastruktur cloud secara terprediksi menggunakan kode.
Anda dapat menentukan dan men-deploy alur kerja menggunakan resource Terraform google_workflows_workflow
. Untuk mengetahui informasi selengkapnya, lihat
Membuat alur kerja menggunakan Terraform.
Untuk membantu Anda mengelola dan memelihara alur kerja yang besar, Anda dapat membuat alur kerja dalam file YAML terpisah dan mengimpor file tersebut ke Terraform menggunakan fungsi templatefile
yang membaca file di jalur tertentu dan merender kontennya sebagai template.
Contoh
# Define a workflow resource "google_workflows_workflow" "workflows_example" { name = "sample-workflow" region = var.region description = "A sample workflow" service_account = google_service_account.workflows_service_account.id # Import main workflow YAML file source_contents = templatefile("${path.module}/workflow.yaml",{}) }
Demikian pula, jika memiliki alur kerja utama yang memanggil beberapa subalur kerja, Anda dapat menentukan alur kerja utama dan subalur kerja dalam file terpisah, dan menggunakan fungsi templatefile
untuk mengimpornya.
Contoh
# Define a workflow resource "google_workflows_workflow" "workflows_example" { name = "sample-workflow" region = var.region description = "A sample workflow" service_account = google_service_account.workflows_service_account.id # Import main workflow and subworkflow YAML files source_contents = join("", [ templatefile( "${path.module}/workflow.yaml",{} ), templatefile( "${path.module}/subworkflow.yaml",{} )]) }
Perhatikan bahwa jika Anda merujuk ke nomor baris saat men-debug alur kerja, semua file YAML yang diimpor melalui file konfigurasi Terraform akan digabungkan dan di-deploy sebagai satu alur kerja.
Men-deploy alur kerja dari repositori Git
Cloud Build menggunakan pemicu build untuk mengaktifkan otomatisasi CI/CD. Anda dapat mengonfigurasi pemicu untuk memproses peristiwa masuk, seperti saat commit baru di-push ke repositori atau saat permintaan pull dimulai, lalu otomatis mengeksekusi build saat peristiwa baru masuk.
Anda dapat menggunakan pemicu Cloud Build untuk otomatis memulai build dan men-deploy alur kerja dari repositori Git. Anda dapat mengonfigurasi pemicu untuk men-deploy alur kerja pada setiap perubahan pada repositori sumber, atau men-deploy alur kerja hanya jika perubahan tersebut cocok dengan kriteria tertentu.
Pendekatan ini dapat membantu Anda mengelola siklus proses deployment. Misalnya, Anda dapat men-deploy perubahan pada alur kerja di lingkungan staging, menjalankan pengujian pada lingkungan tersebut, lalu meluncurkan perubahan ini secara bertahap ke lingkungan produksi. Untuk mengetahui informasi selengkapnya, lihat Men-deploy alur kerja dari repositori Git menggunakan Cloud Build.
Mengoptimalkan penggunaan
Biaya untuk menjalankan alur kerja sangat minim. Namun, untuk penggunaan dengan volume tinggi, terapkan panduan berikut untuk mengoptimalkan penggunaan dan mengurangi biaya:
Daripada menggunakan domain kustom, pastikan bahwa panggilan ke layanan Google Cloudmenggunakan
*.appspot.com
,*.cloud.goog
,*.cloudfunctions.net
, atau*.run.app
sehingga Anda ditagih untuk langkah internal, bukan eksternal.Terapkan kebijakan percobaan ulang kustom yang menyeimbangkan kebutuhan latensi dan keandalan Anda dengan biaya. Percobaan ulang yang lebih sering akan menurunkan latensi dan meningkatkan keandalan, tetapi juga dapat meningkatkan biaya.
Saat menggunakan konektor yang menunggu operasi yang berjalan lama, tetapkan kebijakan polling kustom yang mengoptimalkan latensi untuk biaya. Misalnya, jika Anda memperkirakan operasi akan memerlukan waktu lebih dari satu jam, Anda mungkin menginginkan kebijakan yang awalnya melakukan polling setelah satu menit jika terjadi kegagalan langsung, lalu setiap 15 menit setelahnya.
Gabungkan tugas menjadi satu langkah.
Hindari penggunaan langkah
sys.log
yang berlebihan. Sebaiknya gunakan logging panggilan.
Ringkasan praktik terbaik
Tabel berikut meringkas tips umum dan praktik terbaik yang direkomendasikan dalam dokumen ini.