Bu makalede, farklı mesajlaşma altyapıları üzerinde oluşturulan farklı sistemleri tümleştirmek için kullanabileceğiniz bir teknik olan Mesajlaşma Köprüsü düzeni açıklanmaktadı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 bir iletiden mesaj çeker ve bunları diğerine iter.
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ı sisteminin aldığı farklı bir mesajlaşma altyapısındaki başka 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 bir kerede tümü yerine izin verdikçe uç noktalar bir mesajlaşma altyapısından diğerine geçirilebilir.
Dezavantaj -ları
- 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 dağıtılmış işlemlere (örneğin, Microsoft Dağıtılmış İşlem Düzenleyicisi'ne (DTC) dayanırsa, doğruluk için 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ştirilemiyorsa, diğer sistem tarafından kullanılan altyapı ile SQL Server öykünmüş kuyruğu arasında 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 sözleşmelerini (SLA) karşılamak 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 zehirli iletileri algılamasını ve işleme engellemesini kaldırmak için bunları kuyruktan kaldırması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 kullanabilen eski uygulamaları tümleştirin.
- 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 desenle ortaya konulabilecek diğer sütunların hedeflerine karşı herhangi bir dengeyi göz önünde bulundurun.
Örnek
Şirket içinde barındırılan çalışan zamanlamasını yönetmek için .NET çerçevesinde yazılmış bir uygulama 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.
Zaman uyumsuz kuyruk tabanlı mimari geçmişte iş yükü ekibi için çalışıyordu, bu nedenle ekip aynı mimari yaklaşımı kullanacak ancak modern teknoloji olan Service Bus ile kullanılacak. İş yükü ekibi, birini etkileyen gecikme süresini veya kullanılamamasını azaltmak için bulut ile şirket içi dağıtım arasında zaman uyumlu iletişim sağlamak 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 Mimari İçerik Müşteri Adayı
- 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
- Bryan Lamos | Geliştirici İlişkileri
- 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ğundan 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.
- Bağlantı Hattı Kesici düzeni, köprünün iki tarafında da kapalı kalma süresi yaşantığında kaynakları korur.