Pola transaksi terdistribusi Saga

Azure

Pertahankan konsistensi data dalam sistem terdistribusi dengan mengoordinasikan urutan transaksi lokal di beberapa layanan. Setiap layanan melakukan operasinya dan memicu langkah berikutnya melalui peristiwa atau pesan. Jika langkah gagal, serangkaian transaksi kompensasi membatalkan perubahan yang dilakukan langkah-langkah yang telah selesai.

Konteks dan masalah

Transaksi mewakili unit kerja, yang dapat mencakup beberapa operasi. Dalam transaksi, peristiwa mengacu pada perubahan status yang memengaruhi entitas. Perintah merangkum semua informasi yang diperlukan untuk melakukan tindakan atau memicu peristiwa berikutnya.

Transaksi harus mematuhi prinsip atomitas, konsistensi, isolasi, dan durabilitas (ACID).

• Atomitas: Semua operasi berhasil atau tidak ada operasi yang berhasil.
• Consistency: Transisi Data dari satu status valid ke status valid lainnya.
• Isolasi : Transaksi bersamaan menghasilkan hasil yang sama dengan transaksi berurutan.
• Durabilitas: perubahan bertahan setelah diterapkan, bahkan ketika kegagalan terjadi.

Dalam satu layanan, transaksi mengikuti prinsip ACID karena beroperasi dalam satu database. Namun, bisa lebih kompleks untuk mencapai kepatuhan ACID di beberapa layanan.

Tantangan dalam arsitektur layanan mikro

Arsitektur layanan mikro biasanya menetapkan database khusus untuk setiap layanan mikro. Pendekatan ini memberikan beberapa manfaat:

• Setiap layanan merangkum datanya sendiri.
• Setiap layanan dapat menggunakan teknologi dan skema database yang paling sesuai untuk kebutuhan spesifiknya.
• Database untuk setiap layanan dapat diskalakan secara independen.
• Kegagalan dalam satu layanan diisolasi dari layanan lain.

Terlepas dari keunggulan ini, arsitektur ini mempersulit konsistensi data lintas layanan. Jaminan database tradisional seperti ACID tidak secara langsung berlaku untuk beberapa penyimpanan data yang dikelola secara independen. Karena keterbatasan ini, arsitektur yang mengandalkan komunikasi antarpemrosana, atau model transaksi tradisional seperti protokol penerapan dua fase, sering kali lebih cocok untuk pola Saga.

Solusi

Pola Saga mengelola transaksi dengan memecahnya menjadi urutan transaksi lokal .

Setiap transaksi lokal:

1. Menyelesaikan pekerjaannya secara atomik dalam satu layanan.
2. Memperbarui database layanan.
3. Memulai transaksi berikutnya melalui peristiwa atau pesan.

Jika transaksi lokal gagal, saga melakukan serangkaian transaksi kompensasi untuk membalikkan perubahan yang dibuat oleh transaksi-transaksi lokal sebelumnya.

Konsep utama dalam pola Saga

• Transaksi kompensasi dapat dibatalkan atau dikompensasi oleh transaksi lain dengan efek yang berlawanan. Jika suatu langkah dalam saga gagal, transaksi kompensasi membalikkan perubahan yang dibuat oleh transaksi yang dapat dikompensasi.

• transaksi Pivot berfungsi sebagai titik tidak ada pengembalian dalam saga. Setelah transaksi pivot berhasil, transaksi yang dapat dikompensasi tidak lagi relevan. Semua tindakan berikutnya harus diselesaikan agar sistem mencapai status akhir yang konsisten. Transaksi pivot dapat mengasumsikan peran yang berbeda, tergantung pada alur saga:

  • Transaksi yang tidak dapat diubah atau tidak dapat dikompensasi tidak dapat dibatalkan atau dicoba kembali.

  • Batas antara transaksi yang dapat dibalik dan yang terkomit berarti bahwa transaksi pivot dapat menjadi transaksi terakhir yang masih dapat dibatalkan, atau transaksi yang dapat dikompensasi. Atau itu bisa menjadi operasi pertama yang dapat diulang dalam saga.

