Saya baru saja membaca artikel ini , dan saya bingung.
Mari kita bayangkan 1 webapp dan 1 aplikasi berbeda yang bertindak sebagai "pekerja", keduanya berbagi database yang sama .
Oh, saya bilang "sharing" .. tapi apa yang diperingatkan artikel itu? :
Keempat, berbagi basis data antar aplikasi (atau layanan) adalah hal yang buruk. Terlalu menggoda untuk menempatkan keadaan berbagi amorf di sana dan sebelum Anda menyadarinya, Anda akan memiliki monster yang sangat berpasangan.
=> tidak setuju. Ada beberapa kasus di mana aplikasi yang berbeda masih menjadi bagian dari unit yang sama, dan karena itu, gagasan "masalah kopling" tidak masuk akal dalam kasus ini.
Mari kita lanjutkan: Webapp menangani permintaan HTTP klien dan dapat memperbarui kapan saja beberapa agregat (istilah DDD), menghasilkan peristiwa domain yang sesuai.
Tujuan pekerja adalah untuk menangani peristiwa domain tersebut dengan memproses pekerjaan yang dibutuhkan.
Intinya adalah:
Bagaimana seharusnya data acara diteruskan ke pekerja?
Solusi pertama, seperti yang dipromosikan artikel baca, adalah menggunakan RabbitMQ, menjadi middleware berorientasi pesan yang hebat.
Alur kerjanya akan sederhana:
Setiap kali dyno web membuat suatu acara, itu mempublikasikannya melalui RabbitMQ, yang memberi makan pekerja.
Kekurangannya adalah tidak ada yang menjamin konsistensi langsung antara komitmen pembaruan agregat dan penerbitan acara, tanpa berurusan dengan potensi kegagalan pengiriman ... atau masalah perangkat keras; itu adalah masalah utama lainnya.
Contoh: Ada kemungkinan bahwa suatu peristiwa diterbitkan tanpa keberhasilan pembaruan agregat ... menghasilkan suatu peristiwa yang mewakili representasi palsu dari model domain.
Anda bisa berargumen bahwa XA global (komit dua fase) ada, tetapi itu bukan solusi yang cocok untuk semua basis data atau middlewares.
Jadi apa yang bisa menjadi solusi yang baik untuk memastikan konsistensi langsung ini? :
IMO, menyimpan acara dalam database, dalam transaksi lokal yang sama dengan pembaruan agregat.
Penjadwal asinkron sederhana akan dibuat dan bertanggung jawab untuk menanyakan peristiwa yang tidak dipublikasikan saat ini dari basis data dan mengirimkannya ke RabbitMQ, yang pada gilirannya mengisi pekerja tersebut.
Tapi mengapa perlu penjadwal tambahan di sisi webapp dan omong-omong: mengapa membutuhkan RabbitMQ dalam kasus ini?
Dengan solusi ini, tampaknya secara logis, bahwa RabbitMQ dapat menjadi tidak perlu, terutama karena database digunakan bersama.
Memang, apa pun masalahnya, kami melihat bahwa konsistensi langsung melibatkan pemungutan suara dari database.
Jadi, mengapa pekerja tidak akan bertanggung jawab langsung atas pemungutan suara ini?
Oleh karena itu, saya bertanya-tanya mengapa begitu banyak artikel di web yang mengkritik antrian basis data, sembari mempromosikan middleware yang berorientasi pesan.
Kutipan artikel:
Sederhana, gunakan alat yang tepat untuk pekerjaan itu: skenario ini menyerukan sistem pesan. Ini memecahkan semua masalah yang dijelaskan di atas; tidak ada lagi jajak pendapat, pengiriman pesan yang efisien, tidak perlu menghapus pesan yang selesai dari antrian, dan tidak ada keadaan bersama.
Dan konsistensi langsung, diabaikan?
Singkatnya, tampaknya apa pun masalahnya, artinya database dibagikan atau tidak, kita perlu jajak pendapat database .
Apakah saya kehilangan beberapa gagasan kritis?
Terima kasih