Pola koreografi Saga

Niat

Pola koreografi saga membantu menjaga integritas data dalam transaksi terdistribusi yang menjangkau beberapa layanan dengan menggunakan langganan acara. Dalam transaksi terdistribusi, beberapa layanan dapat dipanggil sebelum transaksi selesai. Ketika layanan menyimpan data di penyimpanan data yang berbeda, mungkin sulit untuk mempertahankan konsistensi data di seluruh penyimpanan data ini.

Motivasi

Transaksi adalah satu unit kerja yang mungkin melibatkan beberapa langkah, di mana semua langkah dijalankan sepenuhnya atau tidak ada langkah yang dijalankan, menghasilkan penyimpanan data yang mempertahankan status konsistennya. Istilah atomisitas, konsistensi, isolasi, dan daya tahan (ACID) mendefinisikan sifat transaksi. Database relasional menyediakan transaksi ACID untuk menjaga konsistensi data.

Untuk menjaga konsistensi dalam suatu transaksi, database relasional menggunakan metode two-phase commit (2PC). Ini terdiri dari fase persiapan dan fase komit.

• Pada tahap persiapan, proses koordinasi meminta proses partisipasi transaksi (peserta) untuk berjanji untuk melakukan atau memutar kembali transaksi.

• Pada fase komit, proses koordinasi meminta peserta untuk melakukan transaksi. Jika peserta tidak setuju untuk berkomitmen dalam fase persiapan, transaksi dibatalkan.

Dalam sistem terdistribusi yang mengikuti pola database-per-service desain, komit dua fase bukanlah pilihan. Ini karena setiap transaksi didistribusikan di berbagai database, dan tidak ada pengontrol tunggal yang dapat mengoordinasikan proses yang mirip dengan komit dua fase di penyimpanan data relasional. Dalam hal ini, salah satu solusinya adalah dengan menggunakan pola koreografi saga.

Penerapan

Gunakan pola koreografi saga saat:

• Sistem Anda membutuhkan integritas dan konsistensi data dalam transaksi terdistribusi yang mencakup beberapa penyimpanan data.

• Penyimpanan data (misalnya, database NoSQL) tidak menyediakan 2PC untuk menyediakan transaksi ACID, Anda perlu memperbarui beberapa tabel dalam satu transaksi, dan menerapkan 2PC dalam batas aplikasi akan menjadi tugas yang kompleks.

• Proses pengendalian pusat yang mengelola transaksi peserta dapat menjadi satu titik kegagalan.

• Peserta saga adalah layanan independen dan perlu digabungkan secara longgar.

• Ada komunikasi antara konteks terbatas dalam domain bisnis.

Masalah dan pertimbangan

• Kompleksitas: Ketika jumlah layanan mikro meningkat, koreografi saga dapat menjadi sulit untuk dikelola karena jumlah interaksi antara layanan mikro. Selain itu, transaksi kompensasi dan percobaan ulang menambah kompleksitas pada kode aplikasi, yang dapat mengakibatkan overhead pemeliharaan. Koreografi cocok ketika hanya ada beberapa peserta dalam saga, dan Anda memerlukan implementasi sederhana tanpa satu titik kegagalan. Ketika lebih banyak peserta ditambahkan, menjadi lebih sulit untuk melacak dependensi antara peserta dengan menggunakan pola ini.

• Implementasi tangguh: Dalam koreografi saga, lebih sulit untuk menerapkan batas waktu, percobaan ulang, dan pola ketahanan lainnya secara global, dibandingkan dengan orkestrasi saga. Koreografi harus diimplementasikan pada komponen individu, bukan pada tingkat orkestrator.

• Dependensi siklik: Para peserta mengkonsumsi pesan yang diterbitkan oleh satu sama lain. Hal ini dapat mengakibatkan dependensi siklik, yang mengarah ke kompleksitas kode dan overhead pemeliharaan, dan kemungkinan kebuntuan.

• Masalah penulisan ganda: Layanan mikro harus memperbarui database secara atomik dan mempublikasikan suatu peristiwa. Kegagalan salah satu operasi dapat menyebabkan keadaan yang tidak konsisten. Salah satu cara untuk mengatasi ini adalah dengan menggunakan pola outbox transaksional.

• Melestarikan acara: Para peserta saga bertindak berdasarkan peristiwa yang diterbitkan. Sangat penting untuk menyimpan peristiwa dalam urutan yang terjadi untuk tujuan audit, debugging, dan replay. Anda dapat menggunakan pola sumber peristiwa untuk mempertahankan peristiwa di penyimpanan acara jika pemutaran ulang status sistem diperlukan untuk memulihkan konsistensi data. Toko acara juga dapat digunakan untuk tujuan audit dan pemecahan masalah karena mencerminkan setiap perubahan dalam sistem.

• Konsistensi akhir: Pemrosesan berurutan transaksi lokal menghasilkan konsistensi akhirnya, yang dapat menjadi tantangan dalam sistem yang membutuhkan konsistensi yang kuat. Anda dapat mengatasi masalah ini dengan menetapkan harapan tim bisnis Anda untuk model konsistensi atau menilai kembali kasus penggunaan dan beralih ke database yang memberikan konsistensi yang kuat.

