Pemesejan Boleh Dipercayai dalam Sistem Teragih

Masalah dwitulisan

Membina sistem teragih yang boleh dipercayai, sangat tersedia, berskala memerlukan pematuhan kepada teknik, prinsip dan corak tertentu. Reka bentuk sistem sedemikian melibatkan menangani pelbagai cabaran. Antara isu yang paling lazim dan asas ialah masalah dwitulisan .

"Masalah penulisan dwi" ialah cabaran yang timbul dalam sistem teragih, terutamanya apabila berurusan dengan berbilang sumber data atau pangkalan data yang perlu disegerakkan. Ia merujuk kepada kesukaran untuk memastikan perubahan data ditulis secara konsisten ke pelbagai stor data, seperti pangkalan data atau cache, tanpa memperkenalkan isu seperti ketidakkonsistenan data, konflik atau kesesakan prestasi.

Seni bina perkhidmatan mikro dan pangkalan data corak bagi setiap perkhidmatan memberi anda banyak faedah, seperti penggunaan dan penskalaan bebas, kegagalan terpencil dan potensi peningkatan halaju pembangunan. Walau bagaimanapun, operasi memerlukan perubahan antara pelbagai perkhidmatan mikro, memaksa anda memikirkan penyelesaian yang boleh dipercayai untuk menangani masalah ini.

Hampir contoh sebenar

Mari kita pertimbangkan senario di mana domain kami melibatkan penerimaan permohonan pinjaman, menilai mereka dan kemudian menghantar makluman pemberitahuan kepada pelanggan.

Berdasarkan semangat prinsip tanggungjawab tunggal, undang-undang Conway, dan pendekatan reka bentuk dipacu domain, selepas beberapa sesi pencerobohan peristiwa, keseluruhan domain dipecahkan kepada tiga subdomain dengan konteks sempadan yang ditakrifkan yang mempunyai sempadan yang jelas, model domain dan bahasa di mana-mana.

Yang pertama ditugaskan untuk menyiapkan dan menyusun permohonan pinjaman baharu. Sistem kedua menilai aplikasi ini dan membuat keputusan berdasarkan data yang diberikan. Proses penilaian ini, termasuk KYC/KYB, antifraud dan semakan risiko kredit, boleh memakan masa, memerlukan keupayaan untuk mengendalikan beribu-ribu permohonan secara serentak. Akibatnya, fungsi ini telah diwakilkan kepada perkhidmatan mikro khusus dengan pangkalan datanya sendiri, membolehkan penskalaan bebas.

Tambahan pula, subsistem ini diuruskan oleh dua pasukan berbeza, masing-masing mempunyai kitaran keluaran sendiri, perjanjian tahap perkhidmatan (SLA) dan keperluan skalabiliti.

Akhir sekali , perkhidmatan pemberitahuan khusus disediakan untuk menghantar makluman kepada pelanggan.

Berikut ialah huraian terperinci tentang kes penggunaan utama sistem:

1. Seorang pelanggan mengemukakan permohonan pinjaman.
2. Perkhidmatan Permohonan Pinjaman merekodkan permohonan baharu dengan status "Pending" dan memulakan proses penilaian dengan memajukan permohonan kepada Perkhidmatan Penilaian.
3. Perkhidmatan Penilaian menilai permohonan pinjaman yang masuk dan seterusnya memaklumkan keputusan tersebut kepada Perkhidmatan Permohonan Pinjaman.
4. Setelah menerima keputusan, Perkhidmatan Permohonan Pinjaman mengemas kini status permohonan pinjaman dengan sewajarnya dan mencetuskan Perkhidmatan Pemberitahuan untuk memaklumkan kepada pelanggan tentang hasilnya.
5. Perkhidmatan Pemberitahuan memproses permintaan ini dan menghantar pemberitahuan kepada pelanggan melalui e-mel, SMS atau kaedah komunikasi pilihan lain, mengikut tetapan pelanggan.

Ia adalah sistem yang agak mudah dan primitif pada pandangan pertama, tetapi mari kita selami bagaimana perkhidmatan permohonan Pinjaman memproses arahan serah permohonan pinjaman.

Kami boleh mempertimbangkan dua pendekatan untuk interaksi perkhidmatan:

1. First-Local-Commit-Then-Publish: Dalam pendekatan ini, perkhidmatan mengemas kini pangkalan data setempatnya (commit) dan kemudian menerbitkan acara atau mesej kepada perkhidmatan lain.

2. First-Publish-Then-Local-Commit: Sebaliknya, kaedah ini melibatkan penerbitan acara atau mesej sebelum melakukan perubahan pada pangkalan data setempat.

   
   

