Yayıncı-Abone Deseni

Olayları, gönderenleri alıcılara bağımlı kılmadan, bir aracı üzerinden birden çok ilgili alıcıya eşzamansız olarak yayınlayın. Pub/sub mesajlaşması olarak bilinen bu yaklaşım, gönderenin hangi tüketicilerin bunları aldığını bilmeden olayları yayımlamasına olanak tanır.

Bağlam ve sorun

Bulut tabanlı ve dağıtılmış uygulamalar genellikle olaylar gerçekleşirken diğer bileşenlere bilgi gönderen sistem bileşenlerini içerir. Bir gönderenin tüketicileriyle doğrudan iletişim kurması, her tüketicinin kimliğini ve uç noktasını bilmesi, her tüketiciye ileti teslim etmesi ve hataları tek tek yönetmesi gerekir. Bir tüketicinin eklenmesi veya kaldırılması, gönderende değişiklik yapılmasını gerektirir ve bu da ekiplerin bağımsız olarak bileşen geliştirme ve dağıtma şeklini sınırlar.

İleti kuyrukları, gönderenleri tüketicilerden ayırır ve gönderenin yanıt beklerken bir işlemi engellemesini engeller. Standart kuyruk, gönderen ile tek bir tüketici arasında doğrudan ilişki oluşturur. Birden çok tüketiciyi desteklemek için, gönderenin her tüketici için ayrı bir kuyruk oluşturması gerekir ve bu da yönlendirme karmaşıklığını artırır ve iyi ölçeklendirilmez. Bazı tüketiciler, gönderenin ürettiği bilgilerin yalnızca bir alt kümesine ihtiyaç duyar, ancak kuyruklar iletileri içeriğe veya kategoriye göre filtrelemek için yerleşik yollar sağlamaz.

Birçok senaryo, bir gönderenin bu tüketicilerin kim olduğunu bilmeden birçok ilgili tüketiciye olayları duyurmasını gerektirir. Her tüketicinin hangi olayları alacağına bağımsız olarak karar vermek için bir yönteme de ihtiyacı vardır.

Çözüm

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

• Gönderenin kullandığı bir giriş mesajlaşma kanalı. Gönderen, bilinen bir ileti biçimi kullanarak olayları iletilere paketler ve bu iletileri giriş kanalı üzerinden gönderir. Bu desendeki gönderen yayımcı olarak da bilinir.

  Uyarı

  İleti, bir veri paketidir. Olay, diğer bileşenlere bir değişiklik veya gerçekleşen bir eylem hakkında bilgi veren bir iletidir. Bu desen genellikle olaylarla çalışır, ancak komutlar ve durum bildirimleri de dahil olmak üzere her tür iletiyi de taşır.

• Her tüketici için 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ı. Mesaj aracısı veya olay otobüsü genellikle bu işlemi yönetir.

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

Diyagramda sol tarafta bir yayımcı gösterilir. Bir giriş kanalını gösteren bir ok. Giriş kanalından ortadaki bir ileti aracısına işaret eden bir ok. Mesaj aracısından çıkış kanalına işaret eden bir ok. Çıkış kanalından üç ok sağ tarafta üç ayrı aboneye işaret eder.

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

• İletişim kurması gereken alt sistemleri birbirinden çıkarır. Alt sistemler bağımsız yönetimi destekler ve bir veya daha fazla alıcı çevrimdışı olsa bile aracı iletileri korur.

• Ölçeklenebilirliği artırır ve gönderenin yanıt hızını artırır. Gönderen, giriş kanalına tek bir ileti gönderir ve ardından temel işleme sorumluluklarına döner. Mesajlaşma altyapısı, iletileri ilgili abonelere yönlendirir.

• Hataları yalıtıyor. Abone hatası yayımcıyı veya diğer aboneleri etkilemez ve kurtarılan abone bunları işlemeye hazır olana kadar aracı iletileri korur.

• Ertelenmiş veya zamanlanmış işlemeyi destekler. Aboneler yoğun olmayan saatlere kadar iletileri almak için bekleyebilir veya sistem iletileri belirli bir zamanlamaya göre yönlendirebilir veya işleyebilir.

• Farklı platformlar, programlama dilleri ve iletişim protokolleri kullanan sistemler arasında tümleştirmeyi destekler ve ayrıca şirket içi sistemleri bulutta çalışan uygulamalara bağlar.

• Test edilebilirliği artırır. Kanallar izlemeyi destekler ve tümleştirme testi stratejisinin bir parçası olarak iletiler inceleme veya günlüğe kaydetme için kullanılabilir.

• Uygulamalar için endişelerin ayrılmasını sağlar. Mesajlaşma altyapısı iletileri güvenilir bir şekilde birden çok tüketiciye yönlendirmek için gereken işleri gerçekleştirirken her uygulama temel özelliklerine odaklanabilir.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzenin nasıl uygulaneceğine karar velarken aşağıdaki noktaları göz önünde bulundurun:

