Mesajlaşma Köprüsü düzeni

Azure Service Bus

Farklı mesajlaşma altyapıları üzerinde oluşturulan mesajlaşma sistemlerine bağlanın ve iletileri bunlar arasında aktarın. Bu yaklaşım, sistemlerin kendilerini değiştirmeden farklı sistemleri tümleştirmenize olanak tanır.

Bağlam ve sorun

Birçok kuruluş ve iş yükü, microsoft message queueing (MSMQ), RabbitMQ, Azure Service Bus ve Amazon SQS gibi birden çok mesajlaşma altyapısını kullanan BT sistemlerine yanlışlıkla sahip olabilir. Bu sorun, birleştirmeler, satın almalar veya geçerli şirket içi sistemlerin maliyet verimliliği ve bakım kolaylığı için bulutta barındırılan bileşenlere genişletilmesinden kaynaklanabilir.

Geliştiriciler, HTTP tabanlı web hizmetlerini kullanarak iletişim kurmak için tümleştirilmekte olan sistemleri değiştirerek bu sorunu çözebilir. Ancak, bu yaklaşımın dezavantajları vardır, örneğin:

• Sistemlerin bir tarafına HTTP istemcisi, diğer tarafına bir HTTP isteği işleyicisi eklenerek değiştirilmesi gerekir. Ardından sistemlerin yeniden test edilmesi ve yeniden dağıtılması gerekir.
• HTTP uç noktalarının barındırılması gerekir ve bu da web hizmetlerini güvenli ve yüksek oranda kullanılabilir hale getirdiğinizde karmaşıklığı artırır.
• Özel olarak oluşturulmuş yeniden deneme mekanizmaları gerektiren sık karşılaşılan ağ bağlantısı sorunları.

Çözüm

Tümleştirilen sistemler, ileti alışverişinde bulunarak iletişim kuran bileşenlerden oluşuyorsa, Mesajlaşma Köprüsü düzeni tümleştirmeyi geliştirir ve dezavantajları azaltır.

Bu senaryoda, her sistem bir mesajlaşma altyapısına bağlanır. Farklı mesajlaşma altyapıları arasında tümleştirmek için, aynı anda iki veya daha fazla mesajlaşma altyapısına bağlanan bir köprü bileşeni tanıtın. Köprü, yükü değiştirmeden mesajları bir yerden alır ve diğerine iletir.

Tümleştirilen sistemlerin diğerlerini veya köprüyü tanıması gerekmez. Gönderen sistemi, yerel mesajlaşma altyapısında belirli iletileri belirlenen kuyruğa gönderecek şekilde yapılandırılmıştır. Köprü bu iletileri alır ve alıcı sistemin aldığı başka bir mesajlaşma altyapısındaki bir kuyruğa iletir.

Sosyal haklar

• Mesajlaşma Köprüsü aracılığıyla tümleştirilen sistemlerin değiştirilmesi gerekmez. İdeal olarak uç noktalar iletilerin köprülendiğinin farkında değildir.
• En az bir kez ileti teslim mekanizması garantisi nedeniyle tümleştirme, HTTP alternatifine kıyasla daha güvenilirdir.
• Geçiş senaryoları daha esnek olabilir. Örneğin, zamanlama uygun oldukça uç noktalar bir mesajlaşma altyapısından diğerine, hepsi bir seferde yerine, kademeli olarak geçirilebilir.

Dezavantajları

• Mesajlaşma teknolojilerinden birinin veya her ikisinin gelişmiş özellikleri köprülenmiş yolda kullanılamayabilir.
• Köprülenmiş yolun her iki teknolojinin sınırlamalarını da dikkate alması gerekir. Örneğin, en büyük ileti boyutu MSMQ'da 4 MB, Azure Depolama kuyruklarında ise yalnızca 64 KB olabilir.

Sorunlar ve dikkat edilmesi gerekenler

Mesajlaşma Köprüsü desenini uygularken aşağıdaki noktaları göz önünde bulundurun:

• Tümleşik sistemlerden biri, doğruluğunu sağlamak için dağıtılmış işlemlere dayanıyorsa, örneğin Microsoft Dağıtılmış İşlem Düzenleyicisi (DTC) gibi, köprüde bir yinelenenleri kaldırma mekanizması uygulamanız gerekir.

