Edit

Pola transaksi terdistribusi Saga

Azure

Pola desain Saga adalah cara untuk mengelola konsistensi data di seluruh layanan mikro dalam skenario transaksi terdistribusi. Saga adalah urutan transaksi yang memperbarui setiap layanan dan menerbitkan pesan atau peristiwa untuk memicu langkah transaksi berikutnya. Jika langkah gagal, saga mengeksekusi transaksi kompensasi yang melawan transaksi sebelumnya.

Konteks dan masalah

Transaksi adalah satu unit logika atau pekerjaan, terkadang terdiri dari beberapa operasi. Dalam transaksi, peristiwa adalah perubahan status yang terjadi pada entitas, dan perintah merangkum semua informasi yang diperlukan untuk melakukan tindakan atau memicu peristiwa selanjutnya.

Transaksi harus atomik, konsisten, terisolasi, dan tahan lama (ACID). Transaksi dalam satu layanan adalah ACID, tetapi konsistensi data lintas layanan memerlukan strategi manajemen transaksi lintas layanan.

Dalam arsitektur multi-layanan:

  • Atomisitas adalah rangkaian operasi yang tidak dapat dibagi dan tidak dapat direduksi yang semuanya harus terjadi atau tidak ada yang terjadi.
  • Konsistensi berarti transaksi membawa data hanya dari satu status valid ke status valid lainnya.
  • Isolasi menjamin bahwa transaksi bersamaan menghasilkan status data yang sama dengan yang dihasilkan oleh transaksi yang dieksekusi secara berurutan.
  • Daya tahan memastikan bahwa transaksi yang berkomitmen tetap dilakukan bahkan jika terjadi kegagalan sistem atau pemadaman listrik.

Model database-per-microservice memberikan banyak manfaat untuk arsitektur layanan mikro. Enkapsulasi data domain memungkinkan setiap layanan menggunakan jenis dan skema penyimpanan data terbaiknya, menskalakan penyimpanan datanya sendiri sebagaimana diperlukan, dan terisolasi dari kegagalan layanan lain. Namun, memastikan konsistensi data di seluruh database khusus layanan menimbulkan tantangan.

Transaksi terdistribusi seperti protokol penerapan dua fase (2PC) mengharuskan semua peserta dalam transaksi untuk melakukan atau memutar kembali sebelum transaksi dapat dilanjutkan. Namun beberapa implementasi peserta, seperti database NoSQL dan perantara pesan, tidak mendukung model ini.

Batasan transaksi terdistribusi lainnya adalah komunikasi antarproses (IPC) sinkronisitas dan ketersediaan. IPC yang disediakan sistem operasi memungkinkan proses terpisah untuk berbagi data. Agar transaksi terdistribusi dapat dilakukan, semua layanan yang berpartisipasi harus tersedia, yang berpotensi mengurangi ketersediaan sistem secara keseluruhan. Implementasi arsitektur dengan IPC atau batasan transaksi adalah kandidat untuk pola Saga.

Solusi

Pola Saga menyediakan manajemen transaksi menggunakan urutan transaksi lokal. Transaksi lokal adalah upaya kerja atom yang dilakukan oleh peserta saga. Setiap transaksi lokal memperbarui database dan menerbitkan pesan atau peristiwa untuk memicu transaksi lokal berikutnya di dalam saga. Jika transaksi lokal gagal, saga akan menjalankan serangkaian transaksi kompensasi yang membatalkan perubahan yang dibuat oleh transaksi lokal sebelumnya.

Ringkasan Saga.

Dalam pola Saga:

  • Transaksi yang dapat dikompensasikan adalah transaksi yang berpotensi dapat dibatalkan dengan memproses transaksi lain dengan efek sebaliknya.
  • Transaksi pivot adalah titik pergi/tidak-pergi dalam sebuah saga. Jika transaksi pivot dilakukan, saga berjalan sampai selesai. Transaksi pivot dapat berupa transaksi yang tidak dapat dikompensasikan atau dicoba ulang, atau dapat menjadi transaksi terakhir yang dapat dikompensasikan atau transaksi pertama yang dapat dicoba kembali dalam saga tersebut.
  • Transaksi yang dapat dicoba lagi adalah transaksi yang mengikuti transaksi pivot dan dijamin berhasil.