Kedua-dua kaedah mempunyai kelemahan mereka dan hanya sebahagiannya gagal-selamat untuk komunikasi dalam sistem teragih.

Ini ialah rajah jujukan menggunakan pendekatan pertama.

Dalam senario ini, Perkhidmatan Permohonan Pinjaman menggunakan pendekatan First-Local-Commit-Then-Publish , di mana ia mula-mula melakukan transaksi dan kemudian cuba menghantar pemberitahuan kepada sistem lain. Walau bagaimanapun, proses ini terdedah kepada kegagalan jika, sebagai contoh, terdapat isu rangkaian, Perkhidmatan Penilaian tidak tersedia, atau Perkhidmatan Permohonan Pinjaman menghadapi ralat Habis Ingatan (OOM) dan ranap. Dalam kes sedemikian, mesej akan hilang, meninggalkan Penilaian tanpa notis permohonan pinjaman baharu, melainkan langkah tambahan dilaksanakan.

Dan yang kedua.

Dalam senario First-Publish-Then-Local-Commit , Perkhidmatan Permohonan Pinjaman menghadapi risiko yang lebih ketara. Ia mungkin memaklumkan Perkhidmatan Penilaian tentang aplikasi baharu tetapi gagal menyimpan kemas kini ini secara setempat disebabkan masalah seperti isu pangkalan data, ralat memori atau pepijat kod. Pendekatan ini boleh membawa kepada ketidakkonsistenan yang ketara dalam data, yang boleh menyebabkan masalah serius, bergantung pada cara Perkhidmatan Semakan Pinjaman mengendalikan permohonan yang masuk.

Oleh itu, kita mesti mengenal pasti penyelesaian yang menawarkan mekanisme yang teguh untuk menerbitkan acara kepada pengguna luar. Tetapi, sebelum menyelidiki penyelesaian yang berpotensi, kita harus terlebih dahulu menjelaskan jenis jaminan penghantaran mesej yang boleh dicapai dalam sistem yang diedarkan.

Jaminan penghantaran mesej

Terdapat empat jenis jaminan yang boleh kami capai.

1. Tiada jaminan
   Tiada jaminan bahawa mesej akan dihantar ke destinasi. Pendekatan First-Local-Commit-Then-Publish adalah tepat mengenai perkara ini. Pengguna mungkin menerima mesej sekali, beberapa kali, atau tidak sama sekali.

2. Paling banyak sekali penghantaran
   Paling banyak sekali penghantaran bermakna mesej akan dihantar ke destinasi paling banyak 1 kali. Pendekatan First-Local-Commit-Then-Publish boleh dilaksanakan dengan cara ini juga dengan dasar cuba semula percubaan dengan nilai satu.

3. Sekurang-kurangnya sekali penghantaran\Pengguna akan menerima dan memproses setiap mesej tetapi mungkin menerima mesej yang sama lebih daripada sekali.

4. Tepat sekali penghantaran\Tepat sekali penghantaran bermakna pengguna akan menerima mesej dengan berkesan sekali.
   Secara teknikal, adalah mungkin untuk dicapai dengan transaksi Kafka dan pelaksanaan idempoten khusus pengeluar dan pengguna.

   
   

Dalam kebanyakan kes, jaminan penghantaran 'sekurang-kurangnya sekali' menangani banyak isu dengan memastikan mesej dihantar sekurang-kurangnya sekali, tetapi pengguna mesti mempunyai idempoten. Walau bagaimanapun, memandangkan kegagalan rangkaian yang tidak dapat dielakkan, semua logik pengguna mestilah idempoten untuk mengelakkan pemprosesan mesej pendua, tanpa mengira jaminan pengeluar. Oleh itu, keperluan ini bukanlah satu kelemahan kerana ia mencerminkan realiti.

Penyelesaian

Terdapat banyak penyelesaian untuk masalah ini, yang mempunyai kelebihan dan kekurangannya.

Komit dua fasa

Menurut Wikipedia, Komit Dua Fasa (2PC) ialah protokol transaksi teragih yang digunakan dalam sains komputer dan sistem pengurusan pangkalan data untuk memastikan ketekalan dan kebolehpercayaan transaksi yang diedarkan. Ia direka untuk situasi di mana berbilang sumber (cth, pangkalan data) perlu mengambil bahagian dalam satu transaksi, dan ia memastikan sama ada kesemuanya melakukan transaksi atau kesemuanya membatalkannya, dengan itu mengekalkan konsistensi data. Kedengarannya seperti yang kita perlukan, tetapi Komit Dua Fasa mempunyai beberapa kelemahan:

