Pola Transaksi Kompensasi

Gunakan pola ini untuk mengurungkan pekerjaan ketika satu atau beberapa langkah gagal dalam operasi yang akhirnya konsisten. Aplikasi yang dihosting cloud yang mengimplementasikan proses bisnis kompleks dan alur kerja umumnya menggunakan operasi yang mengikuti model konsistensi akhir.

Konteks dan masalah

Aplikasi cloud sering memodifikasi data yang tersebar di berbagai sumber data di lokasi geografis yang berbeda. Untuk menghindari pertikaian dan meningkatkan performa di lingkungan terdistribusi, aplikasi harus menerapkan konsistensi akhir alih-alih konsistensi transaksi yang kuat. Dalam model konsistensi akhirnya, operasi bisnis yang khas terdiri dari serangkaian langkah terpisah. Selama langkah-langkah ini, tampilan keseluruhan status sistem mungkin tidak konsisten. Tetapi sistem harus menjadi konsisten lagi ketika semua langkah selesai.

Menangani kegagalan langkah menghadirkan tantangan utama dalam model konsistensi akhirnya. Setelah kegagalan, Anda mungkin perlu membatalkan pekerjaan dari langkah-langkah operasi yang selesai. Namun, Anda tidak selalu dapat mengembalikan data karena instans aplikasi bersamaan lainnya mungkin mengubah data. Bahkan ketika instans bersamaan tidak mengubah data, mungkin lebih kompleks untuk membatalkan langkah daripada memulihkan status asli. Anda mungkin perlu menerapkan aturan khusus bisnis. Misalnya, lihat contoh situs web perjalanan.

Saat operasi yang menerapkan konsistensi akhir mencakup beberapa penyimpanan data, Anda harus mengakses setiap penyimpanan data untuk mengurungkan perubahan. Untuk mencegah sistem dari kondisi tidak konsisten, Anda harus mengembalikan keadaan semula dengan andal di setiap penyimpanan data.

Operasi yang menerapkan konsistensi akhir tidak selalu menyimpan data yang terpengaruh dalam database. Misalnya, di lingkungan arsitektur berorientasi layanan (SOA), operasi dapat memanggil tindakan dalam layanan dan mengubah status yang dipegang layanan. Untuk membatalkan operasi, Anda juga harus membatalkan perubahan status ini, yang dapat melibatkan pemanggilan layanan lagi untuk membalikkan efek tindakan pertama.

Solusi

Terapkan transaksi kompensasi yang membatalkan efek dari langkah-langkah yang diselesaikan dalam operasi asli. Anda mungkin berpikir bahwa memulihkan sistem ke keadaan semula cukup mudah dilakukan, tetapi pendekatan ini dapat menimpa perubahan dari instans aplikasi lain yang berjalan secara bersamaan. Sebaliknya, transaksi kompensasi harus secara cerdas mempertimbangkan pekerjaan bersamaan. Proses ini biasanya spesifik aplikasi dan tergantung pada operasi aslinya.

Anda dapat menggunakan alur kerja untuk menerapkan operasi yang akhirnya konsisten yang memerlukan kompensasi. Saat operasi asli berjalan, sistem merekam informasi tentang setiap langkah dan cara membatalkannya. Jika operasi gagal, alur kerja akan mundur melalui langkah-langkah yang telah selesai dan membalikkan setiap langkah.

Diagram yang memperlihatkan alur kerja dengan langkah maju dan tindakan kompensasi. Pengguna memulai operasi yang menjalankan langkah 1, langkah 2, dan langkah 3 secara berurutan. Jika semua langkah berhasil, proses selesai. Jika kegagalan terjadi setelah langkah apa pun, tindakan kompensasi dijalankan secara terbalik untuk membatalkan pekerjaan yang telah diselesaikan, yang berakhir dalam keadaan terkompensasi.

Meskipun setiap langkah adalah tindakan terpisah, bersama-sama mereka membentuk operasi yang akhirnya konsisten. Sistem harus melakukan langkah-langkah dan operasi pembatalan yang sesuai untuk setiap langkah. Jika pelanggan membatalkan, operasi batalkan ini dapat berjalan sebagai transaksi kompensasi.

Kegagalan satu langkah tidak selalu mengharuskan Anda untuk mengembalikan seluruh sistem dengan menggunakan transaksi kompensasi. Misalnya, dalam skenario situs web perjalanan, pelanggan memesan penerbangan F1, F2, dan F3 tetapi gagal memesan kamar di hotel H1. Menawarkan kamar kepada pelanggan di hotel yang berbeda lebih disukai daripada membatalkan penerbangan. Pelanggan masih dapat memilih untuk membatalkan, yang memicu transaksi kompensasi untuk membatalkan pemesanan penerbangan. Namun, pelanggan harus membuat keputusan ini, bukan sistem. Ketika keputusan berdampak tinggi atau sulit diotomatiskan dengan andal, sertakan manusia dalam proses pengambilan keputusan.

