Pesan Antrian vs. Layanan Web? [Tutup]

258

Dalam kondisi apa seseorang akan menyukai aplikasi yang berbicara melalui antrian pesan alih-alih melalui layanan web (maksud saya XML atau JSON atau YAML atau apa pun melalui HTTP di sini, bukan jenis tertentu)?

Saya harus berbicara antara dua aplikasi di jaringan lokal. Satu akan menjadi aplikasi web dan harus meminta perintah pada aplikasi lain (berjalan pada perangkat keras yang berbeda). Permintaan adalah hal-hal seperti membuat pengguna, memindahkan file, dan membuat direktori. Dalam kondisi apa saya lebih suka Layanan Web XML (atau TCP lurus atau sesuatu) daripada menggunakan antrian Pesan?

Aplikasi web adalah Ruby on Rails, tapi saya pikir pertanyaannya lebih luas dari itu.

web-services message-queue

— Dan Rosenstark
sumber

315

Saat Anda menggunakan layanan web, Anda memiliki klien dan server:

Jika server gagal, klien harus bertanggung jawab untuk menangani kesalahan.
Ketika server bekerja kembali, klien bertanggung jawab untuk mengirimnya kembali.
Jika server memberikan respons terhadap panggilan dan klien gagal operasi hilang.
Anda tidak memiliki pendapat, yaitu: jika jutaan klien memanggil layanan web pada satu server dalam satu detik, kemungkinan besar server Anda akan turun.
Anda dapat mengharapkan respons langsung dari server, tetapi Anda juga dapat menangani panggilan tidak sinkron.

Saat Anda menggunakan antrian pesan seperti RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo Anda mengharapkan hasil yang berbeda dan lebih toleran terhadap kesalahan:

Jika server gagal, antrian tetap ada pesan (opsional, bahkan jika mesin dimatikan).
Ketika server bekerja kembali, ia menerima pesan yang tertunda.
Jika server memberikan respons terhadap panggilan dan klien gagal, jika klien tidak mengakui respons pesan tetap ada.
Anda memiliki pendapat, Anda dapat memutuskan berapa banyak permintaan yang ditangani oleh server (sebut saja pekerja itu).
Anda tidak mengharapkan respons sinkron langsung, tetapi Anda dapat menerapkan / mensimulasikan panggilan sinkron.

Antrian Pesan memiliki lebih banyak fitur, tetapi ini adalah aturan praktis untuk memutuskan apakah Anda ingin menangani sendiri kondisi kesalahan atau membiarkannya pada antrian pesan.

— sw.
sumber

1

Jika SOAP / JMS mengikat digunakan, satu juga mendapatkan kopling longgar di layanan web.

— koppor

Untuk beberapa layanan mikro di sisi server yang mana yang harus lebih disukai layanan Web atau Antrian?

— shivendra pratap singh

@Sw. , bolehkah saya tahu jika itu berarti kami dapat menempatkan MQ di depan situs web normal? Katakanlah saya memiliki Website Wordpress (LAMP stack). Bisakah saya menggunakan MQ infront dari Apache sehingga permintaan datang 1 setelah 1, bukannya semua datang pada waktu yang sama. Dalam hal ini, Klien (Peramban) terhubung ke MQ, bukan Apache, benarkan? Namun, apakah Browser menjaga koneksi HTTP tetap terbuka dan terus menunggu Apache untuk merespons? Tolong bantu saya mengerti sedikit tentang ini. Hargai kebaikan Anda.

— 夏期劇場

@ 夏期劇場 apa kasus penggunaan Anda? Apa yang ingin Anda capai yang bermanfaat bagi pengguna akhir menggunakan browser?

— sw.

Bukankah masalah ini dengan pengaturan klien / server masih menyangkut antara antrian dan server dan antara klien dan antrian? Sepertinya paradigma klien / server masih ada dan sekarang ada di dua tempat.

— ImagerThat

75

Sudah ada cukup banyak penelitian terbaru dalam mempertimbangkan bagaimana REST panggilan HTTP dapat menggantikan konsep antrian pesan.

Jika Anda memperkenalkan konsep proses dan tugas sebagai sumber daya, kebutuhan untuk lapisan olahpesan menengah mulai menguap.

Ex:

POST /task/name
    - Returns a 202 accepted status immediately
    - Returns a resource url for the created task: /task/name/X
    - Returns a resource url for the started process: /process/Y

GET /process/Y
    - Returns status of ongoing process

Suatu tugas dapat memiliki beberapa langkah untuk inisialisasi, dan suatu proses dapat mengembalikan status ketika disurvei atau POST ke URL panggilan balik saat selesai.

Ini sangat sederhana, dan menjadi sangat kuat ketika Anda menyadari bahwa Anda sekarang dapat berlangganan feed rss / atom dari semua proses dan tugas yang sedang berjalan tanpa lapisan tengah. Sistem antrian apa pun akan memerlukan semacam web front end, dan konsep ini telah membuatnya tanpa lapisan kode kustom lain.

Sumber daya Anda ada sampai Anda menghapusnya, yang berarti Anda dapat melihat informasi historis lama setelah proses dan tugas selesai.

Anda telah membangun dalam penemuan layanan, bahkan untuk tugas yang memiliki beberapa langkah, tanpa protokol yang rumit.

GET /task/name
    - returns form with required fields

POST (URL provided form's "action" attribute)

Penemuan layanan Anda adalah bentuk HTML - format universal dan dapat dibaca manusia.

Seluruh aliran dapat digunakan secara terprogram atau oleh manusia, menggunakan alat yang diterima secara universal. Ini didorong oleh klien, dan karenanya tenang. Setiap alat yang dibuat untuk web dapat mendorong proses bisnis Anda. Anda masih memiliki saluran pesan alternatif dengan POST secara asinkron ke larik server log yang terpisah.

Setelah Anda mempertimbangkannya sebentar, Anda duduk dan mulai menyadari bahwa REST mungkin hanya menghilangkan kebutuhan untuk antrian pengiriman pesan dan ESB sama sekali.

http://www.infoq.com/presentations/BPM-with-REST

— tempire
sumber

11

@tempire bagaimana dengan toleransi kesalahan dan sebagainya? REST bagus, tetapi pengembang akhirnya membangun sendiri middleware

— Dan Rosenstark

10

@Yar Sebagian besar pertanyaan tentang 'bagaimana dengan ini' dapat dinyatakan kembali, 'bagaimana penanganannya di web?'. Toleransi kesalahan dapat ditangani melalui load balancers, atau bahkan manipulasi catatan dns. Ada beberapa masalah lagi yang perlu diatasi, seperti skalabilitas horizontal - web secara inheren tidak menangani hal itu dengan baik (misalnya serangan DDoS)

— tempire

8

@tempire, tidak ada pengiriman yang dijamin di Web, bukan? Saya menekan kirim dan berdoa agar pesan sampai ke tujuannya. Dengan MQ, saya tahu bahwa jika saya sampai ke MQ saya selesai. Ini akan menangani pengiriman pesan ke tujuan.

— Dan Rosenstark

10

@Yar mempertimbangkan apa artinya 'pengiriman terjamin'. Ini hanya 'dijamin' seperti waktu antrian pesan. Ganti antrian pesan dengan server REST yang memperlakukan tugas dan proses sebagai sumber daya, dan Anda mendapatkan 'jaminan' yang sama dengan yang lainnya. Pada dasarnya, Anda masih memiliki antrian pesan, tetapi dalam format yang dapat diakses standar web, yang dapat dipantau menggunakan alat web apa pun.

— tempire

16

@ Yar - Saya tidak berpikir banyak orang memahami definisi masalah yang MQ coba selesaikan dengan cukup untuk mempertimbangkan hal-hal seperti itu. Mereka memahami MQ, tetapi itu berbeda dari memahami ruang masalah. Ini adalah masalah yang tersebar luas, karena saya pikir sebagian besar programmer & manajer di dunia telah dilatih untuk menghubungkan potongan-potongan alih-alih solusi insinyur.

— Tempire

32

Antrian pesan sangat ideal untuk permintaan yang mungkin membutuhkan waktu lama untuk diproses. Permintaan diantrekan dan dapat diproses secara offline tanpa memblokir klien. Jika klien perlu diberitahu tentang penyelesaian, Anda dapat memberikan cara bagi klien untuk secara berkala memeriksa status permintaan.

Antrian pesan juga memungkinkan Anda untuk meningkatkan skala waktu. Ini meningkatkan kemampuan Anda untuk menangani semburan aktivitas berat, karena pemrosesan yang sebenarnya dapat didistribusikan sepanjang waktu.

Perhatikan bahwa antrian pesan dan layanan web adalah konsep ortogonal, yaitu mereka tidak saling eksklusif. Misalnya Anda dapat memiliki layanan web berbasis XML yang bertindak sebagai antarmuka ke antrian pesan. Saya pikir perbedaan yang Anda cari adalah Antrian Pesan versus Permintaan / Tanggapan, yang terakhir adalah ketika permintaan diproses secara serempak.

— DSO
sumber

3

Ya, saya hanya memikirkan ini: ini bukan apakah mereka memblokir atau tidak memblokir. Itu apakah mereka memerlukan waktu lebih lama dan / atau tidak dapat diprediksi untuk memproses ... Mengenai mereka yang ortogonal, juga benar bahwa layanan web dapat digunakan untuk permintaan lama (tentu saja dropoff dan pickup terpisah). Namun jika Anda memiliki antrian pesan yang mewah, itu bisa menjadi ide yang bagus.

— Dan Rosenstark

Pertanyaan baru saya adalah, bagaimana jika ingin proses menjadi sinkron, tetapi tidak sinkron pada batas waktu? Maka mungkin layanan web akan lebih cocok.

— Dan Rosenstark

27

Antrian pesan asinkron dan dapat mencoba beberapa kali jika pengiriman gagal. Gunakan antrian pesan jika pemohon tidak perlu menunggu jawaban.

Ungkapan "layanan web" membuat saya berpikir tentang panggilan sinkron ke komponen yang didistribusikan melalui HTTP. Gunakan layanan web jika pemohon membutuhkan respons kembali.

— Duffymo
sumber

1

Terima kasih untuk itu, ya "pengiriman terjamin," saya harus memikirkan apakah itu penting. Maksud saya, sinkronisasi vs async adalah semacam rasa, dalam arti tertentu. Meskipun ada kasus yang jelas hitam dan putih, ada juga tengah abu-abu besar.

— Dan Rosenstark

22

Saya pikir secara umum, Anda menginginkan layanan web untuk tugas pemblokiran (tugas ini harus diselesaikan sebelum kami mengeksekusi lebih banyak kode), dan antrian pesan untuk tugas yang tidak menghalangi (bisa memakan waktu cukup lama, tapi kami tidak tidak perlu menunggu untuk itu).

— Tobias Cohen
sumber

Layanan web juga menawarkan metode satu arah ( @Oneway ). Untuk menerima jawabannya, layanan web harus ditawarkan oleh klien.

— koppor