• Tümleştirilen sistemlerden biri herhangi bir mesajlaşma altyapısı kullanmıyorsa ve değiştirilemezse, diğer sistemin kullandığı altyapı ile SQL Server emülasyonu yapılan kuyruk arasında bir Mesajlaşma Köprüsü oluşturabilirsiniz. Eski sistem, SQL Server'ın değişiklik verilerini yakalama özelliğini kullanarak değişikliklerini ayrılmış bir kuyruk tablosuna göndererek ileti gönderebilir. Köprü, bu iletileri gerçek mesajlaşma altyapısına iletebilir.

• Köprü oluşturma kuyruğu olarak belirlenen her mesajlaşma altyapısında tek bir kuyruk kullanabilirsiniz. Bu topolojide, gönderen sistemi, diğer sisteme gönderilen ileti türleri için hedef olarak bu kuyruğu kullanacak şekilde yapılandırın. Ayrıca her mesajlaşma altyapısında birden çok kuyruk çifti kullanabilirsiniz, böylece gönderen köprüden haberdar değildir. Hedef sistemin mesajlaşma altyapısındaki her hedef kuyruk için bir gölge kuyruk oluşturulur. Köprü, iletileri gölge kuyruklar ve karşılık gelenler arasında iletir.

• İstenen kullanılabilirlik hizmet düzeyi hedeflerine (SLO) ulaşmak için Rakip tüketiciler yaklaşımını kullanarak Mesajlaşma Köprüsü'nün ölçeğini genişletmeniz gerekebilir.

• Normal ileti işleme bileşenleri, geçici hataları işlemek için Yeniden Deneme desenini kullanır. Yeniden deneme sayacı sınırı, bileşenlerin poison mesajları algılamasını ve işlem engelini kaldırmak için bunları kuyruktan çıkarmasını sağlar. Köprü, bir altyapı hatası oluştuğunda iletileri hatalı bir şekilde zehir olarak tanımlamayı önlemek için farklı bir yeniden deneme ilkesi gerektirebilir. İletme işlemini duraklatmak için Devre Kesici desenini kullanabilirsiniz.

Bu düzenin kullanılacağı durumlar

Aşağıdakileri yapmanız gerektiğinde Mesajlaşma Köprüsü desenini kullanın:

• Mevcut sistemleri en az değişiklik gereksinimiyle tümleştirin.
• Diğer mesajlaşma teknolojilerini kullanamayan eski uygulamaları entegre edin.
• Mevcut şirket içi uygulamaları bulutta barındırılan bileşenlerle genişletin.
• İnternet bağlantısı kararlı olmadığında coğrafi olarak dağıtılmış sistemleri bağlayın.
• Tek bir eforla sistemin tamamını geçirmeye gerek kalmadan tek bir dağıtılmış sistemi bir mesajlaşma altyapısından diğerine artımlı olarak geçirme.

Aşağıdaki durumlar için bu düzen uygun olmayabilir:

• İlgili sistemlerden en az biri, diğerinde mevcut olmayan bir mesajlaşma altyapısının özelliğine dayanır.
• Tümleştirme doğası gereği zaman uyumludur ve başlatma sistemi hemen yanıt gerektirir.
• Tümleştirmenin güvenlik veya gizlilik endişeleri gibi belirli işlevsel veya işlev dışı gereksinimleri vardır.
• Tümleştirme için veri hacmi mesajlaşma sisteminin kapasitesini aşıyor veya mesajlaşmayı soruna pahalı bir çözüm haline getiriyor.

İş yükü tasarımı

Bir mimar, Azure İyi Tasarlanmış Çerçeve yapılarında ele alınan hedefleri ve ilkeleri ele almak için mesajlaşma köprüsü düzeninin iş yükünün tasarımında nasıl kullanılabileceğini değerlendirmelidir. Örneğin:

Yapı Taşı	Bu desen sütun hedeflerini nasıl destekler?
Maliyet İyileştirme, iş yükünüzün yatırım getirisini sürdürmeye ve geliştirmeye odaklanır.	Bu ara adım, farklı bir mesajlaşma veya olay teknolojisi kullanan sistemlerle birlikte çalışabilirlik sağlayarak yeniden yazma gerekmeden mevcut sisteminizin uzun ömürlülüğünü artırabilir. - CO:07 Bileşen maliyetleri
Operasyonel Mükemmellik, standartlaştırılmış süreçler ve ekip uyumu aracılığıyla iş yükü kalitesinin sunulmasına yardımcı olur.	Bu ayırma, iş yükünüz içinde mesajlaşma ve olay teknolojisi geçişi yaptığınızda veya dış bağımlılıklardan heterojen gereksinimleriniz olduğunda esneklik sağlar. - OE:06 İş yükü değişikliklerini dağıtma

