Komunikasi antarlayanan di penyiapan microservice

Last reviewed 2024-06-26 UTC

Dokumen ini adalah yang ketiga dari seri empat bagian tentang merancang, membangun, dan men-deploy microservice. Seri ini menjelaskan berbagai elemen arsitektur microservice. Seri ini mencakup informasi tentang kelebihan dan kekurangan pola arsitektur microservice, serta cara menerapkannya.

  1. Pengantar microservice
  2. Memfaktorkan ulang monolit menjadi microservice
  3. Komunikasi antarlayanan dalam penyiapan microservice (dokumen ini)
  4. Pelacakan terdistribusi di aplikasi microservice

Seri ini ditujukan bagi developer dan arsitek aplikasi yang mendesain dan mengimplementasikan migrasi untuk memfaktorkan ulang aplikasi monolit menjadi aplikasi microservice.

Dokumen ini menjelaskan konsekuensi antara pengiriman pesan asinkron dibandingkan dengan API sinkron dalam microservice. Dokumen ini akan memandu Anda memahami dekonstruksi aplikasi monolitik dan menunjukkan cara mengonversi permintaan sinkron dalam aplikasi asli menjadi alur asinkron dalam penyiapan berbasis microservice yang baru. Konversi ini mencakup penerapan transaksi terdistribusi di antara layanan.

Contoh aplikasi

Dalam dokumen ini, Anda menggunakan aplikasi e-commerce bawaan yang disebut Butik Online. Aplikasi ini menerapkan alur e-commerce dasar seperti menjelajahi item, menambahkan produk ke keranjang, dan checkout. Aplikasi ini juga menampilkan rekomendasi dan iklan berdasarkan pilihan pengguna.

Pemisahan layanan secara logis

Dalam dokumen ini, Anda mengisolasi layanan pembayaran dari bagian aplikasi lainnya. Semua alur di aplikasi Butik Online yang asli bersifat sinkron. Dalam aplikasi yang difaktorkan ulang, proses pembayaran dikonversi ke alur asinkron. Oleh karena itu, saat Anda menerima permintaan pembelian, Anda memberikan konfirmasi "permintaan diterima" kepada pengguna, bukan langsung memprosesnya. Di latar belakang, permintaan asinkron dipicu ke layanan pembayaran untuk memproses pembayaran.

Sebelum memindahkan data dan logika pembayaran ke layanan baru, isolasi data dan logika pembayaran dari monolit. Saat Anda mengisolasi data dan logika pembayaran di monolit, akan lebih mudah memfaktorkan ulang kode di codebase yang sama jika Anda salah mendapatkan batas layanan pembayaran (logika bisnis atau data).

Komponen aplikasi monolit dalam dokumen ini sudah termodularisasi, sehingga saling terisolasi. Jika aplikasi memiliki interdependensi yang lebih ketat, Anda harus mengisolasi logika bisnis dan membuat class dan modul terpisah. Anda juga perlu memisahkan dependensi database ke dalam tabelnya sendiri dan membuat class repositori terpisah. Jika Anda memisahkan dependensi database, kemungkinan ada hubungan kunci asing antara tabel pemisahan. Namun, setelah Anda benar-benar memisahkan layanan dari monolit, dependensi ini akan berhenti ada, dan layanan berinteraksi secara eksklusif melalui kontrak API atau RPC yang telah ditetapkan.

Transaksi terdistribusi dan kegagalan parsial

Setelah Anda mengisolasi layanan dan memisahkannya dari monolit, transaksi lokal dalam sistem monolitik asli akan didistribusikan di antara beberapa layanan. Dalam penerapan monolit, proses checkout mengikuti urutan yang ditunjukkan pada diagram berikut.

Urutan checkout didistribusikan di antara beberapa layanan.

Gambar 1. Urutan proses checkout dalam implementasi monolit.

Pada Gambar 1, saat aplikasi menerima pesanan pembelian, pengontrol checkout memanggil layanan pembayaran dan layanan pesanan untuk memproses pembayaran dan menyimpan pesanan masing-masing. Jika salah satu langkah gagal, transaksi database dapat di-roll back. Pertimbangkan contoh skenario saat permintaan pesanan berhasil disimpan dalam tabel pesanan, tetapi pembayaran gagal. Dalam skenario ini, seluruh transaksi di-roll back dan entri dihapus dari tabel pesanan.

