Hizmet-hizmet iletişimi

İpucu

Bu içerik, .NET Docs'ta veya çevrimdışı olarak okunabilen ücretsiz indirilebilir bir PDF olarak sağlanan Azure için Buluta Özel .NET Uygulamaları Tasarlama adlı e-Kitap'tan bir alıntıdır.

PDF'i indirin

Ön uç istemcisinden hareketle artık arka uç mikro hizmetlerinin birbirleriyle iletişim kurmasını ele alıyoruz.

Bulutta yerel bir uygulama oluştururken arka uç hizmetlerinin birbirleriyle nasıl iletişim kuracağı konusunda hassas olmanız gerekir. İdeal olarak, ne kadar az hizmet arası iletişim, o kadar iyi. Ancak, arka uç hizmetleri bir işlemi tamamlamak için genellikle birbirine bağlı olduğundan kaçınma her zaman mümkün değildir.

Hizmetler arası iletişim uygulamak için yaygın olarak kabul edilen birkaç yaklaşım vardır. İletişim etkileşimi türü genellikle en iyi yaklaşımı belirler.

Aşağıdaki etkileşim türlerini göz önünde bulundurun:

• Sorgu – çağrılan bir mikro hizmet, "Hey, bana belirli bir müşteri kimliği için alıcı bilgilerini ver" gibi bir çağrı mikro hizmetten yanıt gerektirdiğinde.

• Command : Çağıran mikro hizmetin bir eylemi yürütmek için başka bir mikro hizmete ihtiyacı olduğunda ancak "Hey, yalnızca bu siparişi gönder" gibi bir yanıt gerektirmediğinde.

• Olay – yayımcı olarak adlandırılan bir mikro hizmet, durumun değiştiği veya bir eylem gerçekleştiğinde bir olay tetikler. İlgilenen aboneler olarak adlandırılan diğer mikro hizmetler olaya uygun şekilde tepki verebilir. Yayımcı ve aboneler birbirinin farkında değildir.

Mikro hizmet sistemleri genellikle hizmetler arası etkileşim gerektiren işlemleri yürütürken bu etkileşim türlerinin bir bileşimini kullanır. Şimdi her birine ve bunları nasıl uygulayabileceğinize yakından bakalım.

Sorgular

Çoğu zaman, bir mikro hizmetin başka bir hizmeti sorgulaması gerekebilir ve bir işlemi tamamlamak için anında yanıt verilmesi gerekebilir. Alışveriş sepeti mikro hizmeti, sepetine bir ürün eklemek için ürün bilgilerine ve bir fiyata ihtiyaç duyabilir. Sorgu işlemlerini uygulamak için birçok yaklaşım vardır.

İstek/Yanıt İletisi

Bu senaryoyu uygulamak için bir seçenek, arka uç mikro hizmetini çağırarak sorgulaması gereken mikro hizmetlere doğrudan HTTP istekleri göndermektir ve Şekil 4-8'de gösterilmiştir.

Şekil 4-8. Doğrudan HTTP iletişimi

Mikro hizmetler arasındaki doğrudan HTTP çağrılarının uygulanması nispeten basit olsa da, bu uygulamayı en aza indirmek için dikkatli olunmalıdır. Başlamak için, bu çağrılar her zaman zaman zaman uyumlu olur ve sonuç döndürülene veya istek zaman aşımına gelene kadar işlemi engeller. Bir zamanlar bağımsız olarak gelişen ve sık sık dağıtım yapabilen bağımsız, bağımsız hizmetler artık birbirine bağlı hale geldi. Mikro hizmetler arasındaki bağlantı arttıkça mimari avantajları azalır.

Başka bir mikro hizmete tek bir doğrudan HTTP çağrısı yapan seyrek bir isteğin yürütülmesi bazı sistemler için kabul edilebilir olabilir. Ancak, birden çok mikro hizmete doğrudan HTTP çağrıları çağıran yüksek hacimli çağrılar önerilmez. Gecikme süresini artırabilir ve sisteminizin performansını, ölçeklenebilirliğini ve kullanılabilirliğini olumsuz etkileyebilir. Daha da kötüsü, uzun bir doğrudan HTTP iletişimi serisi, Şekil 4-9'da gösterilen zaman uyumlu mikro hizmet çağrılarının derin ve karmaşık zincirlerine yol açabilir:

