Pola Jembatan Olah Pesan

Azure Service Bus

Hubungkan sistem perpesanan yang dibangun di atas infrastruktur perpesanan yang berbeda dan teruskan pesan di antara sistem tersebut. Pendekatan ini memungkinkan Anda mengintegrasikan sistem yang berbeda tanpa memodifikasi sistem itu sendiri.

Konteks dan masalah

Banyak organisasi dan beban kerja secara tidak sengaja dapat memiliki sistem TI yang menggunakan beberapa infrastruktur olahpesan seperti Microsoft Message Queueing (MSMQ), RabbitMQ, Azure Bus Layanan, dan Amazon SQS. Masalah ini dapat terjadi karena merger, akuisisi, atau karena perluasan sistem lokal saat ini ke komponen yang dihosting cloud untuk efektivitas biaya dan kemudahan pemeliharaan.

Pengembang mungkin mengatasi tantangan ini dengan memodifikasi sistem yang diintegrasikan untuk berkomunikasi dengan menggunakan layanan web berbasis HTTP. Namun, pendekatan ini memiliki kelemahan, termasuk:

  • Sistem harus dimodifikasi dengan menambahkan klien HTTP di satu sisi dan handler permintaan HTTP di sisi lain. Sistem kemudian harus diuji ulang dan disebarkan ulang.
  • Titik akhir HTTP harus dihosting, yang menambah kompleksitas ketika menyediakan layanan web yang aman dan memiliki ketersediaan tinggi.
  • Masalah konektivitas jaringan yang sering terjadi yang memerlukan mekanisme coba lagi yang dibuat khusus.

Solusi

Jika sistem yang diintegrasikan terdiri dari komponen yang berkomunikasi dengan bertukar pesan, pola Messaging Bridge meningkatkan integrasi dan mengurangi kelemahan.

Dalam skenario ini, setiap sistem terhubung ke satu infrastruktur olahpesan. Untuk mengintegrasikan berbagai infrastruktur olahpesan, perkenalkan komponen penghubung yang terhubung ke dua atau beberapa infrastruktur olahpesan secara bersamaan. Jembatan menarik pesan dari satu dan mendorongnya ke yang lain tanpa mengubah payload.

Sistem yang diintegrasikan tidak perlu mengenali yang lain atau jembatan. Sistem pengirim dikonfigurasi untuk mengirim pesan tertentu ke antrean yang ditunjuk pada infrastruktur olahpesan aslinya. Jembatan mengambil pesan tersebut dan meneruskannya ke antrean lain dalam infrastruktur pesan yang berbeda di mana sistem penerima pesan mengambilnya.

Keuntungan

  • Sistem yang diintegrasikan melalui Messaging Bridge tidak perlu dimodifikasi. Idealnya, endpoint tidak menyadari bahwa pesan digabungkan.
  • Integrasi lebih dapat diandalkan dibandingkan dengan alternatif HTTP karena jaminan mekanisme pengiriman pesan setidaknya sekali.
  • Skenario migrasi bisa lebih fleksibel. Misalnya, titik akhir dapat dimigrasikan dari satu infrastruktur olahpesan ke yang lain sesuai dengan jadwal alih-alih semua sekaligus.

Kekurangan

  • Fitur tingkat lanjut dari satu atau kedua teknologi olahpesan mungkin tidak tersedia pada rute yang disambungkan.
  • Rute yang dijembatani perlu mempertimbangkan keterbatasan kedua teknologi. Misalnya, ukuran pesan maksimum mungkin 4 MB di MSMQ tetapi hanya 64 KB dalam antrean Azure Storage.

Masalah dan pertimbangan