Setelah Anda memisahkan pembayaran ke dalam layanannya sendiri, alur checkout yang dimodifikasi akan serupa dengan diagram berikut:

Proses checkout mencakup beberapa layanan dan database.

Gambar 2. Urutan proses checkout setelah pembayaran dipisahkan ke layanannya sendiri.

Pada gambar 2, transaksi kini mencakup beberapa layanan dan databasenya yang sesuai, sehingga merupakan transaksi terdistribusi. Saat menerima permintaan pesanan, pengontrol checkout menyimpan detail pesanan dalam database lokalnya dan memanggil layanan lain untuk menyelesaikan pesanan. Layanan ini, seperti layanan pembayaran, dapat menggunakan database lokalnya sendiri untuk menyimpan detail pesanan.

Pada aplikasi monolitik, sistem database memastikan bahwa transaksi lokal bersifat atomik. Namun, secara default, sistem berbasis microservice yang memiliki database terpisah untuk setiap layanan tidak memiliki koordinator transaksi global yang mencakup database berbeda. Karena transaksi tidak dikoordinasikan secara terpusat, kegagalan dalam memproses pembayaran tidak akan membatalkan perubahan yang dilakukan dalam layanan pesanan. Oleh karena itu, sistem berada dalam status tidak konsisten.

Pola berikut biasanya digunakan untuk menangani transaksi terdistribusi:

  • Protokol commit dua fase (2PC): Bagian dari rangkaian protokol konsensus, 2PC mengoordinasikan commit transaksi terdistribusi dan mempertahankan jaminan atomisitas, konsistensi, isolasi, ketahanan (ACID). Protokol ini dibagi menjadi fase menyiapkan dan commit. Transaksi akan di-commit hanya jika semua peserta memilih untuk melakukannya. Jika para peserta tidak mencapai konsensus, seluruh transaksi akan di-roll back.
  • Saga: Pola Saga terdiri dari menjalankan transaksi lokal dalam setiap microservice yang membentuk transaksi terdistribusi. Sebuah peristiwa dipicu di akhir setiap operasi, baik yang berhasil atau yang gagal. Semua microservice yang terlibat dalam transaksi terdistribusi berlangganan peristiwa ini. Jika menerima peristiwa berhasil, microservice berikut akan menjalankan operasinya. Jika terjadi kegagalan, microservice sebelumnya akan menyelesaikan tindakan kompensasi untuk mengurungkan perubahan. Saga memberikan tampilan sistem yang konsisten dengan menjaminnya saat semua langkah selesai, baik ketika semua operasi berhasil, atau ketika tindakan kompensasi mengurungkan semua pekerjaan.

Kami merekomendasikan Saga untuk transaksi berumur panjang. Pada aplikasi berbasis microservice, Anda mengharapkan panggilan antarlayanan dan komunikasi dengan sistem pihak ketiga. Oleh karena itu, sebaiknya buat desain untuk konsistensi akhir: coba lagi untuk error yang dapat dipulihkan dan tampilkan peristiwa kompensasi yang pada akhirnya mengubah error yang tidak dapat dipulihkan.

Ada berbagai cara untuk mengimplementasikan Saga. Misalnya, Anda dapat menggunakan mesin tugas dan alur kerja seperti Apache Airflow atau Apache Camel. Anda juga dapat menulis pengendali peristiwa sendiri menggunakan sistem berdasarkan Kafka, RabbitMQ, atau ActiveMQ.

Aplikasi Online Boutique menggunakan layanan checkout untuk mengatur layanan pembayaran, pengiriman, dan notifikasi email. Layanan checkout juga menangani alur kerja bisnis dan pesanan. Sebagai alternatif untuk membuat mesin alur kerja Anda sendiri, Anda dapat menggunakan komponen pihak ketiga seperti Zeebe. Zeebe menyediakan pemodel berbasis UI. Sebaiknya evaluasi pilihan untuk orkestrator microservice dengan cermat berdasarkan persyaratan aplikasi Anda. Pilihan ini merupakan bagian penting dalam menjalankan dan menskalakan microservice Anda.

Aplikasi yang difaktorkan ulang

Untuk mengaktifkan transaksi terdistribusi dalam aplikasi yang difaktorkan ulang, layanan checkout menangani komunikasi antara layanan pembayaran, pengiriman, dan email. Alur kerja Notasi dan Model Proses Bisnis (BPMN) umum menggunakan alur berikut:

Transaksi dalam aplikasi yang difaktorkan ulang mengikuti alur kerja BPMN.