Şekil 4-9. HTTP sorgularını zincirleme

Önceki görüntüde gösterilen tasarımdaki riski kesinlikle hayal edebilirsiniz. 3. Adım başarısız olursa ne olur? Yoksa 8. adım başarısız mı oluyor? Nasıl kurtarılır? Temel alınan hizmet meşgul olduğu için 6. Adım yavaşsa ne olur? Nasıl devam edebilirsiniz? Her şey düzgün çalışsa bile, her adımın gecikme süresinin toplamı olan bu çağrının neden olacağı gecikme süresini düşünün.

Önceki görüntüdeki büyük düzeydeki bağlantı, hizmetlerin en uygun şekilde modellenmediğini gösteriyor. Ekibin tasarımını yeniden gözden geçirmesi gerekir.

Gerçekleştirilmiş Görünüm düzeni

Mikro hizmet bağlamasını kaldırmaya yönelik popüler bir seçenek, Gerçekleştirilmiş Görünüm desenidir. Bu düzende bir mikro hizmet, diğer hizmetlere ait verilerin kendi yerel, normal dışılaştırılmış kopyasını depolar. Ürün Kataloğu ve Fiyatlandırma mikro hizmetlerini sorgulayan Alışveriş Sepeti mikro hizmeti yerine, bu verilerin kendi yerel kopyasını tutar. Bu desen gereksiz bağlamayı ortadan kaldırır ve güvenilirliği ve yanıt süresini artırır. İşlemin tamamı tek bir işlem içinde yürütülür. Bu düzeni ve diğer veri endişelerini Bölüm 5'te inceleyeceğiz.

Hizmet Toplayıcı Düzeni

Mikro hizmetten mikro hizmete bağlamayı ortadan kaldırmaya yönelik bir diğer seçenek de Şekil 4-10'da mor renkle gösterilen toplayıcı mikro hizmetidir.

Şekil 4-10. Toplayıcı mikro hizmeti

Desen, birden çok arka uç mikro hizmetine çağrı yapan bir işlemi yalıtarak mantığını özel bir mikro hizmette merkezileştirir. Önceki şekildeki mor kullanıma alma toplayıcısı mikro hizmeti, Kullanıma Alma işlemi için iş akışını düzenler. Birkaç arka uç mikro hizmetini sıralı bir sırayla çağırmayı içerir. İş akışındaki veriler toplanır ve arayana döndürülür. Toplayıcı mikro hizmeti, doğrudan HTTP çağrılarını uygulamaya devam ederken arka uç mikro hizmetleri arasındaki doğrudan bağımlılıkları azaltır.

İstek/Yanıt Deseni

Zaman uyumlu HTTP iletilerini ayırmaya yönelik bir diğer yaklaşım, kuyruğa alma iletişimi kullanan bir İstek-Yanıt Desenidir. Kuyruk kullanan iletişim her zaman tek yönlü bir kanaldır ve üretici iletiyi gönderirken tüketici de bu iletiyi alır. Bu desenle, Şekil 4-11'de gösterilen hem istek kuyruğu hem de yanıt kuyruğu uygulanır.

Şekil 4-11. İstek-yanıt deseni

Burada, ileti üreticisi benzersiz bir bağıntı kimliği içeren sorgu tabanlı bir ileti oluşturur ve bunu bir istek kuyruğuna yerleştirir. Tüketen hizmet iletileri sıralar, işler ve yanıtı aynı bağıntı kimliğiyle yanıt kuyruğuna yerleştirir. Üretici hizmeti iletiyi sıralar, bağıntı kimliğiyle eşleştirir ve işlemeye devam eder. Sonraki bölümde kuyrukları ayrıntılı olarak ele alacağız.

Komutlar

Başka bir iletişim etkileşimi türü de bir komutdur. Bir mikro hizmetin eylem gerçekleştirmek için başka bir mikro hizmete ihtiyacı olabilir. Sipariş mikro hizmeti, onaylanan bir sipariş için sevkiyat oluşturmak için Sevkiyat mikro hizmeti gerekebilir. Şekil 4-12'de Üretici adlı bir mikro hizmet, başka bir mikro hizmete (Tüketici) bir ileti göndererek bir şey yapması için komut gönderir.