Ada dua pendekatan implementasi saga yang umum, koreografi dan orkestrasi. Setiap pendekatan memiliki serangkaian tantangan dan teknologinya sendiri untuk mengoordinasikan alur kerja.

Koreografi

Koreografi adalah cara untuk mengoordinasikan saga di mana para peserta bertukar peristiwa tanpa titik kendali terpusat. Dengan koreografi, setiap transaksi lokal menerbitkan peristiwa domain yang memicu transaksi lokal di layanan lain.

Ringkasa Koreografi

Keuntungan

  • Bagus untuk alur kerja sederhana yang membutuhkan sedikit peserta dan tidak memerlukan logika koordinasi.
  • Tidak memerlukan implementasi dan pemeliharaan layanan tambahan.
  • Tidak memperkenalkan satu titik kegagalan, karena tanggung jawab didistribusikan ke seluruh peserta saga.

Kekurangan

  • Alur kerja dapat menjadi membingungkan saat menambahkan langkah baru, karena sulit untuk melacak peserta saga mana yang mendengarkan perintah mana.
  • Ada risiko ketergantungan siklik antara peserta saga karena mereka harus menggunakan perintah satu sama lain.
  • Pengujian integrasi sulit karena semua layanan harus dijalankan untuk mensimulasikan transaksi.

Orkestrasi

Orkestrasi adalah cara untuk mengoordinasikan saga di mana pengontrol terpusat memberi tahu peserta saga transaksi lokal apa yang harus dieksekusi. Orkestra saga menangani semua transaksi dan memberi tahu peserta operasi mana yang harus dilakukan berdasarkan peristiwa. Orkestra mengeksekusi permintaan saga, menyimpan dan menafsirkan status setiap tugas, dan menangani pemulihan kegagalan dengan transaksi kompensasi.

Ringkasan Orkestrasi

Keuntungan

  • Baik untuk alur kerja kompleks yang melibatkan banyak peserta atau peserta baru yang ditambahkan seiring waktu.
  • Cocok ketika ada kontrol atas setiap peserta dalam proses, dan kontrol atas aliran kegiatan.
  • Tidak memperkenalkan ketergantungan siklis, karena orkestra secara sepihak bergantung pada peserta saga.
  • Peserta Saga tidak perlu tahu tentang perintah untuk peserta lain. Pemisahan masalah yang jelas menyederhanakan logika bisnis.

Kekurangan

  • Kompleksitas desain tambahan memerlukan implementasi logika koordinasi.
  • Ada titik kegagalan tambahan, karena orkestra mengelola alur kerja yang lengkap.

Masalah dan pertimbangan

Pertimbangkan poin-poin berikut saat menerapkan pola Saga:

  • Pola Saga awalnya mungkin menantang, karena memerlukan cara berpikir baru tentang cara mengoordinasikan transaksi dan menjaga konsistensi data untuk proses bisnis yang mencakup beberapa layanan mikro.
  • Pola Saga sangat sulit untuk di-debug, dan kompleksitasnya bertambah seiring bertambahnya peserta.
  • Data tidak dapat dibatalkan, karena peserta saga melakukan perubahan ke database lokal mereka.
  • Implementasi harus mampu menangani serangkaian potensi kegagalan sementara, dan memberikan idempoten untuk mengurangi efek samping dan memastikan konsistensi data. Idempoten berarti bahwa operasi yang sama dapat diulang beberapa kali tanpa mengubah hasil awal. Untuk informasi selengkapnya, lihat panduan tentang memastikan idempotensi saat memproses pesan dan memperbarui status bersama-sama.
  • Sebaiknya menerapkan observabilitas untuk memantau dan melacak alur kerja saga.
  • Kurangnya isolasi data peserta menimbulkan tantangan daya tahan. Implementasi saga harus mencakup tindakan pencegahan untuk mengurangi anomali.

