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.
Konsistensi
Poin yang agak halus adalah bahwa konsistensi dalam konteks sistem terdistribusi berbeda dari konsistensi dalam konteks basis data. Selanjutnya, dengan konsistensi, yang kami maksud adalah yang pertama: operasi yang tidak lengkap (salah) tidak menimbulkan efek apa pun dan tidak mengubah data; dengan akses bersamaan ke data, semua operasi dianggap atom (Anda tidak dapat melihat hasil perantara dari operasi) jika data memiliki banyak salinan (replikasi) , maka urutan penerapan operasi pada semua salinan adalah sama. Artinya, sebenarnya kami ingin menerima transaksi ACID, tetapi hanya transaksi terdistribusi.
Penyebab masalahnya
Mengapa sulit untuk mempertahankan konsistensi dalam arsitektur layanan mikro? Faktanya adalah bahwa gaya arsitektur ini sering kali melibatkan penggunaan database per pola layanan. Izinkan saya mengingatkan Anda bahwa pola ini terdiri dari fakta bahwa setiap layanan mikro memiliki basis atau basis independennya sendiri (basis, karena selain sumber data primer, misalnya, cache dapat digunakan). Pendekatan ini memungkinkan, di satu sisi, untuk tidak menambahkan tautan format data implisit antara layanan mikro (layanan mikro berinteraksi hanya secara eksplisit melalui API), di sisi lain, untuk memanfaatkan sebaik-baiknya arsitektur layanan mikro sebagai teknologi agnostik (kita dapat memilih teknologi penyimpanan data yang sesuai untuk beban tertentu pada layanan mikro) ). Namun dengan semua ini, kami kehilangan jaminan konsistensi data. Menilai sendirimonolit tersebut dikomunikasikan dengan satu database besar, yang menyediakan kemampuan untuk menyediakan transaksi ACID. Sekarang ada banyak database, dan alih-alih satu transaksi ACID besar, kami memiliki banyak transaksi ACID kecil. Tugas kita adalah menggabungkan semua transaksi ini menjadi satudidistribusikan .
Konsistensi yang optimis
Hal pertama yang terlintas dalam pikiran adalah konsep konsistensi optimis: kami melakukan transaksi sebanyak yang kami inginkan untuk mesin penyimpanan sebanyak yang diperlukan. Pada saat yang sama, kami berharap semuanya akan baik-baik saja, dan jika semuanya buruk, maka kami mengatakan bahwa pada akhirnya semuanya akan baik-baik saja. Jika semuanya buruk pada akhirnya, maka kita berkata: "Ya, ini terjadi, tetapi dengan probabilitas yang sangat rendah."
Selain bercanda, mengabaikan konsistensi ketika bisnis bukanlah hal yang penting adalah ide yang bagus, terutama ketika Anda mempertimbangkan berapa banyak usaha yang akan kami keluarkan untuk mempertahankannya (yang saya harap Anda akan melihatnya nanti).
Opsi konsistensi
Jika konsistensi sangat penting untuk bisnis, ada beberapa cara untuk mencoba mencapainya. Jika kita berbicara tentang situasi di mana data diperbarui oleh satu layanan (misalnya, ada replikasi database), maka algoritma konsistensi standar seperti Paxos atau Raft dapat diterapkan. Transaksi semacam itu disebut homogen . Jika data diperbarui oleh beberapa layanan (yaitu, transaksi heterogen terjadi ), lalu bagaimana kerumitannya dimulai, yang telah kita bicarakan di atas.
Di satu sisi, kami masih dapat melewati kebutuhan untuk menyediakan transaksi terdistribusi dengan mengupayakan arsitektur berbasis layanan (kami menggabungkan layanan sedemikian rupa sehingga transaksinya homogen). Solusi semacam itu tidak terlalu kanonik dari sudut pandang prinsip arsitektur layanan mikro, tetapi secara teknis jauh lebih sederhana, itulah sebabnya sering digunakan dalam praktik. Di sisi lain, kita dapat meninggalkan layanan mikro kanonik, tetapi pada saat yang sama menerapkan salah satu mekanisme untuk memastikan transaksi terdistribusi: komit dua fase atau saga. Artikel ini akan membahas opsi pertama dan membahas opsi kedua di lain waktu.
Komit dua fase
Mekanismenya sangat sederhana: ada beberapa manajer transaksi yang benar-benar mengatur transaksi. Pada tahap pertama (persiapkan), manajer transaksi mengeluarkan perintah yang sesuai untuk manajer sumber daya, yang menurutnya mereka menulis data ke log yang akan dilakukan. Setelah menerima konfirmasi dari semua manajer sumber daya tentang keberhasilan penyelesaian tahap pertama, manajer transaksi memulai tahap kedua dan mengeluarkan perintah berikutnya (komit), yang menurutnya manajer sumber daya menerapkan perubahan yang diterima sebelumnya.
Meskipun terlihat sederhana, pendekatan ini memiliki sejumlah kelemahan. Pertama, jika setidaknya satu pengelola sumber daya gagal pada fase kedua, seluruh transaksi harus dibatalkan. Dengan demikian, salah satu prinsip arsitektur layanan mikro dilanggar - resistensi terhadap kegagalan (ketika kami sampai pada sistem terdistribusi, kami segera berasumsi bahwa kegagalan di dalamnya adalah norma dan bukan situasi yang luar biasa). Apalagi jika terjadi banyak kegagalan (dan akan banyak jumlahnya), maka proses pembatalan transaksi perlu diotomatiskan (termasuk penulisan transaksi yang melakukan rollback transaksi). Kedua, manajer transaksi itu sendiri adalah satu titik kegagalan. Dia harus bisa mengeluarkan id-shnik secara transaksional untuk transaksi. Ketiga, karena perintah khusus diberikan ke repositori, logis untuk mengasumsikan bahwa repositori harus dapat melakukan ini,artinya, mematuhi standar XA, dan tidak semua teknologi modern mematuhinya (broker seperti solusi Kafka, RabbitMQ, dan NoSQL seperti MongoDB dan Cassandra tidak mendukung komitmen dua fase).
Kesimpulan yang menunjukkan dirinya dari semua faktor ini diartikulasikan dengan indah oleh Chris Richardson: "2PC bukan opsi" (komit dua fase bukanlah opsi).
Keluaran
Kami menemukan mengapa transaksi terdistribusi adalah masalah teknis utama dari arsitektur layanan mikro dan membicarakan berbagai opsi untuk memecahkan masalah ini, membahas secara rinci mekanisme komit dua fase.
Saya mengundang semua orang untuk mendaftar ke webinar saya tentang kursus ini , di mana saya akan memberi tahu Anda secara rinci tentang format pelatihan dan memperkenalkan semua orang ke program pelatihan.