Şekil 4-12. Kuyrukla komut etkileşimi

Çoğu zaman, Yapımcı bir yanıt gerektirmez ve iletiyi tetikleyebilir ve unutabilir. Yanıt gerekirse, Tüketici başka bir kanaldaki Üreticiye ayrı bir ileti gönderir. Komut iletisi en iyi şekilde bir ileti kuyruğuyla zaman uyumsuz olarak gönderilir. basit bir ileti aracısı tarafından desteklenir. Önceki diyagramda kuyruğun her iki hizmeti de nasıl ayırıp ayırıyor olduğunu not edin.

İleti kuyruğu, üreticinin ve tüketicinin ileti geçirmesi için aracı bir yapıdır. Kuyruklar zaman uyumsuz, noktadan noktaya mesajlaşma düzeni uygular. Üretici, bir komutun nereye gönderilmesi gerektiğini bilir ve uygun şekilde yönlendirir. Kuyruk, bir iletinin kanaldan okuyan tüketici örneklerinden biri tarafından işlenmesini garanti eder. Bu senaryoda, üretici veya tüketici hizmeti diğerini etkilemeden ölçeği genişletebilir. Teknolojiler her iki taraftan da ayrı olabilir, yani Golang mikro hizmetini çağıran bir Java mikro hizmetimiz olabilir.

1. bölümde, yedekleme hizmetleri hakkında konuştuk. Yedekleme hizmetleri, bulutta yerel sistemlerin bağımlı olduğu yardımcı kaynaklardır. İleti kuyrukları hizmetleri destekler. Azure bulutu, buluta özel sistemlerinizin komut mesajlaşması uygulamak için kullanabileceği iki tür ileti kuyruğu destekler: Azure Depolama Kuyrukları ve Azure Service Bus Kuyrukları.

Azure Depolama Kuyrukları

Azure depolama kuyrukları hızlı, uygun fiyatlı ve Azure depolama hesapları tarafından yedeklenen basit bir kuyruk altyapısı sunar.

Azure Depolama Kuyrukları, güvenilir ve kalıcı mesajlaşmaya sahip REST tabanlı bir kuyruğa alma mekanizmasına sahiptir. Çok az özellik kümesi sağlar, ancak ucuzdur ve milyonlarca iletiyi depolar. Kapasiteleri 500 TB'a kadar değişir. Tek bir iletinin boyutu en fazla 64 KB olabilir.

HTTP veya HTTPS kullanarak kimliği doğrulanmış çağrılar aracılığıyla dünyanın herhangi bir yerinden iletilere erişebilirsiniz. Depolama kuyrukları, trafik artışlarını işlemek için çok sayıda eşzamanlı istemciye ölçeklendirilebilir.

Bununla birlikte, hizmetle ilgili sınırlamalar vardır:

• İleti sırası garanti değildir.

• İleti otomatik olarak kaldırılmadan önce yalnızca yedi gün kalıcı olabilir.

• Durum yönetimi, yinelenen algılama veya işlemler için destek kullanılamaz.

Şekil 4-13,Azure Depolama Kuyruğu hiyerarşisini gösterir.

Şekil 4-13. kuyruk hiyerarşisi Depolama

Önceki şekilde, depolama kuyruklarının iletilerini temel alınan Azure Depolama hesabında nasıl depoladıklarına dikkat edin.

Geliştiriciler için Microsoft, Depolama kuyruğu işleme için çeşitli istemci ve sunucu tarafı kitaplıkları sağlar. .NET, Java, JavaScript, Ruby, Python ve Go gibi çoğu ana platform desteklenir. Geliştiriciler bu kitaplıklarla hiçbir zaman doğrudan iletişim kurmamalıdır. Bunu yaptığınızda mikro hizmet kodunuz Azure Depolama Kuyruk hizmetiyle sıkı bir şekilde birleştirilir. API'nin uygulama ayrıntılarını yalıtmak daha iyi bir uygulamadır. Genel işlemleri kullanıma sunan ve somut kitaplığı kapsülleyen bir aracı katmanı veya ara API tanıtın. Bu gevşek bağlantı, ana hat hizmet kodunda değişiklik yapmanıza gerek kalmadan bir kuyruğa alma hizmetini başka bir kuyruğa alma hizmetiyle değiştirmenizi sağlar.