Anomali berikut dapat terjadi tanpa tindakan yang tepat:

  • Pembaruan yang hilang, saat satu saga menulis tanpa membaca perubahan yang dibuat oleh saga lain.
  • Pembacaan kotor, saat transaksi atau saga membaca pembaruan yang dibuat oleh saga yang belum menyelesaikan pembaruan tersebut.
  • Pembacaan kabur/tidak dapat diulang, saat langkah saga yang berbeda membaca data yang berbeda karena terjadi pembaruan data di antara pembacaan.

Tindakan pencegahan yang disarankan untuk mengurangi atau mencegah anomali meliputi:

  • Kunci semantik, kunci tingkat aplikasi tempat transaksi kompensasi kisah menggunakan semaphore untuk menunjukkan pembaruan sedang berlangsung.
  • Pembaruan komutatif yang dapat dijalankan dalam urutan apa pun dan menghasilkan hasil yang sama.
  • Tampilan pesimis: Ada kemungkinan satu saga membaca data kotor, sementara saga lain menjalankan transaksi yang dapat dikompensasi untuk memutar kembali operasi. Tampilan pesimis menyusun ulang kisah sehingga data yang mendasarinya diperbarui dalam transaksi yang dapat dicoba lagi, yang menghilangkan kemungkinan pembacaan kotor.
  • Nilai baca ulang memverifikasi bahwa data tidak berubah, lalu memperbarui rekaman. Jika rekaman telah berubah, langkah-langkah dibatalkan dan saga dapat dimulai kembali.
  • File versi mencatat operasi pada catatan saat tiba, lalu menjalankannya dalam urutan yang benar.
  • Berdasarkan nilai menggunakan risiko bisnis setiap permintaan untuk memilih mekanisme konkurensi secara dinamis. Permintaan berisiko rendah menyokong saga, sementara permintaan berisiko tinggi menyokong transaksi terdistribusi.

Kapan menggunakan pola ini

Gunakan pola Saga saat Anda perlu:

  • Pastikan konsistensi data dalam sistem terdistribusi tanpa kopling ketat.
  • Putar kembali atau ganti rugi jika salah satu operasi dalam urutan gagal.

Pola Saga kurang cocok untuk:

  • Transaksi yang digabungkan dengan erat.
  • Mengkompensasi transaksi yang terjadi pada peserta sebelumnya.
  • Ketergantungan siklik.

Contoh

Saga Berbasis Orkestrasi di Tanpa Server adalah referensi penerapan saga yang menggunakan pendekatan orkestrasi yang menyimulasikan skenario transfer uang dengan alur kerja yang berhasil dan yang gagal.

Langkah berikutnya

Beberapa pola berikut mungkin juga berguna saat menerapkan pola ini:

  • Koreografi membuat setiap komponen sistem berpartisipasi dalam proses pengambilan keputusan tentang alur kerja transaksi bisnis, alih-alih mengandalkan titik kontrol pusat.
  • Transaksi kompensasi membatalkan pekerjaan yang dilakukan oleh serangkaian langkah, dan akhirnya menentukan operasi yang konsisten jika satu atau beberapa langkah gagal. Aplikasi yang dihosting di cloud yang menerapkan proses bisnis dan alur kerja yang kompleks sering kali mengikuti model konsistensi akhir ini.
  • Coba lagi memungkinkan aplikasi menangani kegagalan sementara saat mencoba menyambung ke layanan atau sumber daya jaringan, dengan mencoba kembali operasi yang gagal secara transparan. Coba lagi dapat meningkatkan stabilitas aplikasi.
  • Pemutus sirkuit menangani kesalahan yang memerlukan waktu pemulihan yang bervariasi, saat menyambung ke layanan atau sumber daya jarak jauh. Pemutus sirkuit dapat meningkatkan stabilitas dan ketahanan aplikasi.
  • Pemantauan titik akhir kesehatan menerapkan pemeriksaan fungsional dalam aplikasi yang dapat diakses oleh alat eksternal melalui titik akhir yang terbuka secara berkala. Pemantauan titik akhir kesehatan dapat membantu memverifikasi bahwa aplikasi dan layanan bekerja dengan benar.