• Jika satu sumber yang mengambil bahagian menjadi tidak bertindak balas atau mengalami kegagalan, keseluruhan proses boleh disekat sehingga isu itu diselesaikan. Ini boleh membawa kepada potensi masalah prestasi dan ketersediaan.
• Komit Dua Fasa tidak menyediakan mekanisme toleransi kesalahan terbina dalam. Ia bergantung pada mekanisme luaran atau campur tangan manual untuk menangani kegagalan.
• Tidak semua pangkalan data moden menyokong Komit Dua Fasa.

Pangkalan data dikongsi

Penyelesaian yang paling jelas untuk seni bina perkhidmatan mikro ialah menggunakan corak (atau kadangkala anti-corak) — pangkalan data dikongsi. Pendekatan ini sangat intuitif jika anda memerlukan konsistensi transaksi merentas berbilang jadual dalam pangkalan data yang berbeza, hanya gunakan satu pangkalan data dikongsi untuk perkhidmatan mikro ini.

Kelemahan pendekatan ini termasuk memperkenalkan satu titik kegagalan, menghalang penskalaan pangkalan data bebas, dan mengehadkan keupayaan untuk menggunakan penyelesaian pangkalan data berbeza yang paling sesuai untuk keperluan dan kes penggunaan tertentu. Selain itu, pengubahsuaian kepada pangkalan kod mikroperkhidmatan akan diperlukan untuk menyokong bentuk transaksi yang diedarkan.

Peti keluar transaksi

' Kotak keluar transaksi ' ialah corak reka bentuk yang digunakan dalam sistem teragih untuk memastikan penyebaran mesej yang boleh dipercayai, walaupun dalam menghadapi sistem pemesejan yang tidak boleh dipercayai. Ia melibatkan penyimpanan peristiwa dalam jadual 'OutboxEvents' yang ditetapkan dalam transaksi yang sama seperti operasi itu sendiri. Pendekatan ini selaras dengan baik dengan sifat ACID pangkalan data hubungan. Sebaliknya, banyak pangkalan data No-SQL tidak menyokong sepenuhnya sifat ACID, sebaliknya memilih prinsip teorem CAP dan falsafah BASE, yang mengutamakan ketersediaan dan konsistensi akhirnya daripada konsistensi yang ketat.

Peti keluar transaksi menyediakan sekurang-kurangnya sekali jaminan dan boleh dilaksanakan dengan beberapa pendekatan:

1. Tailing log transaksi

2. Penerbit undian

   
   

Pendekatan tailing log transaksi membayangkan penggunaan penyelesaian khusus pangkalan data seperti CDC (Tukar Tangkapan Data). Kelemahan utama pendekatan itu ialah:

• Penyelesaian khusus pangkalan data

• Peningkatan kependaman disebabkan oleh spesifik pelaksanaan CDC

  
  

Kaedah lain ialah Publisher Polling , yang memudahkan pemuatan peti keluar dengan mengundi jadual peti keluar. Kelemahan utama pendekatan ini ialah potensi peningkatan beban pangkalan data, yang boleh membawa kepada kos yang lebih tinggi. Tambahan pula, bukan semua pangkalan data No-SQL menyokong pertanyaan yang cekap untuk segmen dokumen tertentu. Oleh itu, mengekstrak keseluruhan dokumen boleh mengakibatkan kemerosotan prestasi.

Berikut ialah rajah jujukan kecil yang menerangkan cara ia berfungsi.

Dengar sendiri

Cabaran utama dengan corak Peti Keluar Transaksi terletak pada pergantungannya pada sifat ACID pangkalan data. Ia mungkin mudah dalam pangkalan data OLTP biasa tetapi menimbulkan cabaran dalam alam NoSQL. Untuk menangani perkara ini, penyelesaian yang berpotensi adalah dengan memanfaatkan log tambahan (contohnya, Kafka) terus daripada memulakan pemprosesan permintaan.

Daripada memproses terus arahan 'serahkan permohonan pinjaman', kami segera menghantarnya ke topik Kafka dalaman dan kemudian mengembalikan keputusan 'diterima' kepada pelanggan. Walau bagaimanapun, memandangkan kemungkinan besar arahan itu masih perlu diproses, kami tidak boleh segera memaklumkan keputusan itu kepada pelanggan. Untuk mengurus ketekalan akhirnya ini, kami boleh menggunakan teknik seperti tinjauan panjang, tinjauan pendapat yang dimulakan pelanggan, kemas kini UI yang optimistik atau menggunakan WebSockets atau Acara Dihantar Pelayan untuk pemberitahuan. Walau bagaimanapun, ini adalah topik yang berbeza sama sekali, jadi mari kita kembali kepada subjek awal kita.