Gambar 3. Alur kerja urutan yang membantu memastikan transaksi terdistribusi di microservice umum.

Diagram sebelumnya menunjukkan alur kerja berikut:

  • Layanan frontend menerima permintaan pesanan, lalu melakukan hal berikut:
    • Mengirim item pesanan ke layanan keranjang. Layanan keranjang kemudian menyimpan detail pesanan (Redis).
    • Mengalihkan ke halaman checkout. Layanan checkout mengambil pesanan dari layanan keranjang, menetapkan status pesanan sebagai Pending, dan meminta pembayaran kepada pelanggan.
    • Mengonfirmasi bahwa pengguna telah membayar. Setelah dikonfirmasi, layanan checkout akan memberi tahu layanan email untuk membuat email konfirmasi dan mengirimkannya kepada pelanggan.
  • Layanan pembayaran kemudian memproses permintaan.
    • Jika permintaan pembayaran berhasil, layanan pembayaran akan memperbarui status pesanan menjadi Complete.
    • Jika permintaan pembayaran gagal, layanan pembayaran akan memulai transaksi kompensasi.
      • Permintaan pembayaran dibatalkan.
      • Layanan checkout mengubah status pesanan menjadi Failed.
    • Jika layanan pembayaran tidak tersedia, waktu permintaan akan habis setelah N detik dan layanan checkout akan memulai transaksi kompensasi.
    • Layanan checkout mengubah status pesanan menjadi Failed.

Tujuan

  • Men-deploy aplikasi Butik Online monolitik di Google Kubernetes Engine (GKE).
  • Validasi alur checkout monolit.
  • Men-deploy versi microservice dari aplikasi monolitik yang difaktorkan ulang
  • Memastikan alur checkout baru berfungsi.
  • Memverifikasi bahwa transaksi terdistribusi dan tindakan kompensasi berfungsi jika terjadi kegagalan.

Biaya

Dalam dokumen ini, Anda akan menggunakan komponen Google Cloud yang dapat ditagih berikut:

Untuk membuat perkiraan biaya berdasarkan proyeksi penggunaan Anda, gunakan kalkulator harga. Pengguna baru Google Cloud mungkin memenuhi syarat untuk mendapatkan uji coba gratis.

Setelah Anda menyelesaikan dokumen ini, Anda dapat menghindari penagihan berkelanjutan dengan menghapus resource yang Anda buat. Untuk informasi selengkapnya, lihat Pembersihan.

Sebelum memulai

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Make sure that billing is enabled for your Google Cloud project.

  3. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  4. Aktifkan API untuk Compute Engine, Google Kubernetes Engine, Cloud SQL, Artifact Analysis, dan Container Registry:

     gcloud services enable \
     compute.googleapis.com \
     sql-component.googleapis.com \
     servicenetworking.googleapis.com\
     container.googleapis.com \
     containeranalysis.googleapis.com \
     containerregistry.googleapis.com \
     sqladmin.googleapis.com

  5. Ekspor variabel lingkungan berikut:

    export PROJECT=$(gcloud config get-value project)
export CLUSTER=$PROJECT-gke
export REGION="us-central1"

Men-deploy monolit e-commerce

Di bagian ini, Anda akan men-deploy aplikasi Butik Online monolitik di cluster GKE. Aplikasi ini menggunakan Cloud SQL sebagai database relasionalnya. Diagram berikut mengilustrasikan arsitektur aplikasi monolitik:

Aplikasi menggunakan arsitektur monolitik.

Gambar 4. Klien terhubung ke aplikasi di cluster GKE dan aplikasi terhubung ke database Cloud SQL.

Untuk men-deploy aplikasi, selesaikan langkah-langkah berikut:

  1. Buat clone repositori GitHub:

    git clone https://github.com/GoogleCloudPlatform/monolith-to-microservices-example

  2. Ganti placeholder PROJECT_ID di file manifes variabel Terraform:

    cd monolith-to-microservices-example/setup && \