Pertimbangkan poin-poin berikut saat menerapkan pola Jembatan Olahpesan:

  • Jika salah satu sistem terintegrasi bergantung pada transaksi terdistribusi, misalnya Koordinator Transaksi Terdistribusi Microsoft (DTC), untuk kebenaran, Anda harus menerapkan mekanisme deduplikasi di jembatan.

  • Jika salah satu sistem yang diintegrasikan tidak menggunakan infrastruktur olahpesan apa pun dan tidak dapat dimodifikasi, Anda dapat membangun Jembatan Olahpesan antara infrastruktur yang digunakan oleh sistem lain dan antrean yang diemulasikan SQL Server. Sistem warisan dapat mengirim pesan dengan menggunakan fitur pengambilan data perubahan untuk SQL Server guna mendorong perubahannya ke tabel antrean khusus. Jembatan dapat meneruskan pesan ini ke infrastruktur olahpesan yang sebenarnya.

  • Anda dapat menggunakan satu antrean di setiap infrastruktur olahpesan, yang ditetapkan sebagai antrean bridging. Dalam topologi ini, konfigurasikan sistem pengirim untuk menggunakan antrean tertentu sebagai tujuan untuk jenis pesan yang dikirim ke sistem lain. Anda juga dapat menggunakan beberapa pasang antrean di setiap infrastruktur olahpesan, sehingga pengirim tidak menyadari jembatan. Antrean bayangan dibuat untuk setiap antrean tujuan dalam infrastruktur pesan sistem tujuan. Jembatan meneruskan pesan antara antrean bayangan dan rekan-rekan mereka.

  • Untuk memenuhi tujuan tingkat layanan ketersediaan (SLO) yang diinginkan, Anda mungkin perlu meluaskan skala Messaging Bridge dengan menggunakan pendekatan Konsumen yang bersaing .

  • Komponen pemrosesan pesan reguler menggunakan pola Coba Lagi untuk menangani kegagalan sementara. Batas penghitung coba lagi memungkinkan komponen mendeteksi pesan racun dan menghapusnya dari antrean untuk memperlancar pemrosesan. Jembatan mungkin memerlukan kebijakan coba lagi yang berbeda untuk mencegah kesalahan mengidentifikasi pesan sebagai racun jika terjadi kegagalan infrastruktur. Anda bisa menggunakan pola Circuit Breaker untuk menjeda penerusan.

Kapan menggunakan pola ini

Gunakan pola Jembatan Pesan ketika Anda perlu:

  • Integrasikan sistem yang ada dengan kebutuhan minimal untuk modifikasi.
  • Integrasikan aplikasi warisan yang tidak dapat menggunakan teknologi olahpesan lainnya.
  • Perluas aplikasi lokal yang ada dengan komponen yang dihosting cloud.
  • Hubungkan sistem terdistribusi geografis saat koneksi internet tidak stabil.
  • Migrasikan sistem terdistribusi tunggal dari satu infrastruktur olahpesan ke infrastruktur olahpesan lain secara bertahap tanpa perlu memigrasikan seluruh sistem dalam satu upaya.

Pola ini mungkin tidak cocok jika:

  • Setidaknya salah satu sistem yang terlibat bergantung pada fitur dari satu infrastruktur olahpesan yang tidak ada di yang lain.
  • Integrasi bersifat sinkron, dan sistem yang memulai memerlukan respons segera.
  • Integrasi memiliki persyaratan fungsional atau nonfungsi tertentu, seperti masalah keamanan atau privasi.
  • Volume data yang diperlukan untuk integrasi melebihi kapasitas sistem olahpesan atau menyebabkan olahpesan menjadi solusi yang mahal untuk masalah tersebut.

Desain beban kerja

Arsitek harus mengevaluasi bagaimana pola Messaging Bridge dapat digunakan dalam desain beban kerja mereka untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar-pilar Azure Well-Architected Framework. Contohnya:

Pilar Bagaimana pola ini mendukung tujuan pilar
Optimasi Biaya berfokus pada mempertahankan dan meningkatkanpengembalian investasi beban kerja Anda. Langkah perantara ini dapat meningkatkan umur panjang sistem Anda yang ada tanpa perlu menulis ulang dengan memungkinkan interoperabilitas dengan sistem yang menggunakan teknologi olahpesan atau peristiwa yang berbeda.