Pertimbangkan poin-poin penting ini:

• Transaksi kompensasi mungkin tidak perlu membatalkan pekerjaan dalam urutan terbalik yang tepat dari operasi asli.

• Anda mungkin dapat melakukan beberapa langkah pembatalan secara paralel.

• Anda mungkin perlu menerapkan aturan khusus bisnis. Misalnya, membatalkan reservasi penerbangan mungkin tidak memberi pelanggan pengembalian dana sepenuhnya.

Pendekatan ini mirip dengan pola transaksi terdistribusi Saga.

Mengkompensasi transaksi pada akhirnya merupakan operasi yang konsisten dan dapat gagal. Sistem harus mencatat kemajuan sehingga dapat melanjutkan transaksi kompensasi dari titik kegagalan. Langkah mungkin berjalan beberapa kali saat dicoba ulang, jadi desain setiap langkah sebagai perintah idempotensi.

Terkadang intervensi manual adalah satu-satunya cara untuk pulih dari langkah yang gagal. Dalam situasi ini, sistem harus menaikkan pemberitahuan yang mencakup informasi terperinci tentang alasan kegagalan tersebut.

Masalah dan pertimbangan

Pertimbangkan poin-poin berikut saat Anda memutuskan cara menerapkan pola ini:

• Mungkin tidak mudah untuk menentukan kapan langkah dalam operasi yang menerapkan konsistensi akhirnya gagal. Langkah mungkin tidak langsung gagal tetapi malah diblokir. Anda mungkin perlu menerapkan mekanisme batas waktu.

• Tidak mudah untuk menggeneralisasi logika kompensasi. Transaksi kompensasi adalah khusus untuk aplikasi. Ini bergantung pada aplikasi yang memiliki informasi yang memadai untuk membatalkan efek dari setiap langkah dalam operasi yang gagal.

• Transaksi kompensasi tidak selalu berhasil. Tentukan langkah-langkah dalam transaksi kompensasi sebagai perintah idempogen sehingga Anda dapat mengulanginya jika transaksi kompensasi itu sendiri gagal.

• Infrastruktur yang menangani langkah-langkah harus memenuhi kriteria berikut:

  • Ini tangguh baik dalam operasi aslinya maupun dalam transaksi kompensasi.

  • Ini tidak kehilangan informasi yang diperlukan untuk mengkompensasi langkah yang gagal.

  • Ini memantau kemajuan logika kompensasi secara andal. Transaksi kompensasi dijalankan setelah operasi asli di-commit, dan transaksi lainnya mungkin mengubah status menengah. Oleh karena itu, pastikan Anda dapat menghubungkan dan mengaudit operasi asli dan kompensasinya secara end-to-end.

• Transaksi kompensasi tidak selalu mengembalikan data sistem ke statusnya pada awal operasi asli. Sebagai gantinya, transaksi mengimbangi pekerjaan yang berhasil diselesaikan oleh operasi sebelum terjadi kegagalan.

• Langkah-langkah transaksi kompensasi tidak selalu membalikkan operasi asli dalam urutan yang berlawanan. Misalnya, jika satu penyimpanan data lebih sensitif terhadap inkonsistensi daripada yang lain, batalkan perubahan pada penyimpanan tersebut terlebih dahulu.

• Beberapa langkah dapat membantu Anda meningkatkan tingkat keberhasilan. Anda dapat menempatkan kunci jangka pendek dengan batas waktu pada setiap sumber daya yang diperlukan untuk menyelesaikan operasi. Anda dapat memperoleh sumber daya ini terlebih dahulu, lalu melakukan pekerjaan hanya setelah Anda memperoleh semua sumber daya. Selesaikan semua tindakan sebelum masa berlaku kunci habis.

• Logika percobaan ulang yang memperlakukan lebih banyak kesalahan sebagai sementara dapat membantu meminimalkan kegagalan yang memicu transaksi kompensasi. Ketika langkah dalam operasi yang menerapkan konsistensi akhirnya gagal, tangani sebagai pengecualian sementara dan coba lagi langkah tersebut. Hanya hentikan operasi dan picu kompensasi jika langkah gagal berulang kali atau Anda tidak dapat memulihkannya. Untuk informasi selengkapnya tentang strategi coba lagi, lihat Penanganan kesalahan sementara.