sed -i -e "s/\[PROJECT_ID\]/$PROJECT/g" terraform.tfvars

  3. Jalankan skrip Terraform untuk menyelesaikan penyiapan infrastruktur dan men-deploy infrastruktur. Untuk mempelajari Terraform lebih lanjut, lihat Mulai menggunakan Terraform di Google Cloud:

    terraform init && terraform apply -auto-approve

    Skrip Terraform membuat hal berikut:

    • Jaringan VPC bernama PROJECT_ID-vpc
    • Cluster GKE bernama PROJECT_ID-gke
    • Instance Cloud SQL bernama PROJECT_ID-mysql
      • Database bernama ecommerce yang digunakan aplikasi
      • root pengguna yang sandinya ditetapkan menjadi password

    Anda dapat mengubah skrip Terraform untuk membuat sandi secara otomatis. Penyiapan ini menggunakan contoh sederhana yang tidak boleh Anda gunakan dalam produksi.

    Penyediaan infrastruktur dapat memerlukan waktu hingga 10 menit. Jika skrip berhasil, output-nya akan terlihat seperti berikut:

    ...

Apply complete! Resources: 8 added, 0 changed, 0 destroyed.

Outputs:

kubernetes_cluster_name = PROJECT_ID-gke
sql_database_name = PROJECT_ID-mysql
vpc_name = PROJECT_ID-vpc

  4. Hubungkan ke cluster dan buat namespace bernama monolith. Anda men-deploy aplikasi di namespace-nya sendiri di cluster GKE:

    gcloud container clusters get-credentials $CLUSTER \
   --region $REGION \
   --project $PROJECT && \
   kubectl create ns monolith

  5. Aplikasi yang berjalan di GKE menggunakan Kubernetes Secret untuk mengakses database Cloud SQL. Buat secret yang menggunakan kredensial pengguna untuk database:

    kubectl create secret generic dbsecret \
  --from-literal=username=root \
  --from-literal=password=password -n monolith

  6. Build image monolit dan upload ke Container Registry:

    cd ~/monolith
gcloud builds submit --tag gcr.io/$PROJECT_ID/ecomm

  7. Update referensi di file deploy.yaml ke image Docker yang baru dibuat:

    cd ~/monolith
sed -i -e "s/\[PROJECT_ID\]/$PROJECT/g" deploy.yaml

  8. Ganti placeholder dalam file manifes deployment, lalu deploy aplikasi:

    cd .. && \
DB_IP=$(gcloud sql instances describe $PROJECT-mysql | grep "ipAddress:" | tail -1 | awk -F ":" '{print $NF}')

sed -i -e "s/\[DB_IP\]/$DB_IP/g" monolith/deploy.yaml
kubectl apply -f monolith/deploy.yaml

  9. Periksa status deployment:

    kubectl rollout status deployment/ecomm -n monolith

    Outputnya akan terlihat seperti berikut. 

    Waiting for deployment "ecomm" rollout to finish: 0 of 1 updated replicas are available...
deployment "ecomm" successfully rolled out

  10. Dapatkan alamat IP aplikasi yang di-deploy:

    kubectl get svc ecomm -n monolith \
        -o jsonpath="{.status.loadBalancer.ingress[*].ip}" -w

    Tunggu hingga alamat IP load balancer dipublikasikan. Untuk keluar dari perintah, tekan Ctrl+C. Catat alamat IP load balancer, lalu akses aplikasi di URL http://IP_ADDRESS. Mungkin perlu waktu beberapa saat agar load balancer responsif dan mulai meneruskan traffic.

Memvalidasi alur checkout monolit

Di bagian ini, Anda membuat pesanan percobaan untuk memvalidasi alur checkout.

  1. Buka URL yang Anda catat di bagian sebelumnya, http://IP_ADDRESS.
  2. Di halaman beranda aplikasi yang muncul, pilih produk apa pun, lalu klik Add to Cart.
  3. Untuk membuat percobaan pembelian, klik Place your order:
  4. Jika checkout berhasil, jendela konfirmasi pesanan akan muncul dan menampilkan ID Konfirmasi Pesanan.

  5. Untuk melihat detail pesanan, hubungkan ke database:

    gcloud sql connect $PROJECT-mysql --user=root

    Anda juga dapat menggunakan metode lain yang didukung untuk terhubung ke database. Saat diminta, masukkan sandi sebagai password.

  6. Untuk melihat detail pesanan yang tersimpan, jalankan perintah berikut:

    select cart_id from ecommerce.cart;

  7. Outputnya akan terlihat seperti berikut:

    +--------------------------------------+
| cart_id                              |
+--------------------------------------+
| 7cb9ab11-d268-477f-bf4d-4913d64c5b27 |
+--------------------------------------+

Men-deploy aplikasi e-commerce berbasis microservice