Azure Depolama kuyrukları, buluta özel uygulamalarınızda komut mesajlaşması uygulamak için ekonomik bir seçenektir. Özellikle kuyruk boyutu 80 GB'ı aşacaksa veya basit bir özellik kümesi kabul edilebilir olduğunda. Yalnızca iletilerin depolanması için ödeme alırsınız; sabit saatlik ücret yoktur.

Azure Service Bus Kuyrukları

Daha karmaşık mesajlaşma gereksinimleri için Azure Service Bus kuyruklarını göz önünde bulundurun.

Güçlü bir ileti altyapısının üzerinde duran Azure Service Bus, aracılı mesajlaşma modelini destekler. İletiler, tüketici tarafından alınana kadar güvenilir bir şekilde bir aracıda (kuyrukta) depolanır. Kuyruk, iletilerin kuyruğa eklenme sırasına göre İlk Gelen/İlk Çıkan (FIFO) ileti teslimini garanti eder.

İletinin boyutu 256 KB'a kadar çok daha büyük olabilir. İletiler kuyrukta sınırsız süre boyunca kalıcı hale gelir. Service Bus yalnızca HTTP tabanlı çağrıları desteklemez, aynı zamanda AMQP protokolü için tam destek sağlar. AMQP, ikili protokolü ve daha yüksek güvenilirlik derecelerini destekleyen satıcılar arasında açık standarttır.

Service Bus, işlem desteği ve yinelenen algılama özelliği de dahil olmak üzere zengin bir özellik kümesi sağlar. Kuyruk, ileti başına "en fazla bir kez teslim" garantisi sunar. Zaten gönderilmiş bir iletiyi otomatik olarak atar. Üretici şüpheliyse aynı iletiyi yeniden gönderebiliyor ve Service Bus yalnızca bir kopyanın işlendiğini garanti ediyor. Yinelenen algılama, ek altyapı tesisatı oluşturmanıza gerek kalmadan sizi serbest bıraktı.

Bölümleme ve oturumlar iki kurumsal özellik daha vardır. Geleneksel bir Service Bus kuyruğu tek bir ileti aracısı tarafından işlenir ve tek bir ileti deposunda depolanır. Ancak Service Bus Bölümleme, kuyruğu birden çok ileti aracısı ve ileti deposuna dağıtır. Genel aktarım hızı artık tek bir ileti aracısı veya mesajlaşma deposunun performansıyla sınırlı değildir. Mesajlaşma deposunda geçici bir kesinti, bölümlenmiş bir kuyruğu kullanılamaz duruma getirmiyor.

Service Bus Oturumları , grupla ilgili iletileri gruplandırmak için bir yol sağlar. İletilerin birlikte işlenmesi ve işlemin sonunda tamamlanması gereken bir iş akışı senaryosu düşünün. Bundan yararlanmak için, oturumların kuyruk için açıkça etkinleştirilmesi ve iletilen her ilgili oturum kimliğinin aynı oturum kimliğini içermesi gerekir.

Ancak bazı önemli uyarılar vardır: Service Bus kuyruklarının boyutu 80 GB ile sınırlıdır ve bu, mağaza kuyruklarından sağlanandan çok daha küçüktür. Ayrıca Service Bus kuyruklarında işlem başına temel maliyet ve ücret uygulanır.

Şekil 4-14, Service Bus kuyruğunun üst düzey mimarisini özetler.

Şekil 4-14. Service Bus kuyruğu

Önceki şekilde noktadan noktaya ilişkiyi not edin. Aynı sağlayıcının iki örneği, iletileri tek bir Service Bus kuyruğunda sıraya alır. Her ileti, sağdaki üç tüketici örneğinden yalnızca biri tarafından tüketilir. Ardından, farklı tüketicilerin aynı iletiyle ilgilenebileceği mesajlaşmayı nasıl uygulayabileceğinizi tartışacağız.

Ekinlikler

İleti kuyruğa alma, üreticinin bir tüketiciye zaman uyumsuz olarak ileti gönderebildiği iletişimi uygulamanın etkili bir yoludur. Ancak, birçok farklı tüketici aynı iletiyle ilgilendiğinde ne olur? Her tüketici için ayrılmış bir ileti kuyruğu iyi ölçeklendirilemez ve yönetilmesi zorlaşır.

