Artikel ini menjelaskan pola Jembatan Olahpesan, yang merupakan teknik yang dapat Anda gunakan untuk mengintegrasikan sistem berbeda yang dibangun di atas berbagai infrastruktur olahpesan.
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 Anda membuat layanan web aman dan sangat tersedia.
- 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 olahpesan yang berbeda di mana sistem penerima mengambilnya.
Keuntungan
- Sistem yang diintegrasikan melalui Messaging Bridge tidak perlu dimodifikasi. Idealnya, titik akhir tidak menyadari bahwa pesan di-bridge.
- 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 infrastruktur olahpesan lainnya karena jadwal mengizinkan alih-alih semua sekaligus.
Kekurangan
- Fitur tingkat lanjut dari satu atau kedua teknologi olahpesan mungkin tidak tersedia pada rute yang disambungkan.
- Rute yang dijemahkan 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 ubah pengambilan data untuk SQL Server untuk 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 di infrastruktur olahpesan sistem tujuan. Jembatan meneruskan pesan antara antrean bayangan dan rekan-rekan mereka.
Untuk memenuhi perjanjian tingkat layanan ketersediaan (SLA) 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 membuka blokir pemrosesan. Jembatan mungkin memerlukan kebijakan coba lagi yang berbeda untuk mencegah kesalahan mengidentifikasi pesan sebagai racun jika terjadi kegagalan infrastruktur. Anda dapat menggunakan pola Circuit Breaker untuk menjeda penerusan.
Kapan menggunakan pola ini
Gunakan pola Jembatan Olahpesan saat 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.
- Koneksi sistem terdistribusi secara 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 untuk integrasi melebihi kapasitas sistem olahpesan atau menjadikan olahpesan solusi yang mahal untuk masalah tersebut.
Desain beban kerja
Arsitek harus mengevaluasi bagaimana pola Jembatan Olahpesan dapat digunakan dalam desain beban kerja mereka untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Contohnya:
| Pilar | Bagaimana pola ini mendukung tujuan pilar |
|---|---|
| Pengoptimalan Biaya difokuskan untuk mempertahankan dan meningkatkan pengembalian beban kerja Anda pada investasi. | 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 transisi olahpesan dan teknologi peristiwa dalam beban kerja Anda atau ketika Anda memiliki persyaratan heterogen dari dependensi eksternal. - OE:06 Menyebarkan perubahan beban kerja |
Seperti halnya keputusan desain apa pun, pertimbangkan tradeoff terhadap tujuan pilar lain yang mungkin diperkenalkan dengan pola ini.
Contoh
Ada aplikasi yang ditulis dalam kerangka kerja .NET 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 dari data penjadwalan perlu dibangun untuk memenuhi kebutuhan bisnis, dan strategi TI memanggil untuk membangun perangkat lunak baru sebagai aplikasi cloud-native untuk mengoptimalkan biaya dan waktu pengiriman.
Arsitektur berbasis antrean asinkron bekerja untuk tim beban kerja di masa lalu, sehingga tim akan menggunakan pendekatan arsitektur yang sama tetapi dengan teknologi modern, Bus Layanan. Tim beban kerja tidak ingin memperkenalkan komunikasi sinkron antara cloud dan penyebaran lokal untuk mengurangi latensi atau tidak tersedianya yang memengaruhi yang lain.
Tim memutuskan untuk menggunakan pola Jembatan Olahpesan 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.
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:
- Rob Bagby | Prospek Konten Arsitektur Utama
- Kyle Baley | Insinyur Perangkat Lunak
- Udi Dahan | Pendiri & CEO Perangkat Lunak Tertentu
- Chad Kittel | Insinyur Perangkat Lunak Utama
- Bryan Lamos | Hubungan Pengembang
- Szymon Pobiega | Insinyur
Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.
Langkah berikutnya
- Deskripsi pola Jembatan Olahpesan dari komunitas pola integrasi perusahaan.
- Pelajari cara menerapkan Messaging Bridge dalam kerangka kerja Spring Java.
- Jembatan QPid dapat digunakan untuk menjembatani teknologi olahpesan berkemampuan AMQP.
- NServiceBus Messaging Bridge adalah implementasi .NET dari jembatan antrean ke antrean yang mendukung berbagai infrastruktur olahpesan termasuk MSMQ, Bus Layanan, dan Azure Queue Storage.
- NServiceBus.Router adalah proyek sumber terbuka yang mengimplementasikan pola Jembatan Olahpesan. Ini juga memungkinkan menjelajah lebih dari dua teknologi dalam satu instans dan memiliki kemampuan perutean pesan tingkat lanjut.
Sumber daya terkait
- Pola Competing Consumers memastikan implementasi Messaging Bridge dapat menangani beban.
- Pola Coba Lagi memungkinkan Jembatan Olahpesan menangani kegagalan sementara.
- Pola Circuit Breaker menghemat sumber daya ketika salah satu sisi jembatan mengalami waktu henti.