Di bagian ini, Anda akan men-deploy aplikasi yang telah difaktorkan ulang. Dokumen ini hanya berfokus pada pemisahan layanan frontend dan pembayaran. Dokumen berikutnya dalam rangkaian ini, Pelacakan terdistribusi dalam aplikasi microservice, menjelaskan layanan lainnya, seperti layanan rekomendasi dan iklan, yang dapat Anda pisahkan dari monolit. Layanan checkout menangani transaksi terdistribusi antara layanan frontend dan pembayaran, serta di-deploy sebagai layanan Kubernetes di cluster GKE, seperti yang ditunjukkan pada diagram berikut:

Layanan pembayaran dan frontend terpisah dari monolit.

Gambar 5. Layanan checkout mengatur transaksi antara layanan keranjang, pembayaran, dan email.

Men-deploy microservice

Di bagian ini, Anda akan menggunakan infrastruktur yang Anda sediakan sebelumnya untuk men-deploy microservice di microservice namespace-nya sendiri:

  1. Pastikan Anda memiliki persyaratan berikut:

    • Project Google Cloud
    • Lingkungan shell dengan gcloud, git, dan kubectl

  2. Di Cloud Shell, clone repositori microservice:

    git clone https://github.com/GoogleCloudPlatform/microservices-demo
cd microservices-demo/

  3. Tetapkan project Google Cloud dan region, serta pastikan GKE API diaktifkan:

    export PROJECT_ID=PROJECT_ID
export REGION=us-central1
gcloud services enable container.googleapis.com \
--project=${PROJECT_ID}

    Ganti PROJECT_ID dengan ID project Google Cloud Anda.

  4. Buat cluster GKE dan dapatkan kredensialnya:

    gcloud container clusters create-auto online-boutique \
    --project=${PROJECT_ID} --region=${REGION}

    Pembuatan cluster mungkin memerlukan waktu beberapa menit.

  5. Deploy microservice ke cluster:

    kubectl apply -f ./release/kubernetes-manifests.yaml

  6. Tunggu hingga pod siap:

    kubectl get pods

    Setelah beberapa menit, Anda akan melihat Pod dalam status Running.

  7. Akses frontend web di browser menggunakan alamat IP eksternal frontend:

    kubectl get service frontend-external | awk '{print $4}'

    Buka http://EXTERNAL_IP di browser web untuk mengakses instance Butik Online Anda.

Memvalidasi alur checkout baru

  1. Untuk memverifikasi alur proses checkout, pilih produk dan lakukan pemesanan, seperti yang dijelaskan di bagian sebelumnya Memvalidasi alur checkout monolit.
  2. Setelah Anda menyelesaikan checkout pesanan, jendela konfirmasi tidak menampilkan ID konfirmasi. Sebagai gantinya, jendela konfirmasi akan mengarahkan Anda untuk memeriksa detail konfirmasi di email Anda.

  3. Untuk memverifikasi bahwa pesanan telah diterima, bahwa layanan pembayaran memproses pembayaran, dan bahwa detail pesanan telah diperbarui, jalankan perintah berikut:

    kubectl logs -f deploy/checkoutservice --tail=100

    Outputnya akan terlihat seperti berikut:

    [...]
{"message":"[PlaceOrder] user_id=\"98828e7a-b2b3-47ce-a663-c2b1019774a3\" user_currency=\"CAD\"","severity":"info","timestamp":"2023-08-10T04:19:20.498893921Z"}
{"message":"payment went through (transaction_id: f0b4a592-026f-4b4a-9892-ce86d2711aed)","severity":"info","timestamp":"2023-08-10T04:19:20.528338189Z"}
{"message":"order confirmation email sent to \"someone@example.com\"","severity":"info","timestamp":"2023-08-10T04:19:20.540275988Z"}

    Untuk keluar dari log, tekan Ctrl+C.

  4. Verifikasi bahwa pembayaran berhasil:

    kubectl logs -f deploy/paymentservice -n --tail=100

    Outputnya akan terlihat seperti berikut:

    [...]
{"severity":"info","time":1691641282208,"pid":1,"hostname":"paymentservice-65cc7795f6-r5m8r","name":"paymentservice-charge","message":"Transaction processed: visa ending 0454     Amount: CAD119.30128260"}
{"severity":"info","time":1691641300051,"pid":1,"hostname":"paymentservice-65cc7795f6-r5m8r","name":"paymentservice-server","message":"PaymentService#Charge invoked with request {\"amount\":{\"currency_code\":\"USD\",\"units\":\"137\",\"nanos\":850000000},\"credit_card\":{\"credit_card_number\":\"4432-8015-6152-0454\",\"credit_card_cvv\":672,\"credit_card_expiration_year\":2039,\"credit_card_expiration_month\":1}}"}

    Untuk keluar dari log, tekan Ctrl+C.

  5. Pastikan email konfirmasi pesanan dikirim:

    kubectl logs -f deploy/emailservice -n --tail=100

    Outputnya akan terlihat seperti berikut:

    [...]
{"timestamp": 1691642217.5026057, "severity": "INFO", "name": "emailservice-server", "message": "A request to send order confirmation email to kalani@examplepetstore.com has been received."}

    Pesan log untuk setiap microservice menunjukkan bahwa transaksi yang didistribusikan di seluruh layanan checkout, pembayaran, dan email telah berhasil diselesaikan.