Bu senaryoyu ele almak için üçüncü ileti etkileşimi türü olan olaya geçeriz. Bir mikro hizmet, bir eylemin gerçekleştiğini duyurur. İlgilenirse diğer mikro hizmetler eyleme veya olaya tepki gösterir. Bu, olay odaklı mimari stili olarak da bilinir.

Olay oluşturma iki adımlı bir işlemdir. Belirli bir durum değişikliği için mikro hizmet, bir olayı bir ileti aracısına yayımlayarak ilgili diğer mikro hizmetlerin kullanımına açar. İlgili mikro hizmet, ileti aracısında olaya abone olarak bildirilir. Olay tabanlı iletişim uygulamak için Yayımla/Abone Ol desenini kullanırsınız.

Şekil 4-15'de, bir alışveriş sepeti mikro hizmetinin, buna abone olan diğer iki mikro hizmetle birlikte bir olay yayımlaması gösterilmektedir.

Şekil 4-15. Olay Odaklı mesajlaşma

İletişim kanalının ortasında yer alan olay veri yolu bileşenini not edin. İleti aracısını kapsülleyen ve temel alınan uygulamadan ayıran özel bir sınıftır. Sipariş ve envanter mikro hizmetleri, olayı birbirinden veya alışveriş sepeti mikro hizmeti hakkında hiçbir bilgi olmadan bağımsız olarak çalıştırır. Kayıtlı olay olay veri yolu üzerinde yayımlandığında, olay üzerinde işlem yaparlar.

Olay oluşturma ile kuyruğa alma teknolojisinden konulara geçeriz. Konu , kuyruğa benzer, ancak bire çok mesajlaşma düzenini destekler. Bir mikro hizmet bir ileti yayımlar. Birden çok abone mikro hizmet bu iletiyi almayı ve bu ileti üzerinde işlem yapmayı seçebilir. Şekil 4-16'da konu mimarisi gösterilmektedir.

Şekil 4-16. Konu mimarisi

Önceki şekilde, yayımcılar konuya ileti gönderir. Sonunda aboneler aboneliklerden iletiler alır. Ortada, konu başlığı koyu mavi kutularla gösterilen bir dizi kurala göre iletileri aboneliklere iletir. Kurallar, belirli iletileri aboneliğe ileden bir filtre görevi görür. Burada, günlük aboneliği tüm iletileri almayı seçtiğinden fiyat ve günlük aboneliklerine bir "GetPrice" olayı gönderilir. Bilgilere ve günlüğe kaydetme aboneliklerine bir "GetInformation" olayı gönderilir.

Azure bulutu iki farklı konu hizmetini destekler: Azure Service Bus Konuları ve Azure EventGrid.

Azure Service Bus Konuları

Azure Service Bus kuyruklarının aynı güçlü aracılı ileti modelinin üzerinde yer alan Azure Service Bus Konuları' dır. Bir konu birden çok bağımsız yayımcıdan ileti alabilir ve 2.000 aboneye kadar ileti gönderebilir. Abonelikler, sistemi durdurmadan veya konuyu yeniden oluşturmadan çalışma zamanında dinamik olarak eklenebilir veya kaldırılabilir.

Yinelenen Algılama ve İşlem desteği gibi konular için Azure Service Bus kuyruklarından birçok gelişmiş özellik de kullanılabilir. Varsayılan olarak, Service Bus konuları tek bir ileti aracısı tarafından işlenir ve tek bir ileti deposunda depolanır. Ancak Service Bus Bölümleme, bir konuyu birçok ileti aracısı ve ileti deposuna dağıtarak ölçeklendirir.

Zamanlanan İleti Teslimi , işleme için belirli bir zamana sahip bir iletiyi etiketler. İleti bu saatten önce konu başlığında görünmez. İleti Erteleme , bir iletinin alınmasını daha sonra ertelemenizi sağlar. her ikisi de genellikle işlemlerin belirli bir sırada işlendiği iş akışı işleme senaryolarında kullanılır. Önceki çalışma tamamlanana kadar alınan iletilerin işlenmesini erteleyebilirsiniz.