Herhangi bir tasarım kararında olduğu gibi, bu modelle ilişkilendirilebilecek temel bileşenlerin hedeflerine karşı olası dengeleri göz önünde bulundurun.

Örnek

Şirket içinde barındırılan çalışan zamanlamalarını yönetmeye yönelik bir .NET Framework uygulaması vardır. Uygulama, MSMQ aracılığıyla iletişim kurarak ayrı bileşenlerle iyi yapılandırılmıştır. Uygulama çalışır ve iş yükü ekibinin uygulamayı yeniden yazmaya niyeti yoktur. Zamanlama verilerinin yeni bir tüketicisinin bir iş gereksinimini karşılayacak şekilde oluşturulması gerekir ve BT stratejisi, maliyetleri ve teslim süresini iyileştirmek için yeni yazılımları buluta özel uygulamalar olarak oluşturmayı gerektirir.

Asenkron kuyruk tabanlı mimari, geçmişte iş yükü ekibinde etkili olmuştu, bu nedenle ekip, aynı mimari yaklaşımla fakat modern teknoloji olan Service Bus ile devam edecek. İş yükü takımı, bulut ve şirket içi dağıtım arasında birinin gecikme süresinin veya kullanılamamasının diğerini etkilemesini önlemek için eş zamanlı iletişim sağlamayı istemiyor.

Ekip, iki sistemi bağlamak için Mesajlaşma Köprüsü desenini kullanmaya karar verir. Desen iki bölümden oluşur. Bir bölüm, mevcut MSMQ kuyruğundan iletileri alır ve Service Bus'a iletir. Diğer bölüm, Service Bus'tan iletileri alır ve mevcut MSMQ kuyruğuna iletir.

Uygulama ekibi bu yaklaşımı kullandığında, yeni bileşenlerle tümleştirmek için mevcut uygulamada mevcut altyapıyı kullanır. Mevcut uygulama, yeni bileşenlerin Azure'da barındırıldığının farkında değildir. Benzer şekilde, yeni bileşenler Service Bus iletileri göndererek eski uygulamayla kendi aralarında iletişim kurar gibi iletişim kurar. Köprü, iletileri iki sistem arasında iletir.

Katkıda Bulunanlar

Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazarlar:

• Rob Bagby | Asıl İçerik Geliştiricisi - Azure Desenleri ve Uygulamaları
• Kyle Baley | Yazılım Mühendisi
• Udi Dahan | Belirli Yazılımların Kurucusu ve CEO'su
• Chad Kittel | Baş Yazılım Mühendisi - Azure Desenleri ve Uygulamaları
• Bryan Lamos | İçerik Geliştiricisi - Azure Desenleri ve Uygulamaları
• Szymon Pobiega | Mühendis

Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.

Sonraki adımlar

• Kurumsal tümleştirme desenleri topluluğu tarafından sağlanan Mesajlaşma Köprüsü desen açıklaması.
• Spring Java çerçevesinde Mesajlaşma Köprüsü uygulamayı öğrenin.
• QPid köprüsü , AMQP özellikli mesajlaşma teknolojilerinin köprülerini açmak için kullanılabilir.
• NServiceBus Mesajlaşma Köprüsü MSMQ, Service Bus ve Azure Kuyruk Depolama gibi çeşitli mesajlaşma altyapılarını destekleyen bir kuyruk-kuyruğa köprüsünün .NET uygulamasıdır.
• NServiceBus.Router , Mesajlaşma Köprüsü desenini uygulayan bir açık kaynak projedir. Ayrıca tek bir örnekte ikiden fazla teknolojinin köprü oluşturmasına olanak tanır ve gelişmiş ileti yönlendirme özelliklerine sahiptir.

İlgili kaynaklar

• Rakip Tüketiciler deseni, Mesajlaşma Köprüsü'nün uygulanmasının yükü işleyebilmesini sağlar.
• Yeniden Deneme düzeni, Mesajlaşma Köprüsü'nün geçici hataları işlemesini sağlar.
• Köprünün her iki tarafında da kapanma süresi sırasında Devre Kesici deseni kaynakları korur.