• Mevcut teknolojiler: Kendi aboneliğinizi oluşturmak yerine yayımlama-abone olma modelini destekleyen mesajlaşma ürünlerini ve hizmetlerini kullanın. Azure'da aşağıdaki hizmetleri göz önünde bulundurun:

  • Azure Service Bus, işlemler, sıralama, oturumlar veya ölü harf kuyrukları gerektiren mesajlaşmalar için.

  • Azure Event Grid özellikle Azure kaynakların durumu değiştiğinde ve abone olunan bileşenleri bilgilendirmesi gerektiğinde olay tabanlı, anında iletme bildirimleri için.

  • Telemetri alımı ve günlük toplama gibi yüksek aktarım hızına sahip olay akışı senaryoları için Azure Event Hubs. Event Hubs, geleneksel pub/sub mesajlaşması yerine günlük tabanlı bir akış modeli kullanır, ancak aynı akışı bağımsız olarak okuyan birden çok tüketici grubunu destekler.

  Daha fazla bilgi için bkz. İletileri teslim eden Azure hizmetleri arasında geçiş yapma. Pub/sub mesajlaşmasını destekleyen diğer teknolojiler Redis, RabbitMQ ve Apache Kafka'dır.

  MassTransit ve NServiceBus gibi kitaplıklar, Service Bus ve diğer mesajlaşma teknolojilerinde yayımla-abone ol modeli için yerleşik destek sağlar.

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

• Güvenlik: Konu temelinde hem yayımcıların hem de abonelerin kimliğini doğrulayın ve yetkilendirilin. İletileri yerleştiren yetkisiz yayımcılar, bir sisteme, bunları okuyan yetkisiz aboneler kadar zarar verebilir. Aktarım sırasında iletileri şifreleyin ve içerik hassassa gizlice dinlemeyi önlemek için aracıda beklerken iletileri şifreleyin.

• İletilerin alt kümeleri: Aboneler genellikle yayımcıdan gelen iletilerin yalnızca bir alt kümesiyle ilgilenir. Mesajlaşma hizmetleri genellikle abonelerin aşağıdaki mekanizmalar aracılığıyla aldıklarını seçmesine 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: Aracı, iletileri içeriğine göre inceler ve dağıtır. Her abone, ihtiyaç duyduğu içeriği belirtebilir.

  Konu ayrıntı düzeyini bilerek seçin. Geniş konuları yönetmek daha kolaydır ancak abonelerin gerekmeyen iletileri filtrelemesini gerektirir. Dar konular abone tarafı filtrelemeyi azaltır, ancak yönetecek konu sayısını artırır. Bazı aracılar, abonelerin her birini numaralandırmadan birden çok konuyu eşleştirmesine olanak tanıyan gibi orders.*joker karakter aboneliklerini destekler.

• Tek yönlü iletişim: Yayımlama-abone olma sistemindeki kanallar tek yönlüdür. Abonenin durumu yayımcıya geri bildirmesi veya onaylaması gerekiyorsa Request-Reply düzenini kullanın. 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.

• İleti sıralama: Abonelerin iletileri alma sırası garanti değildir ve gönderenin bunları oluşturma sırasını yansıtmaz. Sıralama önemliyse, aracı bir bölüm veya oturum içinde sıralı teslimi desteklese de bu ölçeklenebilirliği kısıtlar. Aboneleri, iletileri varış sırasından bağımsız olarak işleyecek şekilde tasarlayın.

• İleti önceliği: Bazı iş yükleri, belirli iletilerin diğerlerinden önce işlenmesini gerektirir. Öncelik Sırası düzeni, daha yüksek öncelikli iletileri düşük öncelikli iletilerden önce yönlendirmek için bir mekanizma sağlar.

• Zehirli iletiler: Hatalı biçimlendirilmiş bir ileti veya kullanılamayan kaynaklara erişim gerektiren bir görev, hizmet örneğinin başarısız olmasına neden olabilir. Analiz için bu ileti ayrıntılarını yakalayın ve başka bir yerde depolayın. Service Bus gibi bazı ileti aracıları ad-letter kuyrukları aracılığıyla bu işlemi destekler.

• İleti boyutu: Aracılar ileti boyutu sınırlarını zorlar. Yük büyük olduğunda, dosya veya görüntü gibi içeriği bir dış veri deposunda depolayın ve iletiye bir başvuru ekleyin. Claim-Check düzeni bu yaklaşımı açıklar.