• Transaksi yang dapat diulang mengikuti transaksi pivot. Transaksi yang dapat dicoba ulang bersifat idempoten dan membantu memastikan bahwa saga dapat mencapai keadaan akhir, bahkan jika terjadi kegagalan sementara. Mereka membantu saga mencapai kondisi yang konsisten pada akhirnya.

Pendekatan implementasi Saga

Dua pendekatan implementasi saga yang khas adalah koreografi dan orkestrasi . Setiap pendekatan memiliki serangkaian tantangan dan teknologinya sendiri untuk mengoordinasikan alur kerja.

Koreografi

Dalam pendekatan koreografi, layanan bertukar peristiwa tanpa pengontrol terpusat. Dengan koreografi, setiap transaksi lokal menerbitkan peristiwa domain yang memicu transaksi lokal di layanan lain.

Manfaat koreografi	Kelemahan koreografi
Baik untuk alur kerja sederhana yang memiliki beberapa layanan dan tidak memerlukan logika koordinasi.	Alur kerja bisa membingungkan saat Anda menambahkan langkah-langkah baru. Sulit untuk melacak perintah mana yang ditanggapi oleh setiap peserta saga.
Tidak ada layanan lain yang diperlukan untuk koordinasi.	Ada risiko ketergantungan siklik antara peserta saga karena mereka harus memproses perintah satu sama lain.
Tidak menimbulkan titik kegagalan tunggal karena tanggung jawab didistribusikan di antara para peserta saga.	Pengujian integrasi sulit karena semua layanan harus berjalan untuk mensimulasikan transaksi.

Orkestrasi

Dalam orkestrasi, pengontrol terpusat, atau orkestrator , menangani semua transaksi dan memberi tahu peserta operasi mana yang harus dilakukan berdasarkan peristiwa. Orkestrator melakukan permintaan saga, menyimpan dan menginterpretasikan status setiap tugas, dan menangani pemulihan kegagalan dengan menggunakan transaksi kompensasi.

Manfaat orkestrasi	Kelemahan orkestrasi
Lebih cocok untuk alur kerja kompleks atau saat Anda menambahkan layanan baru.	Kompleksitas desain lainnya memerlukan implementasi logika koordinasi.
Menghindari dependensi siklik karena orkestrator mengelola alur.	Memperkenalkan titik kegagalan karena orkestrator mengelola alur kerja lengkap.
Pemisahan tanggung jawab yang jelas menyederhanakan logika layanan.

Masalah dan pertimbangan

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

• Pergeseran dalam pemikiran desain: Mengadopsi pola Saga membutuhkan pola pikir yang berbeda. Ini mengharuskan Anda untuk fokus pada koordinasi transaksi dan konsistensi data di beberapa layanan mikro.

• Kompleksitas men-debug saga: Men-debug saga dapat menjadi rumit, terutama ketika jumlah layanan yang berpartisipasi bertambah.

• Perubahan database lokal yang tidak dapat diubah: Data tidak dapat digulung balik karena peserta saga menerapkan perubahan pada database masing-masing.

• Menangani kegagalan sementara dan idempotensi: Sistem harus menangani kegagalan sementara secara efektif dan memastikan idempotensi, ketika mengulangi operasi yang sama tidak mengubah hasilnya. Untuk informasi selengkapnya, lihat Pola Konsumen Idempotoen.

• Perlunya pemantauan dan pelacakan saga: Memantau dan melacak alur kerja saga merupakan hal penting untuk menjaga pengawasan operasional.

• Batasan kompensasi transaksi: Mengkompensasi transaksi mungkin tidak selalu berhasil, yang dapat membuat sistem dalam keadaan tidak konsisten.

Potensi anomali data dalam saga

Anomali data adalah inkonsistensi yang dapat terjadi ketika saga beroperasi di beberapa layanan. Karena setiap layanan mengelola datanya sendiri, yang disebut data peserta, tidak ada isolasi bawaan di seluruh layanan. Konfigurasi ini dapat mengakibatkan inkonsistensi data atau masalah durabilitas, seperti pembaruan yang hanya diterapkan sebagian atau konflik antarlayanan. Masalah umum meliputi:

• Pembaruan yang hilang: Ketika satu saga memodifikasi data tanpa mempertimbangkan perubahan yang dibuat oleh saga lain, hal ini mengakibatkan pembaruan tertimpa atau tidak tercatat.