Service Bus konuları, buluta özel sistemlerinizde yayımlama/abone olma iletişimini etkinleştirmeye yönelik sağlam ve kanıtlanmış bir teknolojidir.

Azure Event Grid

Azure Service Bus, tüm kurumsal özelliklere sahip, savaş testli bir mesajlaşma aracısı olsa da, bloktaki yeni çocuk Azure Event Grid'dir .

Event Grid ilk bakışta başka bir konu tabanlı mesajlaşma sistemi gibi görünebilir. Ancak, birçok yönden farklıdır. Olay odaklı iş yüklerine odaklanan bu hizmet, gerçek zamanlı olay işleme, derin Azure tümleştirmesi ve açık bir platform sağlar. Bunların tümü sunucusuz altyapıya dayanır. Çağdaş buluta özel ve sunucusuz uygulamalar için tasarlanmıştır

Merkezi bir olay arka planı veya kanal olarak Event Grid, Azure kaynakları içindeki ve kendi hizmetlerinizdeki olaylara tepki gösterir.

Olay bildirimleri, her olayı aboneliğe yönlendiren bir Event Grid Konusuna yayımlanır. Aboneler aboneliklerle eşler ve olayları tüketir. Service Bus gibi Event Grid de aboneliğin almak istediği olaylar için kural ayarladığı filtrelenmiş abone modelini destekler. Event Grid, saniyede 10 milyon olay garantisiyle hızlı aktarım hızı sağlayarak Azure Service Bus'ın üretecinden çok daha fazla gerçek zamanlı teslim sağlar.

Event Grid için tatlı bir nokta, Azure altyapısının dokusuyla derin tümleştirmesidir. Cosmos DB gibi bir Azure kaynağı, özel koda gerek kalmadan yerleşik olayları doğrudan diğer ilgili Azure kaynaklarına yayımlayabilir. Event Grid bir Azure Aboneliğinden, Kaynak Grubundan veya Hizmetten olaylar yayımlayabilir ve geliştiricilere bulut kaynaklarının yaşam döngüsü üzerinde ayrıntılı denetim sağlar. Ancak Event Grid, Azure ile sınırlı değildir. Uygulamalardan veya üçüncü taraf hizmetlerden yayımlanan özel HTTP olaylarını kullanabilen ve olayları dış abonelere yönlendirebilen açık bir platform.

Azure kaynaklarından yerel olaylar yayımlanırken ve bu olaylara abone olunduğunda kodlama gerekmez. Basit yapılandırmayla, Konular ve Abonelikler için yerleşik tesisattan yararlanarak bir Azure kaynağındaki olayları başka bir Azure kaynağıyla tümleştirebilirsiniz. Şekil 4-17'de Event Grid'in anatomisi gösterilmektedir.

Şekil 4-17. Event Grid anatomisi

EventGrid ile Service Bus arasındaki en önemli fark, temel alınan ileti değişimi düzenidir.

Service Bus, aşağı akış abonesinin yeni iletiler için konu aboneliğini etkin bir şekilde yokladığı eski bir stil çekme modeli uygular. Bu yaklaşım, aboneye iletileri işleme hızı üzerinde tam denetim sağlar. Herhangi bir zamanda ne zaman ve kaç iletinin işlenmek üzere olduğunu denetler. Okunmamış iletiler işlenene kadar abonelikte kalır. Önemli bir eksiklik, olayın oluşturulduğu zaman ile bu iletiyi işlenmek üzere aboneye çeken yoklama işlemi arasındaki gecikme süresidir. Ayrıca, bir sonraki olay için sürekli yoklama yükü kaynakları ve parayı tüketir.

Ancak EventGrid farklıdır. Olayların eventHandlers'a alınan şekilde gönderildiği ve neredeyse gerçek zamanlı olay teslimi sağlayan bir gönderme modeli uygular. Ayrıca, hizmet yalnızca bir olayı tüketmesi gerektiğinde tetiklendiğinden maliyeti azaltır; yoklamada olduğu gibi sürekli olarak değil. Bununla birlikte, bir olay işleyicisi gelen yükü işlemeli ve kendini bunalmaya karşı korumak için azaltma mekanizmaları sağlamalıdır. Azure İşlevleri ve Logic Apps gibi bu olayları kullanan birçok Azure hizmeti, artan yükleri işlemek için otomatik otomatik ölçeklendirme özellikleri sağlar.