• Teslim garantileri ve yinelenen iletiler: Mesajlaşma sistemleri farklı teslim garantileri sunar; her garanti belirli tavizler içerir.

  • En çok bir kez teslim, ek yükü en aza indirir, ancak broker veya abone başarısız olursa iletileri kaybedebilir.

  • En az bir kez teslim , ileti teslimini güvence altına alır, ancak gönderen bir iletiyi gönderdikten sonra başarısız olduğunda ve yeni bir örnek gönderiyi yinelediğinde olduğu gibi yinelenen sonuçlara neden olabilir.

  • Tam olarak bir kez teslim yinelenenleri kaldırır, ancak koordinasyon yükü ve gecikme süresi ekler ve erişilebilirliği mesajlaşma altyapısına bağlıdır.

  Brokeriniz çiftlenmeyi önleme sağlamıyorsa, aboneleri iletileri idempotent şekilde işleyecek şekilde tasarlayın. Aynı iş yükündeki farklı aboneler farklı garantiler gerektirebilir.

• İleti süre sonu: Bazı iletilerin kullanım ömrü sınırlıdır. Alıcı bu süre içinde bir iletiyi işlemezse, ileti ilgisiz hale gelir ve sistem bu iletiyi atar. Mesaj verisinde alıcıların işlemeden önce geçerliliğini kontrol edebilmesi için bir son kullanma zaman damgası ayarlayın.

• İleti zamanlama: Belirli bir tarih ve saate kadar ileti ambargoya alınıp işlenmeyebilir. Mesajlaşma sisteminin bu noktaya kadar iletiyi saklaması için bir yayın zaman damgası ayarlayın.

• İleti şemasının evrimi: Yayımcılar ve aboneler bağımsız olarak dağıtılır, bu nedenle ileti şemaları zaman içinde değişir. Mevcut abonelerin çalışmaya devam etmesi için isteğe bağlı alanlar ekleme gibi geriye dönük uyumlu değişiklikleri tercih edin. Kritik değişiklikler için, orders.v1 ve orders.v2 gibi konu adları aracılığıyla veya ileti meta verilerinde bir sürüm alanı kullanarak sürüm oluşturun. Aboneler tanımadıkları alanları yoksaymalıdır.

• Korelasyon: Aracı, yayımcıları abonelerden ayırarak iletinin uçtan uca akışını izlemeyi zorlaştırır. Aboneler ve kayıt sistemlerinin ilgili işlemleri tek bir izlemede bağlayabilmesi için her iletiye bir bağıntı kimliği ekleyin.

• Geri baskı ve ölçeklendirme: Aboneler ayak uyduramadığında, işlenmemiş iletiler aracıda birikir ve kaynaklarını tüketebilir. Her abone için tanınmayan iletileri sınırlamak için aracı akış denetimi ayarlarını kullanın. Yalnızca akış denetimi yeterli olmadığında Rakip Tüketiciler desenini kullanarak abonelerin ölçeğini genişletme.

Bu desen ne zaman kullanılır?

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

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

• Bir uygulamanın bağımsız olarak geliştirilmiş uygulamalar veya hizmetlerle iletişim kurması gerekir. Farklı platformlar, programlama dilleri veya iletişim protokolleri kullanabilirler.

• Bir uygulama, gerçek zamanlı yanıtlara 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, gönderenden farklı kullanılabilirlik gereksinimleri veya çalışma süresi zamanlamaları olan birden çok tüketiciye bilgi iletmesi gerekir.

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

• Bir uygulama, üreten uygulamadan önemli ölçüde farklı bilgilere ihtiyaç duyan yalnızca birkaç tüketiciye sahiptir. Bir komisyoncunun yükü, herhangi bir ölçeklendirme faydası olmadan karmaşıklığı artırır. Doğrudan iletişim veya ayrı kuyruklar daha uygun olabilir.

• Bir uygulama, tüketicilerle neredeyse gerçek zamanlı etkileşim gerektirir. Pub/sub modeli, aracı aracılığıyla gecikme süresi getirir. Yayımcı zaman uyumlu yanıt gerektirdiğinde istek-yanıt deseni kullanın.

• Tüketicilerin iletileri belirli, garantili bir sırayla işlemesi gerekir. Pub/sub sistemleri genellikle aboneler arasında sipariş verme garantisi vermez ve siparişin korunması aracıya ve tüketici tasarımına önemli kısıtlamalar ekler.

• İşlem, yayımcı ve tüketicileri arasında tek bir atomik işlem gerektirir. Pub/sub mesajlaşması doğal olarak asenkron ve nihai olarak tutarlıdır. İşlem garantilerine ihtiyacınız varsa, dağıtılmış işlemleri koordine etmek için doğrudan veritabanı işlemini veya Saga desenini göz önünde bulundurun.

İş yükü tasarımı

Azure Well-Architected Framework sütunları kapsamındaki hedefleri ve ilkeleri ele almak için iş yükünün tasarımında Publisher-Subscriber deseninin nasıl kullanılacağını değerlendirin. Aşağıdaki tabloda, bu desenin her bir sütunun hedeflerini nasıl desteklediği hakkında rehberlik sağlanmaktadır.