Kami menghantar mesej mengenai topik Kafka dalaman. Perkhidmatan Permohonan Pinjaman kemudian menggunakan mesej ini — arahan yang sama yang diterima daripada pelanggan — dan mula memproses. Pertama, ia melaksanakan beberapa logik perniagaan; hanya selepas logik ini berjaya dilaksanakan dan hasilnya berterusan, ia menerbitkan mesej baharu mengenai topik Kafka awam.

Mari kita lihat sedikit pseudo-kod.

 public async Task HandleAsync(SubmitLoanApplicationCommand command, ...) { //First, process business logic var loanApplication = await _loanApplicationService.HandleCommandAsync(command, ...); //Then, send new events to public Kafka topic producer.Send(new LoanApplicationSubmittedEvent(loanApplication.Id)); //Then, commit offset consumer.Commit(); }

Bagaimana jika pemprosesan logik perniagaan gagal? Jangan risau, memandangkan offset belum dilakukan, mesej akan dicuba semula.

Bagaimana jika menghantar acara baharu kepada Kafka gagal? Jangan risau, kerana logik perniagaan adalah idempoten, ia tidak akan membuat permohonan pinjaman pendua. Sebaliknya, ia akan cuba menghantar semula mesej kepada topik Kafka awam.

Bagaimana jika mesej dihantar ke Kafka, tetapi komit offset gagal? Jangan risau, kerana logik perniagaan adalah idempoten, ia tidak akan membuat permohonan pinjaman pendua. Sebaliknya, ia akan menghantar semula mesej kepada topik Kafka awam dan berharap komit offset berjaya kali ini.

Kelemahan utama pendekatan ini termasuk kerumitan tambahan yang dikaitkan dengan gaya pengaturcaraan baharu, ketekalan akhirnya (kerana pelanggan tidak akan segera mengetahui hasilnya), dan keperluan untuk semua logik perniagaan menjadi idempoten.

Sumber acara

Apakah sumber acara, dan bagaimanakah ia boleh digunakan di sini? Penyumberan acara ialah corak seni bina perisian yang digunakan untuk memodelkan keadaan sistem dengan menangkap semua perubahan pada datanya sebagai satu siri peristiwa tidak berubah. Peristiwa ini mewakili fakta atau peralihan keadaan dan berfungsi sebagai sumber tunggal kebenaran untuk keadaan semasa sistem. Jadi, secara teknikalnya, dengan melaksanakan sistem penyumberan acara, kami sudah mempunyai semua acara dalam EventStore, dan EventStore ini boleh digunakan oleh pengguna sebagai satu sumber kebenaran tentang apa yang berlaku. Tidak ada keperluan untuk penyelesaian pangkalan data khusus untuk menjejaki semua perubahan atau kebimbangan mengenai pesanan, satu-satunya masalah ialah duduk di sebelah baca kerana untuk mendapatkan keadaan sebenar entiti diperlukan untuk memainkan semula semua acara.

Kesimpulan

Dalam artikel ini, kami menyemak beberapa pendekatan untuk membina pemesejan yang boleh dipercayai dalam sistem teragih. Terdapat beberapa cadangan yang mungkin kami pertimbangkan semasa membina sistem dengan ciri-ciri ini

1. Sentiasa membangunkan pengguna idempoten kerana kegagalan rangkaian tidak dapat dielakkan.
2. Berhati-hati menggunakan First-Local-Commit-Then-Publish dengan pemahaman yang jelas tentang keperluan jaminan.
3. Jangan sekali-kali menggunakan pendekatan First-Publish-Then-Local-Commit kerana ia boleh menyebabkan ketidakkonsistenan data yang teruk dalam sistem anda.
4. Jika keputusan pilihan pangkalan data sedia ada berkemungkinan besar mungkin berubah atau strategi teknikal membayangkan untuk memilih penyelesaian storan terbaik untuk masalah itu — jangan bina perpustakaan kongsi dengan mengikat kepada penyelesaian pangkalan data seperti CDC .
5. Gunakan pendekatan Peti Keluar Transaksi sebagai penyelesaian standard untuk mencapai sekurang-kurangnya sekali jaminan.
6. Pertimbangkan untuk menggunakan pendekatan Dengar sendiri apabila pangkalan data No-SQL dimanfaatkan.

Kali seterusnya, kita akan melihat contoh yang lebih praktikal untuk melaksanakan Peti Keluar Transaksi. Lihat

awak!