Farklı mesajlaşma altyapıları üzerinde oluşturulan mesajlaşma sistemlerine bağlanın ve iletileri bunlar arasında aktarın. Bu yaklaşım, sistemlerin kendilerini değiştirmeden farklı sistemleri tümleştirmenize olanak tanır.

Bağlam ve sorun

Birçok kuruluş ve iş yükü, microsoft message queueing (MSMQ), RabbitMQ, Azure Service Bus ve Amazon SQS gibi birden çok mesajlaşma altyapısını kullanan BT sistemlerine yanlışlıkla sahip olabilir. Bu sorun, birleştirmeler, satın almalar veya geçerli şirket içi sistemlerin maliyet verimliliği ve bakım kolaylığı için bulutta barındırılan bileşenlere genişletilmesinden kaynaklanabilir.

Geliştiriciler, HTTP tabanlı web hizmetlerini kullanarak iletişim kurmak için tümleştirilmekte olan sistemleri değiştirerek bu sorunu çözebilir. Ancak, bu yaklaşımın dezavantajları vardır, örneğin:

• Sistemlerin bir tarafına HTTP istemcisi, diğer tarafına bir HTTP isteği işleyicisi eklenerek değiştirilmesi gerekir. Ardından sistemlerin yeniden test edilmesi ve yeniden dağıtılması gerekir.
• HTTP uç noktalarının barındırılması gerekir ve bu da web hizmetlerini güvenli ve yüksek oranda kullanılabilir hale getirdiğinizde karmaşıklığı artırır.
• Özel olarak oluşturulmuş yeniden deneme mekanizmaları gerektiren sık karşılaşılan ağ bağlantısı sorunları.

Çözüm

Tümleştirilen sistemler, ileti alışverişinde bulunarak iletişim kuran bileşenlerden oluşuyorsa, Mesajlaşma Köprüsü düzeni tümleştirmeyi geliştirir ve dezavantajları azaltır.

Bu senaryoda, her sistem bir mesajlaşma altyapısına bağlanır. Farklı mesajlaşma altyapıları arasında tümleştirmek için, aynı anda iki veya daha fazla mesajlaşma altyapısına bağlanan bir köprü bileşeni tanıtın. Köprü, yükü değiştirmeden mesajları bir yerden alır ve diğerine iletir.

Tümleştirilen sistemlerin diğerlerini veya köprüyü tanıması gerekmez. Gönderen sistemi, yerel mesajlaşma altyapısında belirli iletileri belirlenen kuyruğa gönderecek şekilde yapılandırılmıştır. Köprü bu iletileri alır ve alıcı sistemin aldığı başka bir mesajlaşma altyapısındaki bir kuyruğa iletir.

Sosyal haklar

• Mesajlaşma Köprüsü aracılığıyla tümleştirilen sistemlerin değiştirilmesi gerekmez. İdeal olarak uç noktalar iletilerin köprülendiğinin farkında değildir.
• En az bir kez ileti teslim mekanizması garantisi nedeniyle tümleştirme, HTTP alternatifine kıyasla daha güvenilirdir.
• Geçiş senaryoları daha esnek olabilir. Örneğin, zamanlama uygun oldukça uç noktalar bir mesajlaşma altyapısından diğerine, hepsi bir seferde yerine, kademeli olarak geçirilebilir.

Dezavantajları

• Mesajlaşma teknolojilerinden birinin veya her ikisinin gelişmiş özellikleri köprülenmiş yolda kullanılamayabilir.
• Köprülenmiş yolun her iki teknolojinin sınırlamalarını da dikkate alması gerekir. Örneğin, en büyük ileti boyutu MSMQ'da 4 MB, Azure Depolama kuyruklarında ise yalnızca 64 KB olabilir.

Sorunlar ve dikkat edilmesi gerekenler

Mesajlaşma Köprüsü desenini uygularken aşağıdaki noktaları göz önünde bulundurun:

• Tümleşik sistemlerden biri, doğruluğunu sağlamak için dağıtılmış işlemlere dayanıyorsa, örneğin Microsoft Dağıtılmış İşlem Düzenleyicisi (DTC) gibi, köprüde bir yinelenenleri kaldırma mekanizması uygulamanız gerekir.