Event Grid, tam olarak yönetilen sunucusuz bir bulut hizmetidir. Trafiğinize göre dinamik olarak ölçeklendirilir ve önceden satın alınan kapasite için değil yalnızca gerçek kullanımınız için ücretlendirilir. Ayda ilk 100.000 işlem ücretsizdir: olay girişi (gelen olay bildirimleri), abonelik teslim denemeleri, yönetim çağrıları ve konuya göre filtreleme olarak tanımlanan işlemler. %99,99 kullanılabilirlik ile EventGrid, başarısız teslim için yerleşik yeniden deneme işleviyle 24 saatlik bir süre içinde bir olayın teslimini garanti eder. Teslim edilmemiş iletiler çözüm için "teslim edilemeyen" bir kuyruğa taşınabilir. Azure Service Bus'ın aksine Event Grid hızlı performans için ayarlanmıştır ve sıralı mesajlaşma, işlemler ve oturumlar gibi özellikleri desteklemez.

Azure bulutunda iletileri akışla aktarma

Azure Service Bus ve Event Grid, Cosmos DB'ye yeni bir belge eklenmiş gibi tek ve ayrı olayları kullanıma sunan uygulamalar için harika destek sağlar. Ancak buluta özel sisteminizin ilgili olayların akışını işlemesi gerekiyorsa ne olur? Olay akışları daha karmaşıktır. Bunlar genellikle zaman sıralı, birbiriyle ilişkilidir ve grup olarak işlenmelidir.

Azure Event Hub , olayları toplayan, dönüştüren ve depolayan bir veri akışı platformu ve olay alımı hizmetidir. Telemetri bağlamından yayılan sürekli olay bildirimleri gibi akış verilerini yakalamak için ince ayarlıdır. Hizmet yüksek oranda ölçeklenebilir ve saniyede milyonlarca olayı depolayabilir ve işleyebilir. Şekil 4-18'de gösterilen bu, genellikle bir olay işlem hattı için ön kapıdır ve alma akışını olay tüketiminden ayırır.

Şekil 4-18. Azure Event Hub

Event Hub düşük gecikme süresini ve yapılandırılabilir zaman saklamayı destekler. Event Hubs, kuyruklardan ve konu başlıklarından farklı olarak olay verilerini tüketici tarafından okunduktan sonra saklar. Bu özellik, hem iç hem de dış diğer veri analizi hizmetlerinin daha fazla analiz için verileri yeniden yürütmesini sağlar. Olay hub'ında depolanan olaylar yalnızca saklama süresi sona erdiğinde silinir. Bu, varsayılan olarak bir gündür ancak yapılandırılabilir.

Event Hub, HTTPS ve AMQP gibi yaygın olay yayımlama protokollerini destekler. Ayrıca Kafka 1.0'a da destek olur. Mevcut Kafka uygulamaları, büyük Kafka kümelerini yönetmeye alternatif olarak Kafka protokolunu kullanarak Olay Hub'ı ile iletişim kurabilir. Birçok açık kaynak bulutta yerel sistem Kafka'ya sahiptir.

Event Hubs, her tüketicinin ileti akışının yalnızca belirli bir alt kümesini veya bölümünü okuduğu bölümlenmiş bir tüketici modeli aracılığıyla ileti akışı uygular. Bu düzen, olay işleme için muazzam yatay ölçek sağlar ve kuyruklarda ve konu başlıklarında kullanılamayan akış odaklı diğer özellikler sağlar. Bölüm bir olay hub'ında tutulan olayların sıralı dizisidir. Yeni olaylar geldikçe bu dizinin sonuna eklenir. Şekil 4-19'da bir Olay Hub'ında bölümleme gösterilmektedir.

Şekil 4-19. Olay Hub'ı bölümleme

Her tüketici grubu, aynı kaynaktan okumak yerine ileti akışının bir alt kümesinde veya bölümünde okur.

Çok sayıda olay akışı yapması gereken bulutta yerel uygulamalar için Azure Event Hub sağlam ve uygun fiyatlı bir çözüm olabilir.

Geriİleri