Apakah Akka sudah usang dengan perantara pesan JMS / AMQP? [Tutup]

19

Saya menghabiskan minggu terakhir menyelam dalam-dalam ke dokumen Akka dan akhirnya memahami apa sistem aktor, dan masalah yang mereka pecahkan.

Pemahaman saya (dan pengalaman dengan) pialang pesan tradisional JMS / AMQP adalah bahwa mereka ada untuk menyediakan yang berikut:

  • Pemrosesan yang tidak sinkron antara produsen dan konsumen; dan
  • Jaminan pengiriman pesan, termasuk ketekunan, coba lagi, dan fallback

Tetapi bukankah Akka menyediakan ini, tanpa semua infrastruktur dan biaya operasional yang diperlukan?

  • Di Akka, semua komunikasi Aktor tidak sinkron dan non-pemblokiran; dan
  • Di Akka, SupervisorStrategiesada untuk mencapai coba lagi, mundur dan naik. Aktor dapat dikonfigurasi untuk bertahan pada hampir semua jenis toko, jika ini merupakan persyaratan juga.

Jadi ini membuat saya bertanya-tanya: jika aplikasi saya menggunakan Akka, apakah saya pernah perlu membawa broker JMS / AMQP (mis. ActiveMQ, RabbitMQ, Kafka) ke dalam gambar? Dengan kata lain, apakah ada yang pernah kasus penggunaan di mana aplikasi baru berbasis Akka akan kemudian juga menjamin pengenalan baru JMS / AMQP broker klaster? Mengapa atau mengapa tidak?

Satu-satunya argumen adalah mungkin aplikasi Akka saya harus berintegrasi dengan sistem lain. Tetapi dalam kasus itu, modul Akka-Camel memungkinkan Akka untuk memasuki daftar lengkap kemampuan integrasi Camel yang hampir tak terbatas (TCP, FTP, ZeroMQ, daftarnya berjalan terus dan terus ...).

Pikiran?

asynchronous-programming message-queue messaging akka smeeb
sumber
3
Bukankah paragraf terakhir Anda menjadi alasan mengapa Akka tidak membuat perantara pesan menjadi usang? Sebagai contoh, saya sedang mengerjakan aplikasi Java yang berinteraksi dengan aplikasi C ++ jarak jauh melalui broker pesan yang sesuai dengan JMS. Saya dapat menulis aplikasi Java saya menggunakan Akka-Camel, tetapi saya masih membutuhkan broker karena aplikasi C ++.
Thomas Owens
Ahhh terima kasih @ThomasOwens (+1) tetapi Anda (memang seharusnya) salah mengerti pertanyaan saya. Saya akan mengubah kata-katanya dalam beberapa menit sehingga lebih jelas. Apa yang saya benar-benar bertanya adalah: jika saya membangun sebuah aplikasi Akka, akan saya merasa perlu untuk juga memperkenalkan baru broker JMS / AMQP? Saya pikir jawabannya adalah "tidak", karena Akka + Camel (sekali lagi saya pikir ) menyelesaikan semua masalah yang biasanya diselesaikan oleh broker. Dalam contoh Anda, broker JMS sudah ada sebagai cara untuk berkomunikasi dengan aplikasi C ++; Saya tidak menambahkannya bersama dengan aplikasi Akka baru saya. Dan modul Akka-Camel akan mengatur pengiriman pesan untuk saya.
smeeb
2
Mungkin saya salah paham, tetapi Camel tidak menggantikan JMS (misalnya), tetapi ia menyediakan antarmuka yang dapat digunakan untuk mengirim pesan melalui JMS. Anda dapat mengganti JMS dengan AMQP, RabbitMQ, atau XMPP. Dalam contoh saya, bahkan jika aplikasi Java + Akka dan C ++ saya adalah merek baru, agar mereka dapat berkomunikasi melalui JMS, saya masih perlu memperkenalkan beberapa jenis antrian pesan yang sesuai dengan JMS dan kemudian saya dapat menggunakan Akka-Camel untuk berkomunikasi dengannya. Camel tidak menyediakan broker, hanya sarana untuk berkomunikasi dalam sejumlah protokol. Akka-Camel menyediakan antarmuka yang lebih akrab dibandingkan antarmuka Camel.
Thomas Owens
Terima kasih lagi @ThomasOwens (+1) - Saya pikir Anda terlalu banyak berpikir :-). Dalam contoh Anda ada aplikasi C ++ yang ada - mungkin beberapa sistem lama, dan ada broker yang mematuhi JMS yang sudah digunakan aplikasi C ++ untuk berintegrasi dengan dunia luar. Dalam hal ini, aplikasi Akka baru saya akan - seperti yang Anda katakan - menggunakan modul Akka-Camel untuk menghasilkan / mengkonsumsi pesan ke / dari broker ini. Tapi ini bukan yang saya minta di sini! Saya ingin tahu apakah ada alasan mengapa saya harus membangun 2 hal : (1) aplikasi Akka baru saya, dan (2) broker JMS / AMQP, pada saat yang sama ...
smeeb
3
Anda menyebutkan kemampuan integrasi tak terbatas Camel tetapi tidak dapat berintegrasi dengan Nothing. Perlu ada sesuatu untuk diintegrasikan, jika tidak, Anda hanya menikmati dukungan untuk banyak layanan yang tidak Anda jalankan. Mulai JMS, atau server HTTP atau FTP atau sesuatu jika Anda ingin menggunakan Unta untuk berintegrasi dengan sesuatu. Kalau tidak, itu hanya dengan senang hati memberikan kemampuan integrasi tanpa batas sambil berintegrasi dengan apa pun.
Jimmy Hoffa