• Tümleştirilen sistemlerden biri herhangi bir mesajlaşma altyapısı kullanmıyorsa ve değiştirilemezse, diğer sistemin kullandığı altyapı ile SQL Server emülasyonu yapılan kuyruk arasında bir Mesajlaşma Köprüsü oluşturabilirsiniz. Eski sistem, SQL Server'ın değişiklik verilerini yakalama özelliğini kullanarak değişikliklerini ayrılmış bir kuyruk tablosuna göndererek ileti gönderebilir. Köprü, bu iletileri gerçek mesajlaşma altyapısına iletebilir.

• Köprü oluşturma kuyruğu olarak belirlenen her mesajlaşma altyapısında tek bir kuyruk kullanabilirsiniz. Bu topolojide, gönderen sistemi, diğer sisteme gönderilen ileti türleri için hedef olarak bu kuyruğu kullanacak şekilde yapılandırın. Ayrıca her mesajlaşma altyapısında birden çok kuyruk çifti kullanabilirsiniz, böylece gönderen köprüden haberdar değildir. Hedef sistemin mesajlaşma altyapısındaki her hedef kuyruk için bir gölge kuyruk oluşturulur. Köprü, iletileri gölge kuyruklar ve karşılık gelenler arasında iletir.

• İstenen kullanılabilirlik hizmet düzeyi hedeflerine (SLO) ulaşmak için Rakip tüketiciler yaklaşımını kullanarak Mesajlaşma Köprüsü'nün ölçeğini genişletmeniz gerekebilir.

• Normal ileti işleme bileşenleri, geçici hataları işlemek için Yeniden Deneme desenini kullanır. Yeniden deneme sayacı sınırı, bileşenlerin poison mesajları algılamasını ve işlem engelini kaldırmak için bunları kuyruktan çıkarmasını sağlar. Köprü, bir altyapı hatası oluştuğunda iletileri hatalı bir şekilde zehir olarak tanımlamayı önlemek için farklı bir yeniden deneme ilkesi gerektirebilir. İletme işlemini duraklatmak için Devre Kesici desenini kullanabilirsiniz.

Bu düzenin kullanılacağı durumlar

Aşağıdakileri yapmanız gerektiğinde Mesajlaşma Köprüsü desenini kullanın:

• Mevcut sistemleri en az değişiklik gereksinimiyle tümleştirin.
• Diğer mesajlaşma teknolojilerini kullanamayan eski uygulamaları entegre edin.
• Mevcut şirket içi uygulamaları bulutta barındırılan bileşenlerle genişletin.
• İnternet bağlantısı kararlı olmadığında coğrafi olarak dağıtılmış sistemleri bağlayın.
• Tek bir eforla sistemin tamamını geçirmeye gerek kalmadan tek bir dağıtılmış sistemi bir mesajlaşma altyapısından diğerine artımlı olarak geçirme.

Aşağıdaki durumlar için bu düzen uygun olmayabilir:

• İlgili sistemlerden en az biri, diğerinde mevcut olmayan bir mesajlaşma altyapısının özelliğine dayanır.
• Tümleştirme doğası gereği zaman uyumludur ve başlatma sistemi hemen yanıt gerektirir.
• Tümleştirmenin güvenlik veya gizlilik endişeleri gibi belirli işlevsel veya işlev dışı gereksinimleri vardır.
• Tümleştirme için veri hacmi mesajlaşma sisteminin kapasitesini aşıyor veya mesajlaşmayı soruna pahalı bir çözüm haline getiriyor.

İş yükü tasarımı

Bir mimar, Azure İyi Tasarlanmış Çerçeve yapılarında ele alınan hedefleri ve ilkeleri ele almak için mesajlaşma köprüsü düzeninin iş yükünün tasarımında nasıl kullanılabileceğini değerlendirmelidir. Örneğin:

Yapı Taşı	Bu desen sütun hedeflerini nasıl destekler?
Maliyet İyileştirme, iş yükünüzün yatırım getirisini sürdürmeye ve geliştirmeye odaklanır.	Bu ara adım, farklı bir mesajlaşma veya olay teknolojisi kullanan sistemlerle birlikte çalışabilirlik sağlayarak yeniden yazma gerekmeden mevcut sisteminizin uzun ömürlülüğünü artırabilir. - CO:07 Bileşen maliyetleri
Operasyonel Mükemmellik, standartlaştırılmış süreçler ve ekip uyumu aracılığıyla iş yükü kalitesinin sunulmasına yardımcı olur.	Bu ayırma, iş yükünüz içinde mesajlaşma ve olay teknolojisi geçişi yaptığınızda veya dış bağımlılıklardan heterojen gereksinimleriniz olduğunda esneklik sağlar. - OE:06 İş yükü değişikliklerini dağıtma