Ana Direk	Bu desen sütun hedeflerini nasıl destekler?
Güvenilirlik tasarımı kararları, iş yükünüzün hatalı çalışmaya dayanıklı olmasına ve bir hata oluştuktan sonra tamamen çalışır duruma geldiğinden emin olmasına yardımcı olur.	Bu desen, bağımsız güvenilirlik hedefleri belirleyebilmeniz ve doğrudan bağımlılıkları kaldırabilmeniz için bileşenleri ayırır. - RE:03 Hata modu analizi - RE:07 Arka plan işleri
Güvenlik tasarımı kararları, iş yükünüzün verilerinin ve sistemlerinin gizliliğini, bütünlüğünü ve kullanılabilirliğini sağlamaya yardımcı olur.	Bu düzen, açık bir güvenlik segmentasyonu sınırı sağlar. Kuyruk abonelerini yayımcıdan ağ düzeyinde yalıtmak için kullanın. - SE:04 Segmentlere Ayırma
Maliyet İyileştirme, iş yükünüzün yatırım getirisini (ROI)sürdürmeye ve geliştirmeye odaklanır.	Bu ayrılmış tasarım, tüketim tabanlı faturalama modelleriyle uyumlu olay odaklı mimarileri destekler ve fazla sağlamayı önlemeye yardımcı olur. - CO:05 Hız iyileştirme - CO:12 Ölçeklendirme 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.	Aracı olarak aracı, her iki bileşende de değişiklikleri koordine etmeden yayımcı veya abone tarafında uygulamayı değiştirmenize olanak tanır. - OE:06 İş yükü geliştirme - OE:11 Güvenli dağıtım uygulamaları
Performans Verimliliği , ölçeklendirme, veri ve kod iyileştirmeleri aracılığıyla iş yükünüzün talepleri verimli bir şekilde karşılamasını sağlar.	Yayımcıları tüketicilerden ayırma, her tüketicinin belirli bir ileti türü için işlediği belirli görevler için işlem ve kodu iyileştirmenize olanak tanır. - PE:02 Kapasite planlaması - PE:05 Ölçeklendirme ve bölümleme

Bu model bir sütun içinde dengeleri ortaya çıkartıyorsa, bunları diğer sütunların hedeflerine karşı değerlendirin.

Example

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 üzerinde kurumsal tümleştirme.

En sol tarafta, HTTPS etiketli bir düz ok sağa, istemci uygulamalarından API ağ geçidi simgesine işaret eder. İstemci uygulamaları, kimlik doğrulaması etiketli bir ok aracılığıyla Microsoft Entra ID'ye bağlanır. API ağ geçidinden REST veya basit nesne erişim protokolü (SOAP) web hizmetine doğru işaret eden, HTTPS etiketli düz bir ok. API ağ geçidinin sağındaki iki bölge vardır. İş akışı ve düzenleme etiketli üst orta bölge üç mantıksal uygulama simgesi içerir. Bir mantıksal uygulama simgesinden Service Bus'a doğru bir noktalı ok işareti yöneliyor. Noktalı ok, Service Bus'tan ikinci Logic App simgesine işaret ediyor. Bu mantıksal uygulamadan hizmet olarak yazılım (SaaS) hizmetine HTTPS etiketli düz bir ok işaret ediyor. Etiketsiz bir ok bu satırdan ayrılır ve Azure hizmetine işaret eder. Başka bir noktalı ok, Event Grid'den üçüncü bir mantıksal uygulamaya işaret ediyor. Bu mantıksal uygulamadan SaaS hizmetine doğru HTTPS etiketli katı bir ok yöneliyor. Etiketsiz bir ok bu satırdan ayrılır ve Azure hizmetine işaret eder. Kuyruklar, konular, abonelikler ve olaylar etiketli alt orta bölge, Service Bus ve Event Grid'i içerir. Mesajlar etiketli noktalı bir ok, mesaj tabanlı hizmete işaret eder. En sağ tarafta arka uç sistemleri etiketli bir bölüm üç simge içerir: SaaS hizmeti, Azure hizmetleri ve ileti tabanlı hizmet. Azure hizmetlerinden Event Grid'e "etkinlikler" etiketli noktalı ok. Mesaj tabanlı hizmetten, "gönder" veya "çek" mesajları olarak etiketlenmiş noktalı bir ok, Service Bus'a işaret eder.

Sonraki Adımlar

• Zaman uyumsuz mesajlaşma seçenekleri
• Siparişli teslimata ihtiyacınız yok

İlgili kaynaklar

• Olay temelli mimari stili
• İdempotent ileti işleme
• İleti kuyrukları ve olaylar kullanarak Azure'da kurumsal tümleştirme