• Saat menerapkan transaksi kompensasi, Anda menghadapi banyak tantangan yang mirip dengan menerapkan konsistensi akhir. Untuk informasi selengkapnya, lihat Meminimalkan koordinasi.

• Tentukan titik yang jelas tanpa pengembalian dan langkah-langkah yang tidak dapat diubah. Dalam alur kerja yang kompleks, Anda tidak dapat membatalkan beberapa operasi dengan aman atau bermakna, seperti efek samping eksternal atau tindakan yang mengikat secara hukum. Identifikasi langkah yang dapat dikompensasi versus tidak dapat diubah. Rancang alur kerja sehingga langkah-langkah yang tidak dapat diubah hanya terjadi setelah semua validasi penting berhasil.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

• Operasi bisnis mencakup beberapa langkah, layanan, atau penyimpanan data dan harus dibatalkan jika langkah selanjutnya gagal. Skenario ini sering terjadi dalam alur kerja jangka panjang yang mengikuti model konsistensi akhir dan tidak dapat mengandalkan transaksi atomik.

• Pemulihan kegagalan sering memerlukan logika khusus domain daripada pemutaran kembali data sederhana. Menggunakan tindakan kompensasi saat membatalkan pekerjaan mengharuskan Anda menerapkan aturan bisnis, seperti membatalkan reservasi atau mengeluarkan pengembalian dana parsial.

Pola ini mungkin tidak cocok ketika:

• Operasi dapat dicoba kembali dengan aman dan sebagian besar kegagalan bersifat sementara. Hanya logika coba ulang sering cukup dalam kasus ini, dan transaksi kompensasi menambah kompleksitas yang tidak perlu.

• Sistem tidak dapat mentolerir inkonsistensi sementara, atau kompensasi tidak dapat memulihkan status yang valid dengan andal. Gunakan mekanisme konsistensi yang kuat atau transaksi atom di semua langkah sebagai gantinya.

Desain beban kerja

Evaluasi cara menggunakan Transaksi Kompensasi dalam desain beban kerja untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar kerangka kerja Azure Well-Architected. Tabel berikut memberikan panduan tentang bagaimana pola ini mendukung tujuan setiap pilar.

Pilar	Bagaimana pola ini mendukung tujuan pilar
Keputusan desain Keandalan membantu beban kerja Anda menjadi tangguh tidak berfungsi dan memastikan bahwa memulihkan ke keadaan yang berfungsi penuh setelah kegagalan terjadi.	Tindakan kompensasi mengatasi kerusakan dalam jalur beban kerja penting dengan menggunakan proses seperti secara langsung menggulung balik perubahan data, merusak kunci transaksi, atau bahkan menjalankan perilaku sistem asli untuk membalikkan efek. - RE:02 Alur Kritis - RE:09 Pemulihan bencana

Jika pola ini memperkenalkan kompromi di dalam pilar, bandingkan dengan tujuan pilar lain.

Example

Diagram berikut menunjukkan implementasi praktis Azure pola Kompensasi Transaksi. Implementasi lain mungkin juga berfungsi untuk persyaratan beban kerja Anda. Orkestrator yang berjalan dalam Azure Container Apps mengoordinasikan setiap langkah alur kerja yang berjalan lama dengan mengirim perintah melalui Azure Service Bus. Saat setiap langkah maju berhasil, orkestrator merekam status eksekusi dan tindakan kompensasi yang sesuai dalam Azure Cosmos DB sehingga alur kerja dapat dilanjutkan, berkorelasi, dan diaudit.

Diagram yang memperlihatkan alur kerja di lingkungan Azure Container Apps. Klien mengirim permintaan ke kontainer orkestrator, yang mengoordinasikan Layanan A dan Layanan B dan mencatat operasi. Pesan langkah 1 dan langkah 2 mengalir melalui Service Bus. Jika tahap gagal, tindakan kompensasi dilakukan dalam urutan terbalik. Pesan yang gagal akan dipindahkan ke antrean dead-letter. Lingkungan terintegrasi dengan Microsoft Entra ID untuk identitas dan Application Insights dan Azure Monitor untuk pengamatan.

Model ini menggunakan upaya ulang terlebih dahulu untuk mempertahankan kemajuan ke depan. Jika langkah gagal, orkestrator menerapkan logika coba lagi untuk kesalahan sementara dan mencoba melanjutkan operasi asli. Kompensasi dipanggil hanya ketika kemajuan ke depan menjadi tidak mungkin, seperti ketika percobaan ulang sudah habis atau kegagalan diklasifikasikan sebagai tidak sementara.