Herhangi bir tasarım kararında olduğu gibi, bu modelle ilişkilendirilebilecek temel bileşenlerin hedeflerine karşı olası dengeleri göz önünde bulundurun.

Örnek

Şirket içinde barındırılan çalışan zamanlamalarını yönetmeye yönelik bir .NET Framework uygulaması vardır. Uygulama, MSMQ aracılığıyla iletişim kurarak ayrı bileşenlerle iyi yapılandırılmıştır. Uygulama çalışır ve iş yükü ekibinin uygulamayı yeniden yazmaya niyeti yoktur. Zamanlama verilerinin yeni bir tüketicisinin bir iş gereksinimini karşılayacak şekilde oluşturulması gerekir ve BT stratejisi, maliyetleri ve teslim süresini iyileştirmek için yeni yazılımları buluta özel uygulamalar olarak oluşturmayı gerektirir.

Asenkron kuyruk tabanlı mimari, geçmişte iş yükü ekibinde etkili olmuştu, bu nedenle ekip, aynı mimari yaklaşımla fakat modern teknoloji olan Service Bus ile devam edecek. İş yükü takımı, bulut ve şirket içi dağıtım arasında birinin gecikme süresinin veya kullanılamamasının diğerini etkilemesini önlemek için eş zamanlı iletişim sağlamayı istemiyor.

Ekip, iki sistemi bağlamak için Mesajlaşma Köprüsü desenini kullanmaya karar verir. Desen iki bölümden oluşur. Bir bölüm, mevcut MSMQ kuyruğundan iletileri alır ve Service Bus'a iletir. Diğer bölüm, Service Bus'tan iletileri alır ve mevcut MSMQ kuyruğuna iletir.

Uygulama ekibi bu yaklaşımı kullandığında, yeni bileşenlerle tümleştirmek için mevcut uygulamada mevcut altyapıyı kullanır. Mevcut uygulama, yeni bileşenlerin Azure'da barındırıldığının farkında değildir. Benzer şekilde, yeni bileşenler Service Bus iletileri göndererek eski uygulamayla kendi aralarında iletişim kurar gibi iletişim kurar. Köprü, iletileri iki sistem arasında iletir.

Katkıda Bulunanlar

Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazarlar:

• Rob Bagby | Asıl İçerik Geliştiricisi - Azure Desenleri ve Uygulamaları
• Kyle Baley | Yazılım Mühendisi
• Udi Dahan | Belirli Yazılımların Kurucusu ve CEO'su
• Chad Kittel | Baş Yazılım Mühendisi - Azure Desenleri ve Uygulamaları
• Bryan Lamos | İçerik Geliştiricisi - Azure Desenleri ve Uygulamaları
• Szymon Pobiega | Mühendis

Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.

Sonraki adımlar

• Kurumsal tümleştirme desenleri topluluğu tarafından sağlanan Mesajlaşma Köprüsü desen açıklaması.
• Spring Java çerçevesinde Mesajlaşma Köprüsü uygulamayı öğrenin.
• QPid köprüsü , AMQP özellikli mesajlaşma teknolojilerinin köprülerini açmak için kullanılabilir.
• NServiceBus Mesajlaşma Köprüsü MSMQ, Service Bus ve Azure Kuyruk Depolama gibi çeşitli mesajlaşma altyapılarını destekleyen bir kuyruk-kuyruğa köprüsünün .NET uygulamasıdır.
• NServiceBus.Router , Mesajlaşma Köprüsü desenini uygulayan bir açık kaynak projedir. Ayrıca tek bir örnekte ikiden fazla teknolojinin köprü oluşturmasına olanak tanır ve gelişmiş ileti yönlendirme özelliklerine sahiptir.

İlgili kaynaklar

• Rakip Tüketiciler deseni, Mesajlaşma Köprüsü'nün uygulanmasının yükü işleyebilmesini sağlar.
• Yeniden Deneme düzeni, Mesajlaşma Köprüsü'nün geçici hataları işlemesini sağlar.
• Köprünün her iki tarafında da kapanma süresi sırasında Devre Kesici deseni kaynakları korur.