An Architectural Pattern for Manage a Transactional and Data Consistency in Microservice.
Saga adalah urutan transaksi lokal di mana setiap transaksi berjalan pada sistem local masing-masing service. Transaksi pertama dimulai oleh permintaan eksternal yang sesuai dengan operasi sistem dan kemudian setiap langkah berikutnya dipicu oleh penyelesaian proses yang sebelumnya.
2. Latar
Belakang
Struggle dan kesalahan
implementasi
1. Pertanyaan dari teman-teman
2. Masih melihat cara implementasi yang salah
3. Banyak sistem yang telah migrasi ke
microservice malah lebih banyak masalahnya
4. Banyak yang takut dan tidak tahu bagaimana
implementasi microservice yang benar
5. Menjaga konsistensi data pada microservice
5. Data konsistensi mudah?
1. Konsistensi data adalah bagian terpenting dari
sebuah software.
2. Transactional cara untuk menjaga konsistensi data
(ACID).
3. Pada monolith menggunakan two phase commit
4. Local transaction dan global transaction.
5. Microservice tidak bisa dengan two phase commit.
7. 2 phase commit (2pc)
1. 2pc adalah protokol standar yang memastikan bahwa komit
database diimplementasikan dalam situasi di mana operasi komit
harus dipecah menjadi dua bagian terpisah.
2. Istilah pada 2pc
- Saving data = commit
- Undone data = rollback
1. Implementasi 2pc
- Tahap 1 - Setiap server atau database yang perlu melakukan
menulis data akan menulis datanya ke log. Jika server atau database
tidak berhasil, ia merespons dengan pesan kegagalan. Jika berhasil,
server atau database membalas dengan pesan OK.
8. 2 phase commit (2pc)
Tahap 2 - tahap ini dimulai setelah semua peserta menjawab OK.
Kemudian, koordinator mengirimkan sinyal ke setiap server dengan
instruksi komit. Setelah melakukan, masing-masing menulis komit
sebagai bagian dari rekaman lognya untuk referensi dan
mengirimkan pesan kepada koordinator bahwa komitnya telah
berhasil diterapkan. Jika server gagal, koordinator mengirimkan
instruksi ke semua server untuk membatalkan transaksi. Setelah
server rollback, masing-masing mengirimkan feedback bahwa
proses telah diselesaikan.
9. 1. Database harus support transaksional
2. Direct access pada database
3. Menggunakan driver yang support 2pc
4. Global transaksi membutuhkan aplikasi server seperti
Wildfly or WebLogic or Enduro/X in Go
Syarat 2 phase commit (2pc)
10. 1. Karena tabel-tabel berada pada database yang
berbeda-beda dan satu tabel di manage hanya oleh
satu service maka konsep two phase commit tidak
bisa kita gunakan lagi
2. Global transaksi hanya bisa pada database lama dan
tidak cocok untuk microservice karena kemungkinan
terdapat latency yang tinggi dan menyalahi aturan satu
database di manage oleh satu jenis service,
2pc dan Global Transaksi
11. Ada minimal empat service yang terlibat dalam proses pemesanan.
Setiap service memiliki database sendiri-sendiri dan setiap data yang
terkait satu sama lain harus konsisten.
12. pemesanan akan mencari data dari tabel konsumen melalui service
konsumen dan pada saat yang sama, menulis datanya ke kitchen service
dan tabel akuntansi melalui service account.
14. 1. Saga mengandung arti perjalanan saga pattern pertama kali
dipublikasi di tahun 1987 oleh Hector Garcia dan Molina and
Kenneth Salem.
2. Saga pattern digunakan pada long running transaksi yang
dapat dipecah ke dalam beberapa transaksi.
3. Saga pattern adalah arsitektural pattern yang dapat kita
gunakan untuk membangun sebuah microservice pattern
dan dikhususkan untuk menanggulangi masalah konsistensi
data.
4. Ada dua pendekatan saga pattern, event atau koreografi dan
command atau orkestrasi.
15. Saga adalah urutan transaksi lokal dimana setiap transaksi berjalan pada
sistem lokal masing-masing service. Transaksi pertama dimulai oleh
permintaan eksternal yang sesuai dengan pengoperasian sistem dan
kemudian setiap langkah berikutnya dipicu oleh penyelesaian proses
sebelumnya.
17. 1. Pada saga dengan implementasi event ciri utamanya
adalah proses tidak memiliki central atau pusat dari
sistem. Setiap service menghasilkan dan mendengarkan
event serta memutuskan apakah suatu tindakan harus
diambil atau tidak.
2. Saga pattern pada jenis ini akan berakhir jika service
terakhir yang terlibat melakukan transaksi lokal dan tidak
ada publish event apapun yang didengar oleh setiap
service yang terlibat pada saga.
18.
19. 1. Order Service menyimpan data order baru dan menentukan
state atau status pending dan sekaligus publish event dengan
nama, misalkan ORDER_CREATED.
2. Payment Service mendengarkan event ORDER_CREATED,
melakukan debet pada client, dan mempublish event
BILLED_ORDER. Pada proses ini triger bisa didatangkan juga dari
proses pembayaran yang dilakukan client.
3. Stock service mendengarkan event BILLED_ORDER, melakukan
update stok, melakukan persiapan untuk pengiriman produk
yang dibeli, dan mempublikasi event ORDER_PREPARED
20. 4. Delivery Service mendengarkan event ORDER_PREPARED
melakukan pengambilan dan mengirimkan product. Apabila
telah selesai dia akan mempublish ORDER_DELIVERED.
5. Akhirnya, Order Service mendengar even ORDER_DELIVERED
dan menentukan state dari order telah beres dijalankan atau
dengan kata lain keseluruhan order FINISH.
21. Pada kasus di atas, apabila kita berkeinginan untuk melakukan
track dari semua proses yang terjadi, bisa dilakukan dengan
mudah yaitu Order Service akan mendengarkan semua event
dan melakukan update dari setiap state atau status yang terjadi.
23. Rollback pada saga pattern dengan cara event atau koreografi ini
dijalankan dengan cara mempublish event yang tujuannya
mengembalikan proses yang telah dilakukan oleh proses-proses
sebelumnya. Sehingga proses rollback ini tidaklah terjadi secara
gratis. Kita mesti menuliskan code tambahan ketika rollback
terjadi.
24. 1. Stock Service mempublish event
PRODUCT_OUT_OF_STOCK
2. Kedua proses sebelumnya yaitu, Order dan
Payment akan mendengar event
PRODUCT_OUT_OF_STOCK dan melakukan
proses:
● Refund atau mengembalikan dana client
● Status pada Order Service ditetapkan sebagai
gagal.
26. 1. Event koreografi ini adalah pendekatan alami dalam
mengimplementasikan saga pattern. Caranya sederhana
dan mudah untuk di mengerti. Semua service yang terlibat
dalam transaksi sangat terbebas satu sama lain. Jika
transaksi kita cuma 2 atau sampai 5 tahap cara ini rasanya
adalah cara yang paling cocok untuk digunakan.
27. 2. Jika transaksi kita tahapannya sudah banyak dan
kemungkinan proses development kedepan diperkirakan
perubahan sangat besar maka proses transaksi yang kita
punya akan sulit untuk kita monitor. Bahkan cara kita untuk
melakukan test akan sangat sulit sekali, kita mesti menjaga
semua service jalan sehingga proses tes bisa dijalankan
dengan baik.
29. Pada pendekatan orkestrasi kita memerlukan satu service
tambahan yang berperan sebagi pusat pengendali. Service
ini akan memberikan sejumlah intruksi atau perintah dan
berkomunikasi dengan semua service yang terlibat dalam
transaksi.
32. 1. ORDER_SERVICE akan meminta OSO untuk memulai
menjalankan proses transaksi dan menyimpan status Order
sebagai Pending.
2. OSO akan mengirimkan perintah ke PAYMENT_SERVICE untuk
menjalankan proses pembayaran. Service ini akan memberikan
reply balik berupa proses berhasil ataupun gagal melalui saga
reply chanel.
3. Apabila PAYMENT_SERVICE memberikan pesan bahwa
payment telah tereksekusi maka OSO akan memberikan
perintah ke STOCK_SERVICE untuk melakukan persiapan
pengiriman barang.
33. 4. STOCK_SERVICE akan memberikan pesan bahwa proses bisa di
lanjutkan karena stock tersedia dan OSO menerimanya sebagai
ORDER_PREPARED
5. OSO akan memberikan peritah ke DELIVERY_SERVICE untuk
melakukan pengiriman dan jika suskes akan memberikan
pesan ke OSO bahwa ORDER_DELIVERED.
6. OSO akan menyimpan status Order Finish.
35. Pada pendekatan orkestrasi ini proses rollback juga mudah untuk dilakukan.
Setiap service tinggal memberikan pesan ke command center dan OSO akan
menentukan proses selanjutnya.
36. 1. Stock Service mempublish event ke channel replay
Chanel dengan pesan PRODUCT_OUT_OF_STOCK
2. OSO akan mendengar event PRODUCT_OUT_OF_STOCK
dan melakukan proses rollback.
● OSO mengirimkan pesan Refund ke PAYMENT_SERVICE
● PAYMENT_SERVICE mengembalikan dana customer.
● Status pada Order Service ditetapkan sebagai gagal.
38. Kelebihan
1. Meniadakan ketergantungan antar service.
2. Distribusi transaksi terpusat.
3. Mudah untuk diimplementasikan dan di test.
4. Tingkat kesusahan dari transaksi bersifat linear.
5. Proses rollback mudah untuk ditangani.
6. Jika terdapat penambahan atau pengurangan proses
dan service yang terlibat sangat mudah untuk
dilakukan.
39. Kekurangan
1. Secara infrastruktur semakin banyak dan semakin
sulit karena harus memanage service tambahan
2. Hati-hati jika terjadi konsentrasi banyak sekali logika
yang terpusat di OSO.
3. OSO harus di jaga dan diyakinkan tingkat
avaibilitynya.
40. Tips Saga Pattern
Unik Id Setiap Transaksi Replay Chanel
Reply chanel cukup satu (nama
proses dan message)
Idempotent Proses Asynchronous Prosess
Ideal process, cost
efficient and effective
01
03 04
02
44. CREDITS: This presentation template was created by Slidesgo, including
icons by Flaticon, infographics & images by Freepik and illustrations by
Stories
Thanks!
Do you have any questions?
dhfr123@gmail.com
+62 82117419014
https://medium.com/the-legend
https://www.linkedin.com/in/deni-husni-fahri-rizal-76954235/