Bu makalede, farklı ileti türleri ve mesajlaşma altyapısına katılan varlıklar açıklanmaktadır. Makale, her ileti türünün gereksinimlerine bağlı olarak Azure mesajlaşma hizmetlerini önerir. Seçenekler arasında Azure Service Bus Mesajlaşması, Azure Event Grid ve Azure Event Hubs yer alır. Ürün karşılaştırması için bkz . Mesajlaşma hizmetlerini karşılaştırma.
Mimari düzeyde ileti, diğer varlıkların (tüketicilerin) farkında olabilmesi ve buna göre hareket edebilmesi için bilgileri dağıtmak için bir varlık (üretici) tarafından oluşturulan bir veri birimidir. Üretici ve tüketici, aracı bir varlık (ileti aracısı) aracılığıyla doğrudan veya isteğe bağlı olarak iletişim kurabilir. Bu makale, ileti aracısı kullanan zaman uyumsuz mesajlaşmaya odaklanır.
İletileri iki ana kategoride sınıflandırabiliriz. Üretici tüketiciden bir eylem bekliyorsa, bu ileti bir komut olur. İleti, tüketiciye bir eylemin gerçekleştiğini bildirirse, ileti bir olaydır.
Komutlar
Üretici, tüketicilerin bir iş işlemi kapsamında bir işlem gerçekleştirmesini amaçlayan bir komut gönderir.
Komut yüksek değerli bir iletidir ve en az bir kez teslim edilmelidir. Bir komut kaybolursa, iş işleminin tamamı başarısız olabilir. Ayrıca, bir komut birden çok kez işlenmemelidir. Bunu yapmak hatalı bir işleme neden olabilir. Müşteri yinelenen siparişler alabilir veya iki kez faturalandırılır.
Komutlar genellikle çok adımlı bir iş işleminin iş akışını yönetmek için kullanılır. üretici, iş mantığına bağlı olarak tüketicinin iletiyi kabul etmesini ve işlemin sonuçlarını raporlamasını bekleyebilir. Bu sonuca bağlı olarak, üretici uygun bir eylem kursu seçebilir.
Olaylar
Olay, bir yapımcının olguları duyurmak için yükselttiği ileti türüdür.
Yapımcının (bu bağlamda yayımcı olarak bilinir) olayların herhangi bir eylemle sonuçlanırken hiçbir beklentisi yoktur.
İlgilenen tüketiciler abone olabilir, olayları dinleyebilir ve tüketim senaryolarına bağlı olarak eylemler gerçekleştirebilir. Olayların birden çok abonesi olabilir veya hiç abonesi olamaz. İki farklı abone, bir olaya farklı eylemlerle tepki verebilir ve birbirinden haberdar olamaz.
Üretici ve tüketici gevşek bir şekilde bağlanmış ve bağımsız olarak yönetilmektedir. Üretici, tüketicinin olayı üreticiye geri kabul etmesini beklemez. Olaylarla artık ilgilenmeyen bir tüketici aboneliği kaldırabilir ve bu da üreticiyi veya sistemin genel işlevselliğini etkilemeden tüketiciyi işlem hattından kaldırır.
İki olay kategorisi vardır:
Yapımcı, ayrık olguları duyurmak için olayları yükseltir. Yaygın kullanım örneği olay bildirimidir. Örneğin, Azure Resource Manager kaynakları oluşturduğunda, değiştirdiğinde veya sildiğinde olayları tetikler. Bu olayların abonesi, uyarı e-postaları gönderen bir Mantıksal Uygulama olabilir.
Yapımcı, belirli bir süre boyunca ilgili olayları bir dizide veya bir olay akışında oluşturur. Genellikle bir akış istatistiksel değerlendirme için tüketilir. Değerlendirme, zamansal bir pencerede veya olaylar geldikçe gerçekleşebilir. Telemetri yaygın bir kullanım örneğidir (örneğin, sistem durumu ve yük izleme). Bir diğer durum da IoT cihazlarından olay akışıdır.
Olay mesajlaşmasını uygulamaya yönelik yaygın bir desen, Yayımcı-Abone desenidir.
İleti aracısı rolü ve avantajları
Ara ileti aracısı, iletileri üreticiden tüketiciye taşıma işlevselliği sağlar ve daha fazla avantaj sunabilir.
Ayırma
İleti aracısı, tüketiciden üreticiyi sırasıyla iletileri oluşturan ve kullanan mantıkta ayırıyor. Karmaşık bir iş akışında aracı, iş operasyonlarının ayrıştırılması için teşvik edebilir ve iş akışının koordine edilmesine yardımcı olabilir.
Örneğin, tek bir iş işlemi, bir iş mantığı dizisinde gerçekleştirilen ayrı işlemler gerektirir. Üretici, tüketiciye işlem başlatması için sinyal veren bir komut gönderir. Tüketici, üreticinin yanıtlarını sıralamak için ayrılmış ayrı bir kuyrukta iletiyi kabul eder. Yalnızca yanıt alındıktan sonra üretici, sıradaki bir sonraki işlemi başlatmak için yeni bir ileti gönderir. Farklı bir tüketici bu iletiyi işler ve yanıt kuyruğuna bir tamamlama iletisi gönderir. Hizmetler, mesajlaşmayı kullanarak işlemin iş akışını kendi aralarında koordine eder.
İleti aracısı zamansal ayrıştırma sağlar. Üretici ve tüketicinin eşzamanlı olarak çalışması gerekmez. Üretici, tüketicinin kullanılabilirliğine bakılmaksızın ileti aracısına ileti gönderebilir. Buna karşılık, tüketici üreticinin kullanılabilirliğiyle sınırlı değildir.
Örneğin, bir web uygulamasının kullanıcı arabirimi iletiler oluşturur ve ileti aracısı olarak bir kuyruk kullanır. Tüketici hazır olduğunda, kuyruktan iletileri alabilir ve işi gerçekleştirebilir. Zamansal ayırma, kullanıcı arabiriminin yanıt vermeye devam etmesine yardımcı olur. İletiler zaman uyumsuz olarak işlenirken engellenmez.
Belirli işlemlerin tamamlanması uzun sürebilir. Bir komut verdikten sonra üreticinin tüketici tarafından tamamlanana kadar beklemesi gerekmez. İleti aracısı, iletilerin zaman uyumsuz işlenmesine yardımcı olur.
Yük dengeleme
Üreticiler, birçok tüketici tarafından hizmet veren çok sayıda ileti gönderebilir. İşlemeyi sunucular arasında dağıtmak ve aktarım hızını geliştirmek için bir ileti aracısı kullanın. Tüketiciler yükü yaymak için farklı sunucularda çalışabilir. Tüketiciler gerektiğinde sistemin ölçeğini genişletmek için dinamik olarak eklenebilir veya başka bir şekilde kaldırılabilir.
Rakip Tüketiciler düzeni, aktarım hızını iyileştirmek, ölçeklenebilirliği ve kullanılabilirliği geliştirmek ve iş yükünü dengelemek için birden çok iletiyi eşzamanlı olarak işlemeyi açıklar.
Yük dengeleme
Üretici veya bir üretici grubu tarafından oluşturulan iletilerin hacmi değişken olabilir. Bazen iletilerde ani artışlara neden olan büyük bir birim olabilir. Bir ileti aracısı, bu işi işlemek için tüketici eklemek yerine arabellek görevi görebilir ve tüketiciler sistemi zorlamadan iletileri aşamalı olarak kendi hızlarında tüketebilir.
Kuyruk Tabanlı Yük Dengeleme düzeni daha fazla bilgi sağlar.
Güvenilir mesajlaşma
İleti aracısı, üretici ile tüketici arasındaki iletişim başarısız olsa bile iletilerin kaybolmamasını sağlamaya yardımcı olur. Üretici ileti aracısına ileti gönderebilir ve iletişim yeniden başlatıldığında tüketici bunları alabilir. Üretici, ileti aracısı ile bağlantıyı kaybetmediği sürece engellenmez.
Dayanıklı mesajlaşma
İleti aracısı sisteminizdeki tüketicilere dayanıklılık ekleyebilir. Bir tüketici bir iletiyi işlerken başarısız olursa, tüketicinin başka bir örneği bu iletiyi işleyebilir. İleti aracıda kalıcı olduğundan yeniden işleme mümkündür.
İleti aracısı için teknoloji seçenekleri
Azure, her biri çeşitli özelliklere sahip çeşitli ileti aracısı hizmetleri sağlar. Hizmet seçmeden önce iletinin amacını ve gereksinimlerini belirleyin.
Azure Service Bus Mesajlaşması
Azure Service Bus Mesajlaşma kuyrukları, komutları üreticilerden tüketicilere aktarmak için uygundur. Dikkat edilmesi gereken bazı noktalar aşağıdadır.
Çekme modeli
Service Bus kuyruğunun tüketicisi, yeni iletilerin kullanılabilir olup olmadığını denetlemek için Service Bus'ı sürekli yoklar. Service Bus için istemci SDK'ları ve Azure İşlevleri tetikleyicisi bu modeli özetler. Yeni bir ileti kullanılabilir olduğunda, tüketicinin geri çağırması çağrılır ve ileti tüketiciye gönderilir.
Garantili teslimat
Service Bus, tüketicinin kuyruğa göz atmasını ve diğer tüketicilerden gelen bir iletiyi kilitlemesini sağlar.
İletinin işleme durumunu bildirmek tüketicinin sorumluluğundadır. Yalnızca tüketici iletiyi tüketildi olarak işaretlediğinde Service Bus iletiyi kuyruktan kaldırır. Bir hata, zaman aşımı veya kilitlenme oluşursa, Service Bus iletinin kilidini açar, böylece diğer tüketiciler bu iletiyi alabilir. Bu şekilde ileti aktarımında kaybolmaz.
Yapımcı aynı iletiyi yanlışlıkla iki kez gönderebilir. Örneğin, bir üretici örneği bir ileti gönderdikten sonra başarısız olur. Başka bir üretici özgün örneğin yerini alır ve iletiyi yeniden gönderir. Azure Service Bus kuyrukları, yinelenen iletileri algılayan ve kaldıran yerleşik bir yinelenenleri kaldırma özelliği sağlar. İletinin iki kez teslim edilebilir olması olasılığı hala yüksektir. Örneğin, bir tüketici işleme sırasında başarısız olursa, ileti kuyruğa döndürülür ve aynı veya başka bir tüketici tarafından alınır. Tüketicideki ileti işleme mantığının bir kez etkili olması gerekir, böylece çalışma yineleniyor olsa bile sistemin durumu değiştirilmez.
İleti sıralama
Tüketicilerin iletileri gönderilme sırasına göre almalarını istiyorsanız, Service Bus kuyrukları oturumları kullanarak ilk çıkar (FIFO) sipariş edilen teslimi garanti eder. Oturumda bir veya daha fazla ileti olabilir. İletiler SessionId özelliğiyle ilişkilendirilir. Oturumun parçası olan iletilerin süresi asla dolmaz. Oturum, iletilerinin farklı bir tüketici tarafından işlenmesini önlemek için tüketiciye kilitlenebilir.
Daha fazla bilgi için bkz . İleti oturumları.
İleti kalıcılığı
Service Bus kuyrukları zamansal ayırmayı destekler. Bir tüketici kullanılabilir olmadığında veya iletiyi işleyemediğinde bile kuyrukta kalır.
Denetim noktası uzun süre çalışan işlemler
İş işlemleri uzun süre çalıştırılabilir. İşlemdeki her işlemin birden çok iletisi olabilir. bir işlemin başarısız olması durumunda iş akışını koordine etmek ve dayanıklılık sağlamak için denetim noktası oluşturmayı kullanın.
Service Bus kuyrukları, oturum durumu özelliği aracılığıyla denetim noktası oluşturma olanağı sağlar. Durum bilgileri, bir oturuma ait iletiler için sıraya (SetState) artımlı olarak kaydedilir. Örneğin, bir tüketici durumu (GetState) her zaman ve sonra denetleyerek ilerleme durumunu izleyebilir. Bir tüketici başarısız olursa, başka bir tüketici oturuma devam etmek için bilinen son denetim noktasını belirlemek için durum bilgilerini kullanabilir.
Teslim edilemeyen ileti kuyruğu (DLQ)
Service Bus kuyruğunun teslim edilemeyen veya işlenemeyen iletileri tutmak için teslim edilemeyen ileti kuyruğu (DLQ) olarak adlandırılan varsayılan bir alt sırası vardır. Service Bus veya tüketicideki ileti işleme mantığı DLQ'ya ileti ekleyebilir. DLQ, iletileri kuyruktan alınana kadar saklar.
Aşağıda, bir iletinin DLQ'da ne zaman olabileceğine ilişkin örnekler verilmiştir:
Zehirli ileti, hatalı biçimlendirilmiş veya beklenmeyen bilgiler içerdiği için işlenemediği bir iletidir. Service Bus kuyruklarında, kuyruğun MaxDeliveryCount özelliğini ayarlayarak zehirli iletileri algılayabilirsiniz. Aynı iletinin alınma sayısı bu özellik değerini aşarsa, Service Bus iletiyi DLQ'ya taşır.
İleti bir süre içinde işlenmediyse artık ilgili olmayabilir. Service Bus kuyrukları, üreticinin yaşam süresi özniteliğine sahip iletiler göndermesine olanak sağlar. İleti alınmadan önce bu süre dolarsa, ileti DLQ'ya yerleştirilir.
Hatanın nedenini belirlemek için DLQ'daki iletileri inceleyin.
Karma çözüm
Service Bus, şirket içi sistemlere ve bulut çözümlerine köprü oluşturur. Güvenlik duvarı kısıtlamaları nedeniyle şirket içi sistemlere ulaşmak genellikle zordur. Hem üretici hem de tüketici (şirket içi veya bulut olabilir) iletiler için teslim alma ve bırakma konumu olarak Service Bus kuyruk uç noktasını kullanabilir.
Mesajlaşma Köprüsü düzeni , bu senaryoları işlemenin başka bir yoludur.
Konular ve abonelikler
Service Bus, Service Bus konuları ve abonelikleri aracılığıyla Yayımcı-Abone düzenini destekler.
Bu özellik, yapımcının iletileri birden çok tüketiciye yayınlaması için bir yol sağlar. Bir konu bir ileti aldığında, bu ileti abone olunan tüm tüketicilere iletilir. İsteğe bağlı olarak, aboneliğin tüketicinin iletilerin bir alt kümesini almasına olanak tanıyan filtre ölçütleri olabilir. Her tüketici, abonelikteki iletileri kuyruğa benzer şekilde alır.
Daha fazla bilgi için bkz . Azure Service Bus konuları.
Azure Event Grid
Ayrık olaylar için Azure Event Grid'i öneririz. Event Grid, Yayımcı-Abone desenini izler. Olay kaynakları olayları tetiklediğinde Event Grid konu başlıklarına yayımlanır. Bu olayların tüketicileri, olayları işleyecek olay türlerini ve olay işleyicisini belirterek Event Grid abonelikleri oluşturur. Abone yoksa, olaylar atılır. Her olayın birden çok aboneliği olabilir.
Gönderme Modeli
Event Grid, iletileri bir gönderme modelindeki abonelere yayılır. Web kancası olan bir Event Grid aboneliğiniz olduğunu varsayalım. Yeni bir olay geldiğinde Event Grid olayı web kancası uç noktasına postalar.
Azure ile tümleştirilmiş
Azure kaynakları hakkında bildirim almak istiyorsanız Event Grid'i seçin. Birçok Azure hizmeti, yerleşik Event Grid konularına sahip olay kaynakları olarak görev alır. Event Grid, olay işleyicisi olarak yapılandırılabilir çeşitli Azure hizmetlerini de destekler. Olayları istediğiniz olay işleyicilerine yönlendirmek için bu konulara abone olmak kolaydır. Örneğin, bir blob depolama oluşturulduğunda veya silindiğinde Bir Azure İşlevi çağırmak için Event Grid'i kullanabilirsiniz.
Özel konular
Uygulamanızdan veya Event Grid ile tümleşik olmayan bir Azure hizmetinden olay göndermek istiyorsanız özel Event Grid konuları oluşturun.
Örneğin, bir iş işleminin tamamının ilerleme durumunu görmek için, katılan hizmetlerin kendi iş operasyonlarını işlerken olaylar oluşturmasını istersiniz. Bir web uygulaması bu olayları gösterir. Bu görevi gerçekleştirmenin bir yolu, özel bir konu oluşturmak ve HTTP Web Kancası aracılığıyla kayıtlı web uygulamanızla abonelik eklemektir. İş hizmetleri olayları özel konuya gönderirken, Event Grid bunları web uygulamanıza gönderir.
Filtrelenen olaylar
Event Grid'e olayların yalnızca bir alt kümesini belirli bir olay işleyicisine yönlendirmesini bildirmek için abonelikte filtreler belirtebilirsiniz. Abonelik şemasında filtreleri belirtirsiniz. Konuya filtreyle eşleşen değerlerle gönderilen tüm olaylar otomatik olarak bu aboneliğe iletilir.
Örneğin, çeşitli biçimlerdeki içerik Blob Depolama yüklenir. Bir dosya her eklendiğinde bir olay oluşturulur ve Event Grid'de yayımlanır. Olay aboneliğinde, bir olay işleyicisinin küçük resimler oluşturabilmesi için yalnızca görüntüler için olayları gönderen bir filtre olabilir.
Filtreleme hakkında daha fazla bilgi için bkz . Event Grid için olayları filtreleme.
Yüksek aktarım hızı
Event Grid, bölge başına saniyede 10.000.000 olayı yönlendirebilir. Her ay ilk 100.000 işlem ücretsizdir. Maliyetle ilgili dikkat edilmesi gerekenler için bkz . Event Grid'in maliyeti ne kadardır?
Dayanıklı teslimat
Olaylar için başarılı teslim, komutlar kadar önemli olmasa da, olayın türüne bağlı olarak bazı garantiler isteyebilirsiniz. Event Grid, etkinleştirebileceğiniz ve özelleştirebileceğiniz yeniden deneme ilkeleri, süre sonu süresi ve geçersiz harfleme gibi özellikler sunar. Daha fazla bilgi için bkz . Event Grid ileti teslimi ve yeniden deneme.
Event Grid'in yeniden deneme işlemi dayanıklılığa yardımcı olabilir, ancak başarısızlığa karşı güvenli değildir. Yeniden deneme işleminde Event Grid iletiyi birden çok kez teslim edebilir, uç nokta uzun süre yanıt vermiyorsa bazı yeniden denemeleri atlayabilir veya geciktirebilir. Daha fazla bilgi için bkz . Zamanlamayı yeniden deneme.
Teslim edilmemiş olayları bir blob depolama hesabında kalıcı hale getirmek için teslim edilmeyen iletileri etkinleştirebilirsiniz. İleti blob depolama uç noktasına teslim edilirken gecikme yaşanıyor ve bu uç nokta yanıt vermiyorsa Event Grid olayı atıyor. Daha fazla bilgi için bkz . Teslim edilemeyen harf konumunu ayarlama ve yeniden deneme ilkesi.
Azure Event Hubs
Bir olay akışıyla çalışırken önerilen ileti aracısı Azure Event Hubs'tır . Temelde, düşük gecikme süresiyle büyük hacimli verileri alabilen büyük bir arabellektir. Alınan veriler eşzamanlı işlemler aracılığıyla hızlı bir şekilde okunabilir. Alınan verileri herhangi bir gerçek zamanlı analiz sağlayıcısını kullanarak dönüştürebilirsiniz. Event Hubs, olayları bir depolama hesabında depolama özelliği de sağlar.
Hızlı alım
Event Hubs saniyede milyonlarca olay alabiliyor. Olaylar yalnızca akışa eklenir ve zamana göre sıralanır.
Çekme modeli
Event Grid gibi Event Hubs da Yayımcı-Abone özellikleri sunar. Event Grid ile Event Hubs arasındaki önemli bir fark, olay verilerinin aboneler tarafından kullanılabilir hale getiriliyor olmasıdır. Event Grid alınan verileri abonelere iletirken Event Hubs verileri çekme modelinde kullanılabilir hale getirir. Olaylar alındıkçe Event Hubs bunları akışa ekler. Abone imlecini yönetir ve akışta ileri ve geri gidebilir, bir zaman uzaklığı seçebilir ve bir diziyi kendi hızıyla yeniden oynatabilir.
Akış işlemcileri, dönüştürme ve istatistiksel analiz amacıyla Event Hubs'dan veri çeken abonelerdir. Zaman içinde toplama veya anomali algılama gibi karmaşık işlemler için Azure Stream Analytics ve Apache Spark kullanın.
Bölüm başına her olay üzerinde işlem yapmak istiyorsanız, Olay işlemcisi ana bilgisayarını kullanarak veya dönüştürme mantığını sağlamak için Azure Logic Apps gibi yerleşik bağlayıcıyı kullanarak verileri çekebilirsiniz. Bir diğer seçenek de Azure İşlevleri kullanmaktır.
Bölümleme
Bölüm, olay akışının bir bölümüdür. Olaylar bölüm anahtarı kullanılarak bölünür. Örneğin, birkaç IoT cihazı cihaz verilerini bir olay hub'ına gönderir. Bölüm anahtarı, cihaz tanımlayıcısıdır. Olaylar alındıkçe Event Hubs bunları ayrı bölümlere taşır. Her bölümde tüm olaylar zamana göre sıralanır.
Tüketici, olay verilerini işleyen bir kod örneğidir. Event Hubs bölümlenmiş bir tüketici deseni izler. Her tüketici yalnızca belirli bir bölümü okur. Birden çok bölüme sahip olmak, akışın birden çok tüketici tarafından eşzamanlı olarak okunabilmesi nedeniyle daha hızlı işlemeye neden olur.
Aynı tüketicinin örnekleri tek bir tüketici grubunu oluşturur. Birden çok tüketici grubu aynı akışı farklı niyetlerle okuyabilir. Bir olay akışında sıcaklık algılayıcısından alınan veriler olduğunu varsayalım. Bir tüketici grubu, sıcaklık artışı gibi anomalileri algılamak için akışı okuyabilir. Başka bir akış, zamansal bir pencerede sıralı ortalama sıcaklığı hesaplamak için aynı akışı okuyabilir.
Event Hubs, birden çok tüketici grubuna izin vererek Yayımcı-Abone düzenini destekler. Her tüketici grubu bir abonedir.
Event Hubs bölümleme hakkında daha fazla bilgi için bkz . Bölümler.
Event Hubs Capture
Yakalama özelliği, olay akışını bir Azure Blob depolama alanına veya Data Lake Depolama depolamanıza olanak tanır. Depolama hesabı kullanılamasa bile Capture verilerinizi bir süre saklar ve kullanılabilir olduktan sonra depolama alanına yazar.
Depolama hizmetleri olayları analiz etmek için ek özellikler de sunabilir. Örneğin, blob depolama hesabının erişim katmanlarından yararlanarak, sık erişim gerektiren veriler için olayları sık erişim katmanında depolayabilirsiniz. Bu verileri görselleştirme için kullanabilirsiniz. Alternatif olarak, verileri arşiv katmanında depolayabilir ve denetim amacıyla zaman zaman alabilirsiniz.
Yakalama, Event Hubs tarafından alınan tüm olayları depolar ve toplu işlem için kullanışlıdır. MapReduce işlevini kullanarak veriler üzerinde raporlar oluşturabilirsiniz. Yakalanan veriler, gerçeğin kaynağı olarak da görev yapabilir. Veriler toplanırken bazı olgular yanıtsız kaldıysa, yakalanan verilere başvurabilirsiniz.
Bu özellik hakkında ayrıntılı bilgi için bkz. Azure Blob Depolama veya Azure Data Lake Depolama'da Azure Event Hubs aracılığıyla olayları yakalama.
Apache Kafka istemcileri için destek
Event Hubs, Apache Kafka istemcileri için bir uç nokta sağlar. Mevcut istemciler, yapılandırmalarını uç noktaya işaret edip Event Hubs'a olay göndermeye başlayacak şekilde güncelleştirebilir. Kod değişikliği yapmanız gerekmez.
Daha fazla bilgi için bkz . Apache Kafka için Event Hubs.
Çapraz geçiş senaryoları
Bazı durumlarda, iki mesajlaşma hizmetini birleştirmek avantajlıdır.
Hizmetleri birleştirmek, mesajlaşma sisteminizin verimliliğini artırabilir. Örneğin, iş işleminizde iletileri işlemek için Azure Service Bus kuyruklarını kullanırsınız. Tüketici yeni iletiler için kuyruğu sürekli yokladığı için çoğunlukla boşta olan ve bazen ileti alan kuyruklar verimsizdir. Olay işleyicisi olarak Azure İşlevi ile event Grid aboneliği ayarlayabilirsiniz. Kuyruk her ileti aldığında ve dinleyen tüketici olmadığında Event Grid, kuyruğu boşaltan Azure İşlevini çağıran bir bildirim gönderir.
Service Bus'ı Event Grid'e bağlama hakkında ayrıntılı bilgi için bkz . Azure Service Bus to Event Grid tümleştirmesine genel bakış.
İleti kuyruklarını ve olay başvuru mimarisini kullanan Kurumsal tümleştirme, Service Bus to Event Grid tümleştirmesinin bir uygulamasını gösterir.
Burada başka bir örnek verilmiştir: Event Grid, bazı olayların bir iş akışı gerektirdiği, bazıları ise bildirim için olduğu bir dizi olay alır. İleti meta verileri olayın türünü gösterir. Ayırt etmenin bir yolu, olay aboneliğindeki filtreleme özelliğini kullanarak meta verileri denetlemektir. Bir iş akışı gerektiriyorsa Event Grid bunu Azure Service Bus kuyruğuna gönderir. Bu kuyruğun alıcıları gerekli eylemleri gerçekleştirebilir. Bildirim olayları uyarı e-postaları göndermek için Logic Apps'e gönderilir.
İlgili düzenler
Zaman uyumsuz mesajlaşma uygularken şu desenleri göz önünde bulundurun:
- Rakip Tüketiciler düzeni. Bir kuyruktan gelen iletileri okumak için birden çok tüketicinin rekabete sahip olması gerekebilir. Bu düzende aktarım hızını iyileştirmek, ölçeklenebilirliği ve kullanılabilirliği iyileştirmek ve iş yükünü dengelemek için birden çok iletinin eşzamanlı olarak nasıl işlendiği açıklanır.
- Öncelikli Kuyruk düzeni. İş mantığının bazı iletilerin diğerlerinden önce işlenmesini gerektirdiği durumlarda, bu desen, daha yüksek önceliğe sahip bir üretici tarafından gönderilen iletilerin tüketici tarafından daha düşük öncelikli iletilere göre nasıl daha hızlı alındığını ve işlendiğini açıklar.
- Kuyruk Tabanlı Yük Dengeleme düzeni. Bu düzen, her iki varlık için de aralıklı ağır yüklerin kullanılabilirliği ve yanıt verme hızı üzerindeki etkisini en aza indirmeye yardımcı olmak üzere bir üretici ile tüketici arasında arabellek görevi gören bir ileti aracısı kullanır.
- Yeniden deneme düzeni. Üretici veya tüketici kuyruğa bağlanamayabilir, ancak bu hatanın nedenleri geçici ve hızlı bir şekilde geçebilir. Bu desen, bir uygulamaya dayanıklılık eklemek için bu durumun nasıl işleneceğini açıklar.
- Zamanlayıcı Aracısı Gözetmen düzeni. Mesajlaşma genellikle bir iş akışı uygulamasının parçası olarak kullanılır. Bu düzende, mesajlaşmanın dağıtılmış bir hizmet kümesi ve diğer uzak kaynaklar arasında bir dizi eylemi koordine edebilmesi ve sistemin başarısız olan eylemleri kurtarıp yeniden denemesine nasıl olanak tanıyabileceği gösterilmektedir.
- Koreografi düzeni. Bu düzen, hizmetlerin bir iş işleminin iş akışını denetlemek için mesajlaşmayı nasıl kullanabileceğini gösterir.
- Talep-Denetim düzeni. Bu düzen, büyük bir iletinin talep denetimine ve yüke nasıl bölündüğünü gösterir.
Topluluk kaynakları
Jonathon Oliver'ın blog gönderisi: Idempotency
Martin Fowler'ın blog gönderisi: "Event-Driven" ile ne demek istiyorsunuz?