Ve hiç var mı? Bana göre, MB hem aboneleri hem de yayıncıları tanıyor ve bir arabulucu görevi görüyor, aboneleri yeni mesajlar hakkında bilgilendiriyor (etkin bir "push" modeli). Öte yandan MQ, tüketicilerin mesajları bir kuyruktan çıkardığı bir "çekme" modelidir.
Burada tamamen yoldan sapmış mıyım?
Yanıtlar:
Genel olarak, satıcı yazılım ürünleri söz konusu olduğunda, bunlar birbirinin yerine kullanılır ve sizin tanımladığınız gibi itme veya çekme açısından güçlü ayrımlara sahip değildir.
OTOBÜS vs QUEUE gerçekten en son IBM MQ ve TIBCO buluşma gibi sistemlerden kaynaklanan biraz eski bir kavramdır. MQ başlangıçta 1: 1 bir sistemdi, aslında çeşitli sistemleri ayırmak için bir kuyruktu.
Bunun aksine Tibco, aynı konularda birden fazla yayıncı ve aboneye sahip olabileceğiniz (a) mesajlaşma omurgasıydı.
Ancak her ikisi de (ve daha yeni rakip ürünler) bugünlerde birbirlerinin alanında oynayabilir. Her ikisi de hem kesilecek hem de yeni mesajlar için sorgulama yapacak şekilde ayarlanabilir. Her ikisi de çeşitli sistemler arasındaki etkileşimlere aracılık eder.
Bununla birlikte , mesaj kuyruğu ifadesi, dahili iş parçacığı içi mesaj pompaları ve benzerleri için de kullanılır ve bu bağlamda, kullanım gerçekten farklıdır. Klasik Windows mesaj pompasını düşünürseniz, bu aslında daha çok tanımladığınız çekme modelidir, ancak gerçekten uygulama içi veya kutu içi olmaktan çok uygulama içi.
Mesaj Veriyolu
Bir Mesaj Veriyolu , farklı sistemlerin paylaşılan bir arabirim kümesi ( mesaj veriyolu ) aracılığıyla iletişim kurmasına izin veren bir mesajlaşma altyapısıdır .
Kaynak: EIP
Mesaj Sırası
Mesaj kuyruğunun temel fikri basittir:
İki (veya daha fazla) işlem, ortak bir sistem mesaj kuyruğuna erişim yoluyla bilgi alışverişi yapabilir .
Gönderme işlemi, bazı (OS) mesaj geçirme modülü aracılığıyla, başka bir işlem tarafından okunabilen bir kuyruğa bir mesaj yerleştirir.
Kaynak: Dave Marshall
Fark
Message Queue , FIFO ( ilk giren ilk çıkar ) kuralı içerirken, Message Bus'ta yoktur.
Sonuç
Hem BAKIŞ iki arasında mesaj taşıyorum - işin aynı tür yapıyor gibi uygulamalar veya Modülleri veya arabirimleri veya Sistemlerinin veya Süreçler arasında küçük bir fark dışında, FIFO
Bazı ürünler artık daha önce yalnızca bir kategoriye veya diğerine ait olan özellikleri desteklediğinden (örneğin, Azure Service Bus her iki yaklaşımı da destekler), bu iki kavram arasındaki çizgilerde bir miktar bulanıklaşma olmuştur.
Bir mesaj kuyruğu, bir uygulamadan mesajları alır ve bunları bir veya daha fazla başka uygulamada ilk giren ilk çıkar (FIFO) şeklinde kullanılabilir hale getirir. Birçok mimari senaryoda, A uygulamasının B ve C uygulamalarına güncellemeler veya komutlar göndermesi gerekiyorsa, B ve C için ayrı mesaj kuyrukları ayarlanabilir. A, her kuyruğa ayrı mesajlar yazacak ve her bağımlı uygulama kendi kuyruğundan okuyacaktır. kendi kuyruğu (kuyruktan çıktıktan sonra kaldırılan mesaj). A'nın güncellemeleri göndermesi için ne B ne de C'nin mevcut olması gerekmez. Her ileti kuyruğu kalıcıdır, bu nedenle bir uygulama yeniden başlarsa, tekrar çevrimiçi olduğunda kuyruğundan çekmeye başlar. Bu, bağımlı sistemler arasındaki bağımlılıkları ortadan kaldırmaya yardımcı olur ve uygulamalara daha fazla ölçeklenebilirlik ve hata toleransı sağlayabilir.
Bir mesaj veriyolu veya servis veriyolu, bir (veya daha fazla) uygulamanın mesajları bir veya daha fazla başka uygulamaya iletmesi için bir yol sağlar. İlk giren ilk çıkar siparişinin garantisi olmayabilir ve otobüs aboneleri mesaj gönderenlerin bilgisi olmadan gelip gidebilir. Bu nedenle, durum güncellemelerini B uygulamasına bir mesaj veriyolu yoluyla iletmek için bir uygulama A yazılabilir. Daha sonra bu güncellemelerden de yararlanabilecek C uygulaması yazılır. Uygulama C, A uygulamasında herhangi bir güncelleme gerektirmeden, mesaj veriyolunu dinleyecek ve bu güncellemelere dayalı olarak eylem yapacak şekilde yapılandırılabilir. Gönderen uygulamanın her kuyruğa açıkça mesajlar eklediği kuyrukların aksine, bir mesaj veriyolu bir yayınlama / modele abone olun. Mesajlar otobüse yayınlanır ve bu tür mesajlara abone olan herhangi bir uygulama mesajı alır.
Diğer cevaplarda açıkça belirtilmeyen temel fark, bir mesaj veriyolunun birden fazla aboneye izin verirken, bir kuyruğun öğeleri sırayı dinleyen herhangi bir şeye tek tek sıraya almasıdır. Birden fazla dinleyicinin kuyruktan çıkan aynı öğeleri görmesini istiyorsanız, bunu kendiniz halletmeniz gerekir, bir servis otobüsü bunu sizin için kutudan çıkarır.
Gördüğüm şekilde, Message Queue, Message Bus'ı oluşturur . İstemciler (yani düğümler) daha sonra mesaj veriyolunu dinleyebilir. Bu, özellikle UDP üzerinden mesajlar yayınlayan bir MQ'nuzun olduğu, diğer bir deyişle mesajları kimin alacağını bilmeden veya umursamadan bir yayın / çok noktaya yayın adresine mesajlar göndermesi durumunda geçerlidir. Bu senaryonun daha ayrıntılı bir açıklaması için bu makaleye bakabilirsiniz .
Service Bus, Message Queue'dan daha genel bir terimdir.
MQ basit bir FIFO'dur, ancak bir Servis Veriyolunu, yani mesajları işlemek için büyük bir "merkez" olan bir Olay Merkezini uygulamanın daha karmaşık yolları vardır. MQ tarafından sağlanan işlevselliğin yanı sıra, mesajların depolanmasına (ve dolayısıyla birden fazla abonenin kullanılmasına) vb. İzin verir.
Bir mesaj veriyolu, 1'e çok dağıtım modelidir. Bu modeldeki hedefe genellikle konu veya konu denir. Aynı yayınlanan mesaj, tüm tüketiciler tarafından alınır. Buna 'yayın' modeli de diyebilirsiniz. Bir konuyu, dağıtılmış hesaplama için bir Gözlemci tasarım modelindeki bir Öznenin eşdeğeri olarak düşünebilirsiniz. Bazı mesaj veriyolu sağlayıcıları bunu TCP yerine UDP olarak uygulamayı verimli bir şekilde seçer. Konu için mesaj teslimi 'ateşle ve unut' şeklindedir - kimse dinlemiyorsa mesaj kaybolur. İstediğiniz bu değilse, 'dayanıklı abonelikler' kullanabilirsiniz.
Bir mesaj kuyruğu, mesajların 1'e 1 hedefidir. Mesaj, tüketen alıcılardan yalnızca biri tarafından alınır (lütfen unutmayın: sürekli olarak aboneleri 'konu müşterileri için ve alıcıları kuyruk istemcisi için kullanmak kafa karışıklığını önler). Bir kuyruğa gönderilen mesajlar, birisi onu alana veya süresi dolana kadar diskte veya bellekte saklanır. Bu nedenle kuyruklar (ve kalıcı abonelikler) bazı aktif depolama yönetimi gerektirir, yavaş tüketicileri düşünmeniz gerekir.
Çoğu ortamda, konuların daha iyi bir seçim olduğunu, çünkü mimariyi değiştirmek zorunda kalmadan her zaman ek bileşenler ekleyebileceğinizi iddia ediyorum. Eklenen bileşenler izleme, günlük kaydı, analiz vb. Olabilir. Projenin başında 1 yıl, 5 yıl, 10 yıl içinde gereksinimlerin nasıl olacağını asla bilemezsiniz. Değişim kaçınılmazdır, kucaklayın :-)