• Idempotensi: Peserta Saga harus idempoten untuk memungkinkan eksekusi berulang jika terjadi kegagalan sementara yang disebabkan oleh crash tak terduga dan kegagalan orkestrator.

• Isolasi transaksi: Pola saga tidak memiliki isolasi transaksi, yang merupakan salah satu dari empat properti dalam transaksi ACID. Tingkat isolasi transaksi menentukan seberapa banyak transaksi bersamaan lainnya dapat mempengaruhi data tempat transaksi beroperasi. Orkestrasi transaksi secara bersamaan dapat menyebabkan data basi. Kami merekomendasikan menggunakan penguncian semantik untuk menangani skenario seperti itu.

• Observabilitas: Observabilitas mengacu pada pencatatan dan penelusuran terperinci untuk memecahkan masalah dalam proses implementasi dan orkestrasi. Ini menjadi penting ketika jumlah peserta saga meningkat, menghasilkan kompleksitas dalam debugging. nd-to-end Pemantauan dan pelaporan E lebih sulit dicapai dalam koreografi saga, dibandingkan dengan orkestrasi saga.

• Masalah latensi: Transaksi kompensasi dapat menambah latensi ke waktu respons keseluruhan ketika saga terdiri dari beberapa langkah. Jika transaksi melakukan panggilan sinkron, ini dapat meningkatkan latensi lebih lanjut.

Implementasi

Arsitektur tingkat tinggi

Dalam diagram arsitektur berikut, koreografi saga memiliki tiga peserta: layanan pemesanan, layanan inventaris, dan layanan pembayaran. Tiga langkah diperlukan untuk menyelesaikan transaksi: T1, T2, dan T3. Tiga transaksi kompensasi mengembalikan data ke keadaan awal: C1, C2, dan C3.

• Layanan pesanan menjalankan transaksi lokal, T1, yang secara atomik memperbarui database dan menerbitkan Order placed pesan ke broker pesan.

• Layanan inventaris berlangganan pesan layanan pesanan dan menerima pesan bahwa pesanan telah dibuat.

• Layanan inventaris menjalankan transaksi lokal, T2, yang secara atomik memperbarui database dan menerbitkan Inventory updated pesan ke broker pesan.

• Layanan pembayaran berlangganan pesan dari layanan inventaris dan menerima pesan bahwa inventaris telah diperbarui.

• Layanan pembayaran menjalankan transaksi lokal, T3, yang secara atomik memperbarui database dengan detail pembayaran dan menerbitkan pesan ke Payment processed broker pesan.

• Jika pembayaran gagal, layanan pembayaran menjalankan transaksi kompensasi, C1, yang secara atomik mengembalikan pembayaran dalam database dan menerbitkan pesan ke broker pesan. Payment failed

• Transaksi kompensasi C2 dan C3 dijalankan untuk mengembalikan konsistensi data.

Implementasi menggunakan layanan AWS

Anda dapat menerapkan pola koreografi saga dengan menggunakan Amazon. EventBridge EventBridgemenggunakan acara untuk menghubungkan komponen aplikasi. Ini memproses peristiwa melalui bus acara atau pipa. Bus acara adalah router yang menerima acara dan mengirimkannya ke nol atau lebih tujuan, atau target. Aturan yang terkait dengan bus acara mengevaluasi peristiwa saat mereka tiba dan mengirimkannya ke target untuk diproses.

Dalam arsitektur berikut:

• Layanan mikro — layanan pemesanan, layanan inventaris, dan layanan pembayaran — diimplementasikan sebagai fungsi Lambda.

• Ada tiga EventBridge bus khusus: bus Orders acara, bus Inventory acara, dan bus Payment acara.

• Ordersaturan, Inventory aturan, dan Payment aturan cocok dengan peristiwa yang dikirim ke bus acara terkait dan memanggil fungsi Lambda.

Dalam skenario yang sukses, ketika pesanan ditempatkan:

1. Layanan pesanan memproses permintaan dan mengirimkan acara ke bus Orders acara.

2. OrdersAturan cocok dengan acara dan memulai layanan inventaris.

3. Layanan inventaris memperbarui inventaris dan mengirimkan acara ke bus Inventory acara.

4. InventoryAturan cocok dengan acara dan memulai layanan pembayaran.

5. Layanan pembayaran memproses pembayaran dan mengirimkan acara ke bus Payment acara.

6. PaymentAturan cocok dengan acara dan mengirim pemberitahuan Payment processed acara ke pendengar.

   Atau, ketika ada masalah dalam pemrosesan pesanan, EventBridge aturan memulai transaksi kompensasi untuk mengembalikan pembaruan data untuk menjaga konsistensi dan integritas data.

7. Jika pembayaran gagal, Payment aturan memproses acara dan memulai layanan inventaris.Layanan inventaris menjalankan transaksi kompensasi untuk mengembalikan inventaris.

8. Ketika inventaris telah dikembalikan, layanan inventaris mengirimkan Inventory reverted acara ke bus Inventory acara.Acara ini diproses oleh Inventory aturan.Ini memulai layanan pesanan, yang menjalankan transaksi kompensasi untuk menghapus pesanan.

Konten terkait

• Pola orkestrasi Saga

• Pola kotak keluar transaksional

• Coba lagi dengan pola backoff