• Pembacaan kotor: Ketika saga atau transaksi membaca data yang dimodifikasi oleh saga lain, tetapi modifikasinya belum selesai.

• Pembacaan fuzzy, atau tidak dapat diulang: Ketika langkah-langkah berbeda dalam saga membaca data yang tidak konsisten karena pembaruan terjadi di antara pembacaan tersebut.

Strategi untuk mengatasi anomali data

Untuk mengurangi atau mencegah anomali ini, pertimbangkan tindakan balasan berikut:

• Kunci semantik: Gunakan kunci tingkat aplikasi saat transaksi saga yang dapat dikompensasi menggunakan semaphore untuk menunjukkan bahwa pembaruan sedang berlangsung.

• Pembaruan komutatif: Pembaruan desain sehingga dapat diterapkan dalam urutan apa pun sambil tetap menghasilkan hasil yang sama. Pendekatan ini membantu mengurangi konflik antar saga.

• Pandangan pesimistis: Atur ulang urutan saga sehingga pembaruan data terjadi dalam transaksi yang dapat dicoba ulang untuk menghilangkan pembacaan kotor. Jika tidak, satu saga dapat membaca data kotor, atau perubahan yang tidak dilakukan, sementara saga lain secara bersamaan melakukan transaksi yang dapat dikompensasi untuk mengembalikan pembaruannya.

• Membaca ulang nilai: Konfirmasikan bahwa data tetap tidak berubah sebelum Anda membuat pembaruan. Jika data berubah, hentikan langkah saat ini dan mulai ulang saga sesuai kebutuhan.

• Berkas versi: Menyimpan catatan semua operasi yang dilakukan pada sebuah rekod dan memastikan bahwa semua operasi tersebut dilakukan dalam urutan yang tepat untuk mencegah konflik.

• Konkurensi berbasis risiko berdasarkan nilai: Secara dinamis memilih mekanisme konkurensi yang sesuai berdasarkan potensi risiko bisnis. Misalnya, gunakan saga untuk pembaruan berisiko rendah dan transaksi terdistribusi untuk pembaruan berisiko tinggi.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

• Anda perlu memastikan konsistensi data dalam sistem terdistribusi tanpa coupling yang ketat.
• Anda perlu membatalkan atau melakukan kompensasi jika salah satu operasi dalam urutan tersebut gagal.

Pola ini mungkin tidak cocok ketika:

• Transaksi saling terkait erat.
• Transaksi kompensasi terjadi pada peserta sebelumnya.
• Ada dependensi siklik.

Langkah berikutnya

• pola data asli Cloud

Sumber daya terkait

Pola berikut mungkin relevan ketika Anda menerapkan pola ini:

• Pola koreografi memiliki setiap komponen sistem berpartisipasi dalam proses pengambilan keputusan tentang alur kerja transaksi bisnis, alih-alih mengandalkan titik kontrol pusat.

• Pola Mengimbangi Transaksi membatalkan pekerjaan yang dilakukan oleh serangkaian langkah, dan akhirnya menentukan operasi yang konsisten jika satu atau beberapa langkah gagal. Aplikasi yang dihosting cloud yang menerapkan proses bisnis dan alur kerja yang kompleks sering kali mengikuti model konsistensi akhir ini.

• Pola Coba Lagi memungkinkan aplikasi menangani kegagalan sementara ketika mencoba menyambungkan ke layanan atau sumber daya jaringan dengan mencoba kembali operasi yang gagal secara transparan. Pola ini dapat meningkatkan stabilitas aplikasi.

• Pola Circuit Breaker menangani kesalahan yang membutuhkan waktu variabel untuk pulih, saat Anda terhubung ke layanan atau sumber daya jarak jauh. Pola ini dapat meningkatkan stabilitas dan ketahanan aplikasi.

• Pola Pemantauan Titik Akhir Kesehatan menerapkan pemeriksaan fungsi dalam aplikasi yang dapat diakses alat eksternal melalui titik akhir yang terekspos secara berkala. Pola ini dapat membantu Anda memverifikasi bahwa aplikasi dan layanan berkinerja dengan benar.

