REST atau AMQP dari Microservices, yang mana


15

Saya telah membaca banyak artikel tentang arsitektur microservices dan saya bertanya-tanya kapan harus menggunakan AMQP atau REST.

Saya pernah membaca bahwa lepasnya kopling antara layanan adalah hal yang baik dan AMQP tampaknya menjadi pilihan yang baik dalam hal ini. Tetapi jika kita menggunakan AMQP, ini berarti bahwa kita tidak membutuhkan titik akhir REST lagi (tetapi itu berarti bahwa kita kehilangan konsep HATEOAS).

Tetapi apakah REST benar-benar cara yang baik untuk membangun layanan saya? Karena saya tidak akan menggunakan titik akhir ... Dalam hal mana yang lebih baik dari yang lain?

Kapan saya harus menggunakan satu atau yang lain?

Jawaban:


10

Dengan membuang REST, Anda kehilangan lebih dari sekadar HATEOAS. Jika layanan Microsoft Anda bersifat publik (dan itu ide yang bagus bagi mereka untuk menjadi publik atau setidaknya cenderung menjadi publik suatu hari¹), menggunakan apa pun selain REST dan SOAP akan bermasalah:

  • Beberapa pengembang tidak pernah menggunakan AMQP,

  • Beberapa telah menggunakan AMQP, tetapi seringkali lebih akrab dengan REST dan SOAP,

  • Perpustakaan AMQP untuk beberapa bahasa tidak mudah,

  • Eksperimen manual dengan layanan ini sangat terbatas: Saya dapat menggunakan CURL untuk melakukan permintaan apa pun ke Amazon S3; apa yang harus saya instal pada mesin saya jika saya ingin bermain dengan varian AMQP S3?

  • Debestging REST dan SOAP itu mudah. Saya hanya melacak pertukaran HTTP dan menganalisisnya. Tidak yakin alat apa yang harus saya gunakan untuk melihat untuk men-debug pertukaran AMQP.

AMQP memang hebat, tetapi dilakukan untuk tujuan pertukaran yang sangat spesifik berdasarkan peristiwa. Meskipun secara teknis dimungkinkan untuk melakukan RPC dengan AMQP, itu bukan tujuan utamanya.

Aspek asinkron juga penting. Terkadang ini menguntungkan: Saya tidak ingin memblokir antarmuka pengguna aplikasi saat melakukan permintaan ke server. Kadang-kadang, itu hanya membuat segalanya lebih sulit daripada yang seharusnya: jika saya perlu memulihkan cadangan file dari Amazon S3 karena yang lokal rusak, dan kemudian mengembalikan cadangan, file batch saya perlu CURL untuk menyelesaikan tugasnya sebelum melanjutkan, dan operasi sinkron (dengan batas waktu tertentu) sangat masuk akal.

Simpan REST untuk operasi utama:

  • Mendapatkan produk,

  • Menyimpan faktur,

dan gunakan AMQP untuk tugas-tugas di mana perpesanan benar-benar masuk akal:

  • Memproses semua faktur dari bulan September dan memberi tahu aplikasi ketika laporan siap ditampilkan (mengingat bahwa operasi biasanya berlangsung dari dua hingga sepuluh menit),

    Manfaat AMQP di sini adalah aspek asinkronnya. Permintaan HTTP yang tertunda selama sepuluh menit memiliki peluang bagus untuk menyebabkan batas waktu dan masalah lainnya.

  • Mengirim informasi bahwa cadangan rusak kepada setiap orang yang mungkin tertarik, seperti orang-orang pendukung, administrator basis data, tim pemantauan, pengembang aplikasi yang menggunakan basis data ini, dll.

    Manfaat AMQP di sini adalah, antara lain, kemampuan untuk menambah pelanggan tanpa mengubah aplikasi yang melacak cadangan dan memicu peringatan ketika menemukan yang rusak.


¹ Layanan web publik tidak selalu digunakan oleh pengguna di luar perusahaan. Di perusahaan besar atau menengah, layanan Anda sering digunakan oleh divisi lain dari perusahaan yang sama dan memiliki persyaratan yang sama dengan yang akan digunakan oleh pihak ketiga: layanan ini seharusnya tidak mempercayai panggilan apa pun (fakta bahwa beberapa pria yang tidak pernah Anda kenal sebelumnya) mendengar siapa yang menyebut layanan Anda bekerja di perusahaan yang sama dengan Anda, bukan berarti dia tidak akan mengeksploitasi masalah keamanannya, itu harus didokumentasikan dengan baik (karena orang India yang sama tidak perlu mengetahui nomor telepon Anda dan tidak perlu tahu bahasa Inggris), dll.