Memvalidasi tindakan kompensasi dalam transaksi terdistribusi

Bagian ini menyimulasikan skenario saat pelanggan melakukan pemesanan dan layanan pembayaran berhenti.

  1. Untuk menyimulasikan tidak tersedianya layanan, hapus deployment pembayaran dan layanan:

    kubectl delete deploy paymentservice && \
kubectl delete svc paymentservice

  2. Akses lagi aplikasi dan selesaikan alur checkout. Dalam contoh ini, jika layanan pembayaran tidak merespons, waktu permintaan akan habis dan tindakan kompensasi dipicu.

  3. Di frontend UI, klik tombol Place Order. Outputnya akan terlihat seperti berikut:

    HTTP Status: 500 Internal Server Error
rpc error: code = Internal desc = failed to charge card: could not charge the card: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp: lookup paymentservice on 34.118.224.10:53: no such host"
failed to complete the order
main.(*frontendServer).placeOrderHandler
    /src/handlers.go:360

  4. Tinjau log layanan frontend:

    kubectl logs -f deploy/frontend --tail=100

    Outputnya akan terlihat seperti berikut:

    [...]
{"error":"failed to complete the order: rpc error: code = Internal desc = failed to charge card: could not charge the card: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp: lookup paymentservice on 34.118.224.10:53: no such host\"","http.req.id":"0a4cb058-ee9b-470a-9bb1-3a965636022e","http.req.method":"POST","http.req.path":"/cart/checkout","message":"request error","session":"96c94881-a435-4490-9801-c788dc400cc1","severity":"error","timestamp":"2023-08-11T18:25:47.127294259Z"}

  5. Tinjau log Layanan Checkout:

    kubectl logs -f deploy/frontend --tail=100

    Outputnya akan terlihat seperti berikut:

    [...]
{"message":"[PlaceOrder] user_id=\"96c94881-a435-4490-9801-c788dc400cc1\" user_currency=\"USD\"","severity":"info","timestamp":"2023-08-11T18:25:46.947901041Z"}
{"message":"[PlaceOrder] user_id=\"96c94881-a435-4490-9801-c788dc400cc1\" user_currency=\"USD\"","severity":"info","timestamp":"2023-08-11T19:54:21.796343643Z"}

    Perhatikan bahwa tidak ada panggilan berikutnya ke layanan email untuk mengirim notifikasi. Tidak ada log transaksi, seperti payment went through (transaction_id: 06f0083f-fa47-4d91-8258-6d61edfab1ca).

  6. Tinjau log layanan email:

    kubectl logs -f deploy/emailservice --tail=100

    Perhatikan bahwa tidak ada entri log yang dibuat untuk transaksi gagal di layanan email.

Sebagai orkestrator, jika panggilan layanan gagal, layanan checkout akan menampilkan status error dan keluar dari proses checkout.

Pembersihan

Jika berencana untuk menyelesaikan langkah-langkah dalam dokumen berikutnya pada rangkaian ini, Pelacakan terdistribusi dalam aplikasi microservice, Anda dapat menggunakan kembali project dan resource, bukan menghapusnya.

Menghapus project

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Menghapus resource

Jika ingin menyimpan project Google Cloud yang Anda gunakan dalam dokumen ini, hapus masing-masing resource.

  1. Jalankan perintah berikut di Cloud Shell:

    cd setup && terraform destroy -auto-approve

  2. Untuk menghapus cluster microservice menggunakan Google Cloud CLI, jalankan perintah berikut:

    gcloud container clusters delete online-boutique \
    --location $REGION

Langkah selanjutnya