Pertahankan konsistensi data dalam sistem terdistribusi dengan mengoordinasikan urutan transaksi lokal di beberapa layanan. Setiap layanan melakukan operasinya dan memicu langkah berikutnya melalui peristiwa atau pesan. Jika langkah gagal, serangkaian transaksi kompensasi membatalkan perubahan yang dilakukan langkah-langkah yang telah selesai.

Konteks dan masalah

Transaksi mewakili unit kerja, yang dapat mencakup beberapa operasi. Dalam transaksi, peristiwa mengacu pada perubahan status yang memengaruhi entitas. Perintah merangkum semua informasi yang diperlukan untuk melakukan tindakan atau memicu peristiwa berikutnya.

Transaksi harus mematuhi prinsip atomitas, konsistensi, isolasi, dan durabilitas (ACID).

• Atomitas: Semua operasi berhasil atau tidak ada operasi yang berhasil.
• Consistency: Transisi Data dari satu status valid ke status valid lainnya.
• Isolasi : Transaksi bersamaan menghasilkan hasil yang sama dengan transaksi berurutan.
• Durabilitas: perubahan bertahan setelah diterapkan, bahkan ketika kegagalan terjadi.

Dalam satu layanan, transaksi mengikuti prinsip ACID karena beroperasi dalam satu database. Namun, bisa lebih kompleks untuk mencapai kepatuhan ACID di beberapa layanan.

Tantangan dalam arsitektur layanan mikro

Arsitektur layanan mikro biasanya menetapkan database khusus untuk setiap layanan mikro. Pendekatan ini memberikan beberapa manfaat:

• Setiap layanan merangkum datanya sendiri.
• Setiap layanan dapat menggunakan teknologi dan skema database yang paling sesuai untuk kebutuhan spesifiknya.
• Database untuk setiap layanan dapat diskalakan secara independen.
• Kegagalan dalam satu layanan diisolasi dari layanan lain.

Terlepas dari keunggulan ini, arsitektur ini mempersulit konsistensi data lintas layanan. Jaminan database tradisional seperti ACID tidak secara langsung berlaku untuk beberapa penyimpanan data yang dikelola secara independen. Karena keterbatasan ini, arsitektur yang mengandalkan komunikasi antarpemrosana, atau model transaksi tradisional seperti protokol penerapan dua fase, sering kali lebih cocok untuk pola Saga.

Solusi

Pola Saga mengelola transaksi dengan memecahnya menjadi urutan transaksi lokal .

Setiap transaksi lokal:

1. Menyelesaikan pekerjaannya secara atomik dalam satu layanan.
2. Memperbarui database layanan.
3. Memulai transaksi berikutnya melalui peristiwa atau pesan.

Jika transaksi lokal gagal, saga melakukan serangkaian transaksi kompensasi untuk membalikkan perubahan yang dibuat oleh transaksi-transaksi lokal sebelumnya.

Konsep utama dalam pola Saga

• Transaksi kompensasi dapat dibatalkan atau dikompensasi oleh transaksi lain dengan efek yang berlawanan. Jika suatu langkah dalam saga gagal, transaksi kompensasi membalikkan perubahan yang dibuat oleh transaksi yang dapat dikompensasi.

• transaksi Pivot berfungsi sebagai titik tidak ada pengembalian dalam saga. Setelah transaksi pivot berhasil, transaksi yang dapat dikompensasi tidak lagi relevan. Semua tindakan berikutnya harus diselesaikan agar sistem mencapai status akhir yang konsisten. Transaksi pivot dapat mengasumsikan peran yang berbeda, tergantung pada alur saga:

  • Transaksi yang tidak dapat diubah atau tidak dapat dikompensasi tidak dapat dibatalkan atau dicoba kembali.

  • Batas antara transaksi yang dapat dibalik dan yang terkomit berarti bahwa transaksi pivot dapat menjadi transaksi terakhir yang masih dapat dibatalkan, atau transaksi yang dapat dikompensasi. Atau itu bisa menjadi operasi pertama yang dapat diulang dalam saga.