Bagaimana dengan memuat objek bergantung menggunakan AMQP? Seperti halnya pengguna yang terkait dengan layanan penagihan (dalam arsitektur layanan mikro yang besar), apakah Anda ingin akses asynchronicity VS REST hateoas (synchroneous)?
Thomas thomas

5

Gunakan keduanya.

REST style JSON web services bagus untuk interoperablity dengan javascript, ios dll

AMQP sangat bagus untuk proses, acara dan orkestrasi berjalan lama dari layanan microser.

Tetapi keduanya hanya pembungkus komunikasi untuk layanan aktual, Anda dapat mengekspos layanan yang sama dalam berbagai cara dan mungkin harus.

AMPQ dapat bekerja dengan baik di Websockets, yang dapat terlihat seperti titik akhir REST jika Anda menyipitnya.


1
"Jika kamu menyipit" lol, itu hebat.
Iain Duncan

0

REST adalah teknologi standar yang sangat cocok untuk interoperabilitas antar komponen - ini adalah bagian kuncinya, sangat bagus untuk membuat layanan web yang dapat dikonsumsi orang lain. Namun, itu menderita masalah yang biasa seperti interoperabilitas dalam hal itu kurang efisien daripada protokol khusus.

Jika Anda menulis arsitektur back-end di mana layanan hanya dikonsumsi oleh Anda sendiri, maka Anda dapat menggunakan protokol apa pun yang Anda suka - Anda tidak lagi dibatasi dengan menggunakan satu yang sangat interoperable. Anda dapat menggunakan MQ atau sesuatu yang lebih rapat dan performan. Yang mana yang Anda gunakan tergantung pada kasus penggunaan Anda, bus pesan sangat baik untuk set layanan terdistribusi yang memproses data di mana klien tidak peduli siapa yang mendapatkan pesan yang dikirimnya.


2
Saya tidak setuju, sejauh yang saya ketahui mereka memiliki tujuan yang berbeda; Anda (umumnya) tidak boleh mengekspos AMQP melalui internet publik; ia memiliki fasilitas auth jauh lebih sedikit untuk satu hal, dan biasanya pengguna internet publik menginginkan tanggapan dari kegiatan mereka. REST cocok untuk penggunaan internet publik karena alasan ini. Perbedaan terbesarnya adalah bahwa AMQP bersifat asinkron ( perilaku seperti sinkron dimungkinkan, tetapi bukan untuk MQ), dan REST adalah sinkron (ya kembali 202adalah mendikte asinkron, tetapi mengapa Anda menggunakan REST saat itu? Mungkin karena itu publik.)
Jimmy Hoffa

Sebagai tambahan, mengekspos AMQP untuk penggunaan websocket sehingga pengguna mendapatkan dorongan langsung waktu nyata daripada harus polling sebenarnya adalah alasan untuk melakukan AMQP publik; tetapi sekali lagi: Lintas tujuan, Anda tidak melakukan REST sehingga konsumen bisa mendapatkan dorongan, ini adalah skenario lain di mana Anda menggunakan AMQP untuk sesuatu yang REST tidak bisa lakukan.
Jimmy Hoffa

@JimmyHoffa saya pikir dia bertanya apa yang harus digunakan untuk menghubungkan server web atau kliennya atau apa pun ke layanan mikrosenya di LAN internal, bukan melalui web - maka pendapat saya bahwa REST baik untuk itu, tetapi jika semua yang Anda gunakan ada di bawah Anda kontrol, Anda dapat menggunakan apa pun yang Anda suka.
gbjbaanb

Ya, itu masuk akal; Saya membaca pertanyaannya secara berbeda: Sepertinya dia membaca tentang gagasan layanan mikro, dan tidak mengerti alasan yang relevan untuk memilih AMQP vs REST. Secara internal Anda dapat menggunakan apa pun yang Anda inginkan, tetapi masih ada alasan khusus untuk menggunakan AMQP vs REST bahkan secara internal; layanan yang ingin sinkronisasi tidak menggunakan AMQP secara internal, layanan yang sinkron (pikirkan layanan pemrosesan murni: Data Mentah di -> Data yang diproses keluar) harus REST. Ada kelebihan dan kekurangan yang berbeda untuk kedua teknologi IPC, Anda tahu mereka dan harus mencantumkannya dalam jawaban Anda! :)
Jimmy Hoffa

0

AMQP juga mendukung komunikasi point-to-point (misalnya, lihat python-qpid-protontutorial). Anda dapat mengimplementasikan antarmuka RESTful menggunakan itu, karena REST !=HTTP.

AMQP juga berkinerja jauh lebih baik daripada HTTP.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.