Aturan khusus bisnis juga dapat mengutamakan kemajuan ke depan dibandingkan dengan kompensasi langsung. Jika langkah gagal, orkestrator dapat memilih jalur alternatif, seperti mengganti opsi layanan atau fallback yang setara, alih-alih mengembalikan alur kerja. Untuk kasus berdampak tinggi atau ambigu, Anda dapat menjeda alur kerja untuk peninjauan manusia sebelum memutuskan apakah akan melanjutkan jalur alternatif atau memicu kompensasi. Pendekatan ini memperlakukan kompensasi sebagai upaya terakhir dan memungkinkan aturan domain mendorong keputusan pemulihan.

Dalam urutan umum, orkestrator mengirim pesan langkah melalui Service Bus (langkah 1 dan 2), menerima hasil yang berhasil, dan menyimpan metadata penerusan dan kompensasi di Azure Cosmos DB.

Anda dapat memicu kompensasi dengan dua cara:

• Ketika langkah selanjutnya dalam beban kerja yang sama gagal dan Anda harus membatalkan langkah-langkah yang berhasil sebelumnya. Kompensasi ini dapat segera terjadi ketika langkah mengembalikan kesalahan bisnis seperti kegagalan validasi aturan atau setelah upaya percobaan ulang secara teknis telah habis dan pesan dipindahkan ke antrean dead-letter.

• Ketika klien berikutnya secara eksplisit meminta untuk membatalkan operasi yang selesai.

Dalam kedua kasus, orkestrator membaca rekaman kompensasi yang disimpan dan mengirim perintah kompensasi ke layanan yang sesuai. Jika langkah kompensasi gagal sementara, Service Bus mencoba kembali dapat menyelesaikannya tanpa meningkatkan insiden.

Jika percobaan ulang berulang masih gagal, Service Bus memindahkan pesan ke antrean surat mati dan mempertahankan detail kegagalan. Orkestrator, atau prosesor surat mati khusus, menimbulkan pemberitahuan dan memancarkan telemetri terstruktur, termasuk alasan kegagalan dan ID korelasi, untuk Azure Monitor dan Log Analytics, yang dapat muncul di Application Insights. Jalur operasional ini membantu tim mendiagnosis kegagalan, menentukan kebutuhan intervensi manual, dan mempertahankan keterlacakan di seluruh alur asli dan kompensasi.

Alur kerja dapat memulai kompensasi secara otomatis untuk kondisi yang jelas dan berisiko rendah atau jeda untuk peninjauan manusia ketika situasi ambigu, berdampak tinggi, atau memerlukan keputusan manual.

Gunakan identitas terkelola dan otorisasi berbasis Microsoft Entra ID antar komponen untuk menghindari rahasia bersama dan menerapkan akses hak istimewa terkecil. Saat Anda membuat diagram referensi yang disederhanakan, perlakukan kontrol identitas dan otorisasi ini sebagai masalah implementasi dasar daripada langkah-langkah alur eksplisit. Jaga agar diagram tetap berfokus pada orkestrasi, coba lagi, kompensasi, dan penanganan kegagalan.

Sumber daya terkait

• Pertimbangan data untuk layanan mikro: Pelajari mengapa konsistensi akhir dan kegagalan parsial melekat dalam sistem terdistribusi. Pola Compensating Transaction menyediakan mekanisme konkret untuk menangani kegagalan tersebut ketika operasi mencakup beberapa layanan.

• pola Transactional Outbox dengan Azure Cosmos DB: Gunakan pola ini saat kompensasi transaksi perlu menerbitkan peristiwa atau perintah dengan andal. Ini membantu memastikan bahwa perubahan status dan pesan direkam secara atomik, yang mencegah kehilangan pesan.

• Desain untuk penyembuhan diri: Gunakan transaksi kompensasi sebagai bagian dari pendekatan penyembuhan diri untuk aplikasi Anda.

• Pola Pengawas Agen Penjadwal: Gunakan pola ini untuk menerapkan sistem tangguh yang melakukan operasi bisnis di seluruh layanan dan sumber daya terdistribusi. Sistem ini terkadang membutuhkan kompensasi transaksi untuk membatalkan pekerjaan.

• Pola coba lagi: Gunakan pola ini untuk menangani kegagalan sementara dan meminimalkan kebutuhan untuk mengkompensasi transaksi.

• Pola transaksi terdistribusi Saga: Gunakan pola ini untuk mengelola konsistensi data di seluruh layanan mikro dalam transaksi terdistribusi. Saga menggunakan transaksi kompensasi untuk pemulihan kegagalan.

• Pola Pipa dan Filter: Gunakan pola ini dengan pola Kompensasi Transaksi sebagai alternatif untuk transaksi terdistribusi saat Anda menguraikan tugas kompleks ke dalam langkah-langkah yang dapat digunakan kembali.