Jawaban:

12

Model Aktor

Model aktor adalah strategi ilmu komputer untuk membangun aplikasi yang menangani banyak komputasi bersamaan dan pemrosesan stateful. Ini bukan satu-satunya strategi tetapi ini adalah pendekatan yang teruji dengan sangat baik, sederhana, dan andal yang menggerakkan komputasi menjadi aktor , yang berkomunikasi melalui pesan yang mereka proses satu per satu dan dalam urutan.

Akka adalah kerangka kerja yang mengimplementasikan model aktor dan memungkinkan Anda untuk membangun sistem aktor dengan semua infrastruktur dan fitur yang sudah dibangun (seperti menggunakan JQuery alih-alih javascript).

Olahpesan

Sistem pesan adalah aplikasi yang dapat mengirim dan mengambil pesan. Ada banyak variasi dari antrian dasar ke perangkat lunak perusahaan besar dengan topik, pub / sub, kegigihan dan fitur lainnya tetapi tujuan akhirnya adalah sama. Simpan beberapa byte di suatu tempat dan ambil lagi nanti, dengan semacam pemesanan. Kasus penggunaan utama hari ini adalah memisahkan sistem dan memungkinkan pemrosesan asinkron pada jadwal atau kecepatan yang berbeda. RabbitMQ, NATS, Kafka, dll adalah contoh dari sistem pesan.

Perbandingan

Model Aktor dan kerangka kerja Akka adalah alat tingkat rendah yang merupakan cara terbaik untuk membangun aplikasi , seperti antrian pesan.

Bisakah Anda menggunakan Akka sebagai ganti antrian pesan? Tentu. Jika Anda membuat perangkat lunak yang sudah menggunakan model aktor maka Anda mungkin tidak perlu antrian pesan eksternal, terutama untuk mengirim pesan dalam utas atau aplikasi yang sama. Anda dapat menggunakan kemampuan Akka Remoting untuk bahkan mengirim pesan ke sistem aktor lain yang berjalan di mesin lain.

Namun, apakah ini membuat sistem pesan usang? Benar-benar tidak. Hanya karena Anda dapat mengkodekan semua hal ini sendiri bukan berarti Anda harus melakukannya, terutama ketika model aktor tidak baik untuk masalah Anda atau Anda memerlukan bahasa, aplikasi, API eksternal, sistem operasi, database, dll yang berbeda untuk berkomunikasi satu sama lain (apakah mereka sistem aktor atau tidak).

Jika Anda hanya perlu mengirimkan beberapa pesan di antara dua sistem, gunakan antrian pesan. Jika Anda memerlukan pemrosesan bersyarat negara dan pesan latensi rendah dalam aplikasi yang sama, maka gunakan model aktor. Keduanya ada pada level yang sangat berbeda dan bagaimana Anda menggunakannya tergantung pada solusi yang Anda buat.

Ada jawaban yang bagus pada SO tentang model aktor yang sama ini vs perpesanan: /programming/5693346/when-to-use-actors-instead-of-messaging-solutions-such-as-websphere-mq- atau-Tibco

Mani Gandham
sumber