pengantar
Seperti yang Anda ketahui, transisi dari arsitektur monolit ke arsitektur layanan mikro menyebabkan sejumlah kesulitan yang terkait dengan bagian teknis proyek dan faktor manusia. Salah satu tantangan teknis yang paling sulit adalah memastikan konsistensi dalam sistem terdistribusi.
Terakhir kali, kita membahas penyebab masalah konsistensi dalam arsitektur layanan mikro, pendekatan optimis terhadap konsistensi, dan konsistensi menggunakan komit dua fase.
Pola saga
Saga adalah mekanisme untuk memastikan konsistensi data dalam arsitektur layanan mikro tanpa menggunakan transaksi terdistribusi.
Untuk setiap perintah sistem yang perlu memperbarui data di beberapa layanan, saga dibuat. Saga adalah semacam "daftar periksa" yang terdiri dari transaksi ACID lokal berurutan, yang masing-masing memperbarui data dalam satu layanan. Transaksi kompensasi diterapkan untuk menangani kegagalan. Transaksi seperti itu dijalankan jika terjadi kegagalan pada semua layanan di mana transaksi lokal telah berhasil diselesaikan.
Ada beberapa jenis transaksi dalam saga, sebanyak empat:
- Kompensasi - Membatalkan perubahan yang dibuat oleh transaksi lokal.
- Kompensasi adalah transaksi yang perlu diberi kompensasi (dibalik) jika transaksi berikutnya gagal.
- Turning - transaksi yang menentukan keberhasilan seluruh saga. Jika berhasil, maka saga tersebut dijamin akan mencapai akhir.
- Repeatable - mengikuti pivot dan dijamin berhasil.
Anda dapat mengatur hikayat menggunakan koreografi atau orkestrasi.
Dalam kasus saga koreografi, tidak ada orkestra khusus. Menggunakan layanan pemesanan dan pengguna sebagai contoh, akan terlihat seperti ini: layanan pesanan menerima permintaan dan membuat pesanan dalam status PENDING, dan kemudian menerbitkan acara "Pesanan dibuat". Pengendali peristiwa di layanan pengguna memproses peristiwa ini, mencoba untuk memesan item, dan menerbitkan hasilnya sebagai peristiwa. Layanan pesanan memproses acara ini, mengonfirmasi atau membatalkan pesanan tergantung pada hasil baca.
Saga yang diatur terlihat sedikit lebih menarik. Menggunakan layanan di atas sebagai contoh, akan terlihat seperti ini: layanan pesanan menerima permintaan, membuat saga yang membuat pesanan dalam status PENDING, dan kemudian mengirim perintah untuk memesan barang untuk layanan pengguna. Layanan pengguna mencoba untuk memesan produk dan mengirimkan pesan tanggapan yang menunjukkan hasilnya. Saga menyetujui atau membatalkan pesanan.
Pola saga memungkinkan aplikasi untuk menjaga konsistensi data di berbagai layanan tanpa menggunakan transaksi terdistribusi (komitmen dua fase) dan menghindari masalah yang dibahas di artikel sebelumnya. Tetapi di sisi lain, model pemrogramannya sangat rumit: misalnya, pengembang untuk setiap transaksi harus menulis transaksi kompensasi yang membalikkan perubahan yang dibuat sebelumnya dalam saga.
Saga ini memungkinkan kita untuk mencapai model ACD (Atomicity + Consistency + Durability in ACID), tetapi kami kehilangan satu huruf. Kurangnya surat I menyebabkan masalah terkenal kurangnya isolasi. Ini termasuk: pembaruan yang hilang - satu saga menimpa perubahan yang dibuat oleh yang lain tanpa membacanya, bacaan kotor - transaksi atau saga membaca pembaruan yang belum selesai dari saga lain, kabur / nonrepeatable reads) - dua tahapan berbeda dari saga membaca data yang sama tetapi mendapatkan hasil yang berbeda karena saga lain membuat perubahan. Ada sejumlah pola yang memungkinkan Anda memperbaiki anomali tertentu: penguncian semantik, pembaruan komutatif, representasi pesimistis, pembacaan ulang nilai, perubahan file, dan nilai.Masalah memastikan isolasi tetap terbuka.
Masalah menarik lainnya adalah ketidakmungkinan atomic memperbarui database dan memposting pesan ke broker pesan untuk memicu langkah lebih lanjut dalam saga.
Kesimpulan
Kami berbicara tentang cara mengatur hikayat menggunakan koreografi dan orkestrasi, serta masalah yang ditimbulkan oleh pola ini. Selanjutnya, kita akan membahas cara untuk memperbaiki beberapa anomali dan mengirim pesan secara transaksional ke broker pesan.