• Transaksi yang dapat diulang mengikuti transaksi pivot. Transaksi yang dapat dicoba ulang bersifat idempoten dan membantu memastikan bahwa saga dapat mencapai keadaan akhir, bahkan jika terjadi kegagalan sementara. Mereka membantu saga mencapai kondisi yang konsisten pada akhirnya.

Pendekatan implementasi Saga

Dua pendekatan implementasi saga yang khas adalah koreografi dan orkestrasi . Setiap pendekatan memiliki serangkaian tantangan dan teknologinya sendiri untuk mengoordinasikan alur kerja.

Koreografi

Dalam pendekatan koreografi, layanan bertukar peristiwa tanpa pengontrol terpusat. Dengan koreografi, setiap transaksi lokal menerbitkan peristiwa domain yang memicu transaksi lokal di layanan lain.

Manfaat koreografi	Kelemahan koreografi
Baik untuk alur kerja sederhana yang memiliki beberapa layanan dan tidak memerlukan logika koordinasi.	Alur kerja bisa membingungkan saat Anda menambahkan langkah-langkah baru. Sulit untuk melacak perintah mana yang ditanggapi oleh setiap peserta saga.
Tidak ada layanan lain yang diperlukan untuk koordinasi.	Ada risiko ketergantungan siklik antara peserta saga karena mereka harus memproses perintah satu sama lain.
Tidak menimbulkan titik kegagalan tunggal karena tanggung jawab didistribusikan di antara para peserta saga.	Pengujian integrasi sulit karena semua layanan harus berjalan untuk mensimulasikan transaksi.

Orkestrasi

Dalam orkestrasi, pengontrol terpusat, atau orkestrator , menangani semua transaksi dan memberi tahu peserta operasi mana yang harus dilakukan berdasarkan peristiwa. Orkestrator melakukan permintaan saga, menyimpan dan menginterpretasikan status setiap tugas, dan menangani pemulihan kegagalan dengan menggunakan transaksi kompensasi.

Manfaat orkestrasi	Kelemahan orkestrasi
Lebih cocok untuk alur kerja kompleks atau saat Anda menambahkan layanan baru.	Kompleksitas desain lainnya memerlukan implementasi logika koordinasi.
Menghindari dependensi siklik karena orkestrator mengelola alur.	Memperkenalkan titik kegagalan karena orkestrator mengelola alur kerja lengkap.
Pemisahan tanggung jawab yang jelas menyederhanakan logika layanan.

Masalah dan pertimbangan

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

• Pergeseran dalam pemikiran desain: Mengadopsi pola Saga membutuhkan pola pikir yang berbeda. Ini mengharuskan Anda untuk fokus pada koordinasi transaksi dan konsistensi data di beberapa layanan mikro.

• Kompleksitas men-debug saga: Men-debug saga dapat menjadi rumit, terutama ketika jumlah layanan yang berpartisipasi bertambah.

• Perubahan database lokal yang tidak dapat diubah: Data tidak dapat digulung balik karena peserta saga menerapkan perubahan pada database masing-masing.

• Menangani kegagalan sementara dan idempotensi: Sistem harus menangani kegagalan sementara secara efektif dan memastikan idempotensi, ketika mengulangi operasi yang sama tidak mengubah hasilnya. Untuk informasi selengkapnya, lihat Pola Konsumen Idempotoen.

• Perlunya pemantauan dan pelacakan saga: Memantau dan melacak alur kerja saga merupakan hal penting untuk menjaga pengawasan operasional.

• Batasan kompensasi transaksi: Mengkompensasi transaksi mungkin tidak selalu berhasil, yang dapat membuat sistem dalam keadaan tidak konsisten.

Potensi anomali data dalam saga

Anomali data adalah inkonsistensi yang dapat terjadi ketika saga beroperasi di beberapa layanan. Karena setiap layanan mengelola datanya sendiri, yang disebut data peserta, tidak ada isolasi bawaan di seluruh layanan. Konfigurasi ini dapat mengakibatkan inkonsistensi data atau masalah durabilitas, seperti pembaruan yang hanya diterapkan sebagian atau konflik antarlayanan. Masalah umum meliputi:

• Pembaruan yang hilang: Ketika satu saga memodifikasi data tanpa mempertimbangkan perubahan yang dibuat oleh saga lain, hal ini mengakibatkan pembaruan tertimpa atau tidak tercatat.

• Pembacaan kotor: Ketika saga atau transaksi membaca data yang dimodifikasi oleh saga lain, tetapi modifikasinya belum selesai.

• Pembacaan fuzzy, atau tidak dapat diulang: Ketika langkah-langkah berbeda dalam saga membaca data yang tidak konsisten karena pembaruan terjadi di antara pembacaan tersebut.

Strategi untuk mengatasi anomali data

Untuk mengurangi atau mencegah anomali ini, pertimbangkan tindakan balasan berikut:

• Kunci semantik: Gunakan kunci tingkat aplikasi saat transaksi saga yang dapat dikompensasi menggunakan semaphore untuk menunjukkan bahwa pembaruan sedang berlangsung.

• Pembaruan komutatif: Pembaruan desain sehingga dapat diterapkan dalam urutan apa pun sambil tetap menghasilkan hasil yang sama. Pendekatan ini membantu mengurangi konflik antar saga.

• Pandangan pesimistis: Atur ulang urutan saga sehingga pembaruan data terjadi dalam transaksi yang dapat dicoba ulang untuk menghilangkan pembacaan kotor. Jika tidak, satu saga dapat membaca data kotor, atau perubahan yang tidak dilakukan, sementara saga lain secara bersamaan melakukan transaksi yang dapat dikompensasi untuk mengembalikan pembaruannya.

• Membaca ulang nilai: Konfirmasikan bahwa data tetap tidak berubah sebelum Anda membuat pembaruan. Jika data berubah, hentikan langkah saat ini dan mulai ulang saga sesuai kebutuhan.

• Berkas versi: Menyimpan catatan semua operasi yang dilakukan pada sebuah rekod dan memastikan bahwa semua operasi tersebut dilakukan dalam urutan yang tepat untuk mencegah konflik.

• Konkurensi berbasis risiko berdasarkan nilai: Secara dinamis memilih mekanisme konkurensi yang sesuai berdasarkan potensi risiko bisnis. Misalnya, gunakan saga untuk pembaruan berisiko rendah dan transaksi terdistribusi untuk pembaruan berisiko tinggi.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

• Anda perlu memastikan konsistensi data dalam sistem terdistribusi tanpa coupling yang ketat.
• Anda perlu membatalkan atau melakukan kompensasi jika salah satu operasi dalam urutan tersebut gagal.

Pola ini mungkin tidak cocok ketika:

• Transaksi saling terkait erat.
• Transaksi kompensasi terjadi pada peserta sebelumnya.
• Ada dependensi siklik.

Langkah berikutnya

• pola data asli Cloud

Sumber daya terkait

Pola berikut mungkin relevan ketika Anda menerapkan pola ini:

• Pola koreografi memiliki setiap komponen sistem berpartisipasi dalam proses pengambilan keputusan tentang alur kerja transaksi bisnis, alih-alih mengandalkan titik kontrol pusat.

• Pola Mengimbangi Transaksi membatalkan pekerjaan yang dilakukan oleh serangkaian langkah, dan akhirnya menentukan operasi yang konsisten jika satu atau beberapa langkah gagal. Aplikasi yang dihosting cloud yang menerapkan proses bisnis dan alur kerja yang kompleks sering kali mengikuti model konsistensi akhir ini.

• Pola Coba Lagi memungkinkan aplikasi menangani kegagalan sementara ketika mencoba menyambungkan ke layanan atau sumber daya jaringan dengan mencoba kembali operasi yang gagal secara transparan. Pola ini dapat meningkatkan stabilitas aplikasi.

• Pola Circuit Breaker menangani kesalahan yang membutuhkan waktu variabel untuk pulih, saat Anda terhubung ke layanan atau sumber daya jarak jauh. Pola ini dapat meningkatkan stabilitas dan ketahanan aplikasi.

• Pola Pemantauan Titik Akhir Kesehatan menerapkan pemeriksaan fungsi dalam aplikasi yang dapat diakses alat eksternal melalui titik akhir yang terekspos secara berkala. Pola ini dapat membantu Anda memverifikasi bahwa aplikasi dan layanan berkinerja dengan benar.