- Biaya komponen CO:07
Keunggulan Operasional membantu memberikan kualitas beban kerja melalui proses standar dan kohesi tim. Pemisahan ini memberikan fleksibilitas ketika Anda mentransisikan teknologi pesan dan pemrosesan peristiwa dalam beban kerja Anda atau ketika Anda memiliki persyaratan yang heterogen dari ketergantungan eksternal.

- OE:06 Menyebarkan perubahan beban kerja

Seperti halnya keputusan desain apa pun, pertimbangkan pengorbanan terhadap tujuan pilar lain yang dapat diperkenalkan oleh pola ini.

Contoh

Ada aplikasi .NET Framework untuk mengelola penjadwalan karyawan yang dihosting secara lokal. Aplikasi ini terstruktur dengan baik dengan komponen terpisah yang berkomunikasi melalui MSMQ. Aplikasi ini berfungsi, dan tim beban kerja tidak memiliki niat untuk menulis ulang aplikasi tersebut. Konsumen baru data penjadwalan perlu dibangun untuk memenuhi kebutuhan bisnis, dan strategi TI menyerukan untuk membangun perangkat lunak baru sebagai aplikasi cloud-native guna mengoptimalkan biaya dan waktu pengiriman.

Arsitektur berbasis antrean asinkron telah berhasil digunakan oleh tim penangan beban kerja di masa lalu, jadi tim akan menggunakan pendekatan arsitektur yang sama tetapi dengan teknologi yang lebih baru, Bus Layanan. Tim beban kerja tidak ingin memperkenalkan komunikasi sinkron antara cloud dan penyebaran di tempat untuk mengurangi latensi atau ketidaktersediaan yang dapat memengaruhi satu sama lain.

Tim memutuskan untuk menggunakan pola Jembatan Pesan untuk menghubungkan kedua sistem. Pola terdiri dari dua bagian. Satu bagian menerima pesan dari antrean MSMQ yang ada dan meneruskannya ke Bus Layanan. Bagian lain mengambil pesan dari Bus Layanan dan meneruskannya ke antrean MSMQ yang ada.

Diagram Messaging Bridge yang mengintegrasikan MSMQ dan Bus Layanan.

Ketika tim implementasi menggunakan pendekatan ini, mereka menggunakan infrastruktur yang ada di aplikasi yang ada untuk berintegrasi dengan komponen baru. Aplikasi yang ada tidak menyadari bahwa komponen baru dihosting di Azure. Demikian pula, komponen baru berkomunikasi dengan aplikasi warisan dengan cara yang sama seperti mereka berkomunikasi antara mereka sendiri, dengan mengirim pesan Bus Layanan. Jembatan meneruskan pesan antara kedua sistem.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

  • Deskripsi pola Messaging Bridge dari komunitas pola integrasi perusahaan.
  • Pelajari cara menerapkan Messaging Bridge dalam kerangka kerja Spring Java.
  • Jembatan QPid dapat digunakan untuk menghubungkan teknologi olahpesan yang mendukung AMQP.
  • NServiceBus Messaging Bridge adalah implementasi .NET dari jembatan antar-antrean yang mendukung berbagai infrastruktur pesan termasuk MSMQ, Bus Layanan, dan Azure Queue Storage.
  • NServiceBus.Router adalah proyek sumber terbuka yang mengimplementasikan pola Jembatan Olahpesan. Ini juga memungkinkan menghubungkan lebih dari dua teknologi dalam satu instans dan memiliki kemampuan perutean pesan tingkat lanjut.
  • Pola Competing Consumers memastikan implementasi Messaging Bridge dapat menangani beban.
  • Pola Pengulangan memungkinkan Messaging Bridge menangani kegagalan sementara.
  • Pola Circuit Breaker menghemat sumber daya ketika salah satu sisi jembatan mengalami waktu henti.