Yayımcı-Abone deseni

Bir uygulamanın, gönderenlerle alıcıları eşlemeden etkinlikleri ilgi duyan birden çok tüketiciye zaman uyumsuz bir şekilde duyurmasını sağlayın.

Ayrıca: Pub/sub messaging

Bağlam ve sorun

Bulut tabanlı ve dağıtılmış uygulamalarda, sistem bileşenlerinin genellikle olaylar gerçekleştiğinde diğer bileşenlere bilgi sağlaması gerekir.

Zaman uyumsuz mesajlaşma, gönderenleri tüketicilerden ayırmanın ve gönderenin yanıt beklemesini engellemeyi önlemenin etkili bir yoludur. Ancak, her tüketici için ayrılmış bir ileti kuyruğu kullanmak, birçok tüketiciye etkili bir şekilde ölçeklendirilmez. Ayrıca, bazı tüketiciler bilgilerin yalnızca bir alt kümesiyle ilgilenebilir. Gönderen, kimliklerini bilmeden tüm ilgili tüketicilere olayları nasıl duyurabilir?

Çözüm

Aşağıdakileri içeren zaman uyumsuz bir mesajlaşma alt sistemini tanıtın:

• Gönderen tarafından kullanılan bir giriş mesajlaşma kanalı. Gönderen, bilinen bir ileti biçimini kullanarak olayları iletilere paketler ve bu iletileri giriş kanalı üzerinden gönderir. Bu desendeki gönderen, yayımcı olarak da adlandırılır.

  Not

  İleti, bir veri paketidir. Olay, diğer bileşenlere bir değişiklik veya gerçekleştirilen bir eylem hakkında bilgi veren bir iletidir.

• Tüketici başına bir çıkış mesajlaşma kanalı. Tüketiciler abone olarak bilinir.

• Bu iletiyle ilgilenen tüm aboneler için her iletiyi giriş kanalından çıkış kanallarına kopyalama mekanizması. Bu işlem genellikle ileti aracısı veya olay veri yolu gibi bir aracı tarafından işlenir.

Aşağıdaki diyagramda bu desenin mantıksal bileşenleri gösterilmektedir:

Pub/sub mesajlaşma aşağıdaki avantajlara sahiptir:

• İletişim kurması gereken alt sistemleri birbirinden çıkarır. Alt sistemler bağımsız olarak yönetilebilir ve bir veya daha fazla alıcı çevrimdışı olsa bile iletiler düzgün yönetilebilir.

• Ölçeklenebilirliği artırır ve gönderenin yanıt hızını artırır. Gönderen, giriş kanalına hızlı bir şekilde tek bir ileti gönderebilir ve ardından temel işlem sorumluluklarına geri dönebilir. İleti altyapısı, iletilerin ilgili abonelere teslim edilmesini sağlamakla sorumludur.

• Güvenilirliği artırır. Zaman uyumsuz mesajlaşma, uygulamaların artan yükler altında sorunsuz bir şekilde çalışmaya devam etmelerine ve aralıklı hataları daha etkili bir şekilde işlemelerine yardımcı olur.

• Ertelenmiş veya zamanlanmış işlemeye izin verir. Aboneler yoğun olmayan saatlere kadar iletileri almayı bekleyebilir veya iletiler belirli bir zamanlamaya göre yönlendirilebilir veya işlenebilir.

• Farklı platformları, programlama dillerini veya iletişim protokollerini kullanan sistemler arasında ve bulutta çalışan şirket içi sistemlerle uygulamalar arasında daha basit bir tümleştirme sağlar.

• Kuruluş genelinde zaman uyumsuz iş akışlarını kolaylaştırır.

• Test edilebilirliği artırır. Kanallar izlenebilir ve tümleştirme testi stratejisinin bir parçası olarak iletiler incelenebilir veya günlüğe kaydedilebilir.

• Uygulamalarınız için endişelerin ayrılmasını sağlar. Her uygulama temel özelliklerine odaklanabilirken mesajlaşma altyapısı iletileri birden çok tüketiciye güvenilir bir şekilde yönlendirmek için gereken her şeyi işler.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzenin nasıl uygulanacağına karar verirken aşağıdaki noktaları göz önünde bulundurun:

• Mevcut teknolojiler. Kendi aboneliğinizi oluşturmak yerine yayımlama-abone olma modelini destekleyen kullanılabilir mesajlaşma ürünlerini ve hizmetlerini kullanmanız kesinlikle önerilir. Azure'da Service Bus, Event Hubs veya Event Grid kullanmayı göz önünde bulundurun. Pub/sub mesajlaşması için kullanılabilecek diğer teknolojiler Redis, RabbitMQ ve Apache Kafka'dır.

• Abonelik işleme. Mesajlaşma altyapısı, tüketicilerin kullanılabilir kanallara abone olmak veya abonelikten çıkmak için kullanabileceği mekanizmalar sağlamalıdır.

• Güvenlik. Yetkisiz kullanıcıların veya uygulamaların gizlice dinlemesini önlemek için herhangi bir ileti kanalına bağlanmanın güvenlik ilkesi tarafından kısıtlanması gerekir.

• İletilerin alt kümeleri. Aboneler genellikle bir yayımcı tarafından dağıtılan iletilerin yalnızca bir alt kümesiyle ilgilenir. Mesajlaşma hizmetleri genellikle abonelerin aşağıdakiler tarafından alınan ileti kümesini daraltmasına olanak sağlar:

  • Konu. Her konunun ayrılmış bir çıkış kanalı vardır ve her tüketici ilgili tüm konulara abone olabilir.
  • İçerik filtreleme. İletiler, her iletinin içeriğine göre incelenir ve dağıtılır. Her abone ilgilendiği içeriği belirtebilir.

• Joker karakter aboneleri. Abonelerin joker karakterler aracılığıyla birden çok konuya abone olmasını sağlamayı göz önünde bulundurun.

• çift yönlü iletişim. Yayımlama-abone olma sistemindeki kanallar tek yönlü olarak değerlendirilir. Belirli bir abonenin bildirim göndermesi veya durumu yayımcıya geri iletmesi gerekiyorsa İstek/Yanıt Düzeni'ni kullanmayı göz önünde bulundurun. Bu düzende aboneye ileti göndermek için bir kanal ve yayımcıyla iletişim kurmak için ayrı bir yanıt kanalı kullanılır.

• Mesaj sıralama. Tüketici örneklerinin iletileri alma sırası garanti değildir ve iletilerin oluşturulma sırasını yansıtması şart değildir. İleti işleme sırasına bağımlılığı ortadan kaldırmaya yardımcı olmak için, ileti işlemenin bir kez etkili olduğundan emin olmak için sistemi tasarlayın.

• İleti önceliği. Bazı çözümler, iletilerin belirli bir sırada işlenmesini gerektirebilir. Öncelik Sırası düzeni, belirli iletilerin diğerlerinden önce teslim edilmesini sağlamaya yönelik bir mekanizma sağlar.

• Zehirli mesajlar. Hatalı biçimlendirilmiş bir ileti veya kullanılabilir durumda olmayan kaynaklara erişim gerektiren bir görev, bir hizmet örneğinin başarısız olmasına yol açabilir. Sistem bu tür iletilerin kuyruğa döndürülmesini engellemelidir. Bunun yerine, gerekirse analiz edilebilmeleri için bu iletilerin ayrıntılarını yakalayın ve başka bir yerde depolayın. Azure Service Bus gibi bazı ileti aracıları, teslim edilemeyen ileti kuyruğu işlevleri aracılığıyla bunu destekler.

• Yinelenen iletiler. Aynı ileti birden çok kez gönderilebilir. Örneğin, bir ileti gönderildikten sonra gönderen başarısız olabilir. Ardından gönderenin yeni bir örneği başlatılıp iletiyi tekrarlayabilir. İletilerin en çok bir kez teslimini sağlamak için mesajlaşma altyapısı, ileti kimliklerini temel alarak yinelenen ileti algılama ve kaldırma (yinelenenleri kaldırma olarak da bilinir) uygulamalıdır. Alternatif olarak, iletilerin yinelenenlerini kaldırmayan mesajlaşma altyapısını kullanıyorsanız ileti işleme mantığının bir kez etkili olduğundan emin olun.

• İleti süre sonu. İletinin kullanım ömrü sınırlı olabilir. Bu süre içinde işlenmediyse, artık ilgili olmayabilir ve atılmalıdır. Gönderen, iletideki verilerin bir parçası olarak bir süre sonu belirtebilir. Alıcı, iletiyle ilişkili iş mantığını gerçekleştirip gerçekleştirmeyeceğine karar vermeden önce bu bilgileri inceleyebilir.

• İleti zamanlaması. İleti geçici olarak ambargoya alınabilir ve belirli bir tarih ve saate kadar işlenmemelidir. İleti bu zamana kadar alıcı tarafından kullanılamamalıdır.

• Abonelerin ölçeğini genişletme. Belirli bir abone aldığı iletilerin hızına ayak uyduramıyorsa ölçeği genişletmek için Rakip Tüketiciler desenini kullanın.

Bu düzenin kullanılacağı durumlar

Bu düzeni aşağıdaki durumlarda kullanın:

• Bir uygulamanın önemli sayıda tüketiciye bilgi yayınlaması gerekir.

• Bir uygulamanın farklı platformlar, programlama dilleri ve iletişim protokolleri kullanabilen, bağımsız olarak geliştirilmiş bir veya daha fazla uygulama veya hizmetle iletişim kurması gerekir.

• Bir uygulama, tüketicilerin gerçek zamanlı yanıtlarına gerek kalmadan tüketicilere bilgi gönderebilir.

• Tümleştirilen sistemler, verileri için nihai tutarlılık modelini destekleyecek şekilde tasarlanmıştır.

• Bir uygulamanın birden çok tüketiciye bilgi iletmesi gerekir. Bu, gönderenden farklı kullanılabilirlik gereksinimlerine veya çalışma süresi zamanlamalarına sahip olabilir.

Bu düzen aşağıdaki durumlarda kullanışlı olmayabilir:

• Bir uygulamanın, üreten uygulamadan önemli ölçüde farklı bilgilere ihtiyacı olan yalnızca birkaç tüketicisi vardır.

• Bir uygulama, tüketicilerle neredeyse gerçek zamanlı etkileşim gerektirir.

İş yükü tasarımı

Bir mimar, Azure İyi Tasarlanmış Çerçeve yapılarında ele alınan hedefleri ve ilkeleri ele almak için yayımcı/abone deseninin iş yükünün tasarımında nasıl kullanılabileceğini değerlendirmelidir. Örneğin:

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

Aşağıdaki diyagramda iş akışlarını koordine etmek için Service Bus kullanan bir kurumsal tümleştirme mimarisi ve gerçekleşen olayları alt sistemlere bildirmek için Event Grid gösterilmektedir. Daha fazla bilgi için bkz . İleti kuyruklarını ve olaylarını kullanarak Azure'da kurumsal tümleştirme.

Sonraki adımlar

Bu desen uygulanırken aşağıdaki yönergeler uygun olabilir:

• İletileri teslim eden Azure hizmetleri arasında seçim yapın.

• Zaman Uyumsuz Mesajlaşma Temel Bilgileri. Mesaj kuyrukları zaman uyumsuz bir iletişim mekanizmasıdır. Bir tüketici hizmetinin bir uygulamaya yanıt göndermesi gerekiyorsa bir tür yanıt mesajlaşması uygulamak gerekebilir. Zaman Uyumsuz Mesajlaşma Temel Bilgileri sayfasında mesaj kuyrukları kullanılarak nasıl istek/yanıt mesajlaşması uygulanabileceği hakkında bilgi sağlanmaktadır.

Bu desen uygulanırken aşağıdaki desenler uygun olabilir:

• Gözlemci düzeni. Yayımla-Abone Ol düzeni, zaman uyumsuz mesajlaşma yoluyla konuları gözlemcilerden ayrıştırarak Gözlemci desenini temel alır.

• İleti Aracısı düzeni. Yayımlama-abone olma modelini destekleyen birçok mesajlaşma alt sistemi bir ileti aracısı aracılığıyla uygulanır.

Bu blog gönderisi , sıra dışı gelen iletileri işlemenin farklı yollarını açıklar.

İlgili kaynaklar

• Olay odaklı mimari stili, pub/sub mesajlaşması kullanan bir mimari stilidir.
• Bir kez etkili ileti işleme
• İleti kuyruklarını ve olaylarını kullanarak Azure'da kurumsal tümleştirme