Apa itu perantara pesan?

Broker pesan adalah modul perangkat lunak dalam solusi middleware perpesanan atau middleware berorientasi pesan (MOM). Jenis middleware ini memberi pengembang sarana standar untuk menangani aliran data antara komponen aplikasi sehingga mereka dapat fokus pada logika intinya. Modul ini dapat berfungsi sebagai lapisan komunikasi terdistribusi yang memungkinkan aplikasi yang mencakup berbagai platform untuk berkomunikasi secara internal.

Broker pesan dapat memvalidasi, menyimpan, merutekan, dan mengirimkan pesan ke tujuan yang sesuai. Aplikasi ini berfungsi sebagai perantara antara aplikasi lain, memungkinkan pengirim untuk mengirim pesan tanpa mengetahui di mana penerima berada, apakah mereka aktif atau tidak, atau berapa banyak jumlahnya. Broker pesan memfasilitasi pemisahan proses dan layanan dalam sistem.

Untuk menyediakan penyimpanan pesan yang andal dan pengiriman yang terjamin, broker pesan sering mengandalkan substruktur atau komponen yang disebut antrean pesan yang menyimpan dan meminta pesan sampai aplikasi yang dikonsumsi dapat memprosesnya. Dalam antrean pesan, pesan disimpan dalam urutan yang sama persis dengan urutan pengirimannya dan tetap berada dalam antrean sampai penerimaan dikonfirmasi.

Pengiriman pesan asinkron mengacu pada jenis komunikasi antar-aplikasi yang dimungkinkan oleh broker pesan. Solusi ini mencegah hilangnya data berharga dan memungkinkan sistem untuk terus berfungsi bahkan dalam menghadapi masalah konektivitas intermiten atau latensi yang umum di jaringan publik. Pengiriman pesan asinkron menjamin bahwa pesan akan dikirimkan sekali (dan hanya sekali) dalam urutan yang benar dibandingkan dengan pesan-pesan lainnya.

Broker pesan dapat terdiri dari manajer antrean untuk menangani interaksi antara beberapa antrean pesan, serta layanan yang menyediakan perutean data, penerjemahan pesan, persistensi, dan fungsi manajemen status klien.

Broker pesan menawarkan dua pola distribusi pesan dasar atau gaya pesan:

Pengiriman pesan dari titik ke titik: Ini adalah pola distribusi yang digunakan dalam antrean pesan dengan hubungan satu-ke-satu antara pengirim dan penerima pesan. Setiap pesan dalam antrean dikirim ke hanya satu penerima dan dikonsumsi hanya sekali. Pesan dari titik ke titik dipanggil ketika pesan harus ditindaklanjuti hanya satu kali. Contoh penggunaan yang sesuai untuk gaya pesan ini termasuk penggajian dan pemrosesan transaksi keuangan. Dalam sistem ini, baik pengirim maupun penerima membutuhkan jaminan bahwa setiap pembayaran akan dikirim sekali dan hanya sekali.

Pesan publikasi/berlangganan: Dalam pola distribusi pesan ini, yang sering disebut sebagai “pub/sub,” produsen setiap pesan menerbitkannya ke sebuah topik, dan beberapa konsumen pesan berlangganan ke topik-topik yang ingin mereka terima pesannya. Semua pesan yang dipublikasikan ke suatu topik didistribusikan ke semua aplikasi yang berlangganan topik tersebut. Ini adalah metode distribusi gaya broadcast, di mana ada hubungan satu-ke-banyak antara penerbit pesan dan konsumennya. Jika, misalnya, sebuah maskapai penerbangan menyebarkan informasi terbaru tentang waktu pendaratan atau status penundaan penerbangannya, beberapa pihak dapat memanfaatkan informasi tersebut: kru darat yang melakukan pemeliharaan dan pengisian bahan bakar pesawat, petugas bagasi, pramugari dan pilot yang mempersiapkan perjalanan pesawat berikutnya, dan operator tampilan visual yang memberi tahu publik. Gaya pesan pub/sub akan sesuai untuk digunakan dalam skenario ini.

Aplikasi cloud-native dibuat untuk memanfaatkan keunggulan yang melekat pada komputasi awan, termasuk fleksibilitas, skalabilitas, dan penerapan yang cepat. Aplikasi ini terdiri atas komponen kecil, diskret, dan dapat digunakan kembali yang disebut layanan mikro. Setiap layanan mikro diterapkan dan dapat berjalan secara independen dari yang lain. Ini berarti bahwa salah satu dari layanan tersebut dapat diperbarui, diskalakan, atau dimulai ulang tanpa mempengaruhi layanan lain dalam sistem. Seringkali dikemas dalam kontainer, layanan mikro bekerja bersama untuk membentuk seluruh aplikasi, meskipun masing-masing memiliki tumpukannya sendiri, termasuk basis data dan model data yang mungkin berbeda dari yang lain.

Layanan mikro harus memiliki sarana untuk berkomunikasi satu sama lain agar dapat beroperasi secara bersamaan. Broker pesan adalah salah satu mekanisme yang digunakan untuk membuat tulang punggung komunikasi bersama ini.

Broker pesan sering digunakan untuk mengelola komunikasi antara sistem lokal dan komponen cloud di lingkungan hybrid cloud. Menggunakan broker pesan memberikan peningkatan kontrol atas komunikasi antar-layanan, memastikan bahwa data dikirim dengan aman, andal, dan efisien di antara komponen-komponen aplikasi. Broker pesan dapat memainkan peran serupa dalam mengintegrasikan lingkungan multicloud, memungkinkan komunikasi antara beban kerja dan waktu proses yang berada pada platform berbeda. Broker pesan juga cocok untuk digunakan dalam komputasi tanpa server, di mana layanan individual yang dihosting di cloud berjalan sesuai permintaan berdasarkan tiap-tiap permintaan.

REST API biasanya digunakan untuk komunikasi antara layanan mikro. Istilah Representational State Transfer (REST) mendefinisikan seperangkat prinsip dan batasan yang dapat diikuti oleh para pengembang ketika membangun layanan web. Setiap layanan yang mematuhi prinsip dan batasan ini akan dapat berkomunikasi melalui seperangkat operator dan permintaan tanpa status yang seragam. Antarmuka Pemrograman Aplikasi (API) merujuk pada kode yang mendasari, yang jika memenuhi aturan REST, memungkinkan layanan untuk berbicara satu sama lain.

REST API menggunakan Hypertext Transfer Protocol (HTTP) untuk berkomunikasi. Karena HTTP adalah protokol transport standar Internet publik, REST API dikenal luas, sering digunakan, dan dapat dioperasikan secara luas. HTTP adalah protokol permintaan/respons, jadi sebaiknya digunakan dalam situasi yang membutuhkan permintaan/respons yang sinkron. Ini berarti bahwa layanan yang membuat permintaan melalui REST API harus dirancang untuk mengharapkan respons segera. Jika klien yang menerima respons sedang tumbang, layanan pengiriman akan diblokir saat menunggu balasan. Logika failover dan penanganan kesalahan harus dibangun ke dalam kedua layanan.

Broker pesan memungkinkan komunikasi asinkron antara layanan sehingga layanan pengirim tidak perlu menunggu balasan dari layanan penerima. Hal ini meningkatkan toleransi kesalahan dan ketahanan pada sistem tempat mereka digunakan. Selain itu, penggunaan broker pesan memudahkan penskalaan sistem karena pola pesan pub/sub dapat dengan mudah mendukung perubahan jumlah layanan. Broker pesan juga melacak status konsumen.

Sementara broker pesan dapat mendukung dua atau lebih pola pengiriman pesan, termasuk antrean pesan dan pub/sub, platform streaming peristiwa hanya menawarkan pola distribusi bergaya pub/sub. Dirancang untuk digunakan dengan volume pesan yang tinggi, platform streaming peristiwa mudah diskalakan. Platform ini mampu mengurutkan aliran rekaman ke dalam kategori dan menyimpannya selama jangka waktu tertentu yang telah ditentukan. Namun, tidak seperti broker pesan, platform streaming peristiwa tidak dapat menjamin pengiriman pesan atau melacak konsumen mana yang telah menerima pesan.

Platform streaming peristiwa menawarkan skalabilitas yang lebih besar daripada broker pesan tetapi lebih sedikit fitur yang memastikan toleransi kesalahan (seperti pengiriman ulang pesan), serta kemampuan perutean dan antrean pesan yang lebih terbatas.

Pelajari lebih lanjut tentang  arsitektur yang digerakkan oleh peristiwa.

Enterprise service bus (ESB) adalah pola arsitektur yang terkadang digunakan dalam arsitektur berorientasi layanan (SOA) yang diimplementasikan di seluruh perusahaan. Dalam ESB, platform perangkat lunak terpusat menggabungkan protokol komunikasi dan format data ke dalam “bahasa umum” yang dapat digunakan bersama oleh semua layanan dan aplikasi dalam arsitektur. Platform ini mungkin, misalnya, menerjemahkan permintaan yang diterima dari satu protokol (seperti XML) ke protokol lain (seperti JSON). ESB mengubah payload pesan menggunakan proses otomatis. Platform perangkat lunak terpusat juga menangani logika orkestrasi lainnya, seperti konektivitas, perutean, dan pemrosesan permintaan.

Namun, infrastruktur ESB sangat kompleks, dan bisa jadi sulit untuk diintegrasikan serta mahal untuk dipelihara. Sulit untuk memecahkan masalah ketika terjadi masalah di lingkungan produksi, infrastruktur ini tidak mudah untuk diskalakan, dan pembaruannya melelahkan.

Broker pesan adalah alternatif "ringan" untuk ESB yang menyediakan fungsi yang sama—sebuah mekanisme untuk komunikasi antar-layanan—dengan lebih sederhana dan dengan biaya yang lebih rendah. Broker pesan sangat cocok untuk digunakan dalam arsitektur layanan mikro yang telah menjadi lebih umum karena ESB tidak lagi disukai.

Menerapkan broker pesan dapat memenuhi berbagai macam kebutuhan bisnis di seluruh industri dan dalam lingkungan komputasi perusahaan yang beragam. Broker pesan berguna kapan pun dan di mana pun komunikasi antar-aplikasi yang andal dan pengiriman pesan yang terjamin diperlukan.

Broker pesan sering kali digunakan dengan cara-cara berikut:

• Transaksi keuangan dan pemrosesan pembayaran: Sangat penting untuk memastikan bahwa pembayaran dikirim sekali dan hanya sekali. Menggunakan broker pesan untuk menangani data transaksi ini menawarkan jaminan bahwa informasi pembayaran tidak akan hilang atau digandakan secara tidak sengaja, memberikan bukti penerimaan, dan memungkinkan sistem untuk berkomunikasi dengan andal bahkan ketika jaringan perantara mati.
  
  
• Pemrosesan dan pemenuhan pesanan e-commerce: Jika Anda menjalankan bisnis online, kekuatan reputasi merek Anda bergantung pada keandalan situs web dan platform e-commerce Anda. Kemampuan broker pesan untuk meningkatkan toleransi kesalahan dan menjamin bahwa pesan hanya dikonsumsi sekali dan sekali saja membuat mereka menjadi pilihan alami untuk digunakan saat memproses pesanan online.
  
  
• Melindungi data yang sangat sensitif saat istirahat dan dalam perjalanan: Jika industri Anda sangat diatur atau bisnis Anda menghadapi risiko keamanan yang signifikan, pilihlah solusi perpesanan dengan kemampuan enkripsi end-to-end.