Dayanıklı Olay Hub'ları ve İşlevler tasarımı

Hata işleme, idempotency için tasarlama ve yeniden deneme davranışını yönetme, Event Hubs ile tetiklenen işlevlerin dayanıklı ve büyük hacimli verileri işleyebilmesini sağlamak için gerçekleştirebileceğiniz kritik ölçülerden birkaçıdır. Bu makale bu önemli kavramları kapsar ve sunucusuz olay akışı çözümleri için önerilerde bulunur.

Azure, çok çeşitli benzersiz, olay odaklı senaryoları desteklemek için Azure İşlevleri ile kullanılabilen üç ana mesajlaşma hizmeti sunar. Azure Event Hubs, bölümlenmiş tüketici modeli ve verileri yüksek hızda alma özelliği nedeniyle olay akışı ve büyük veri senaryoları için yaygın olarak kullanılır. Azure mesajlaşma hizmetlerinin ayrıntılı karşılaştırması için bkz . Azure mesajlaşma hizmetleri arasında seçim yapma - Event Grid, Event Hubs ve Service Bus.

Akış avantajları ve zorlukları

Akışların avantajlarını ve dezavantajlarını anlamak, Event Hubs gibi bir hizmetin nasıl çalıştığını anlamanıza yardımcı olur. Önemli mimari kararlar alırken, sorunları giderirken ve performansı iyileştirirken de bu bağlama ihtiyacınız vardır. Hem Event Hubs hem de İşlevleri içeren çözümlerle ilgili aşağıdaki temel kavramları göz önünde bulundurun:

  • Akışlar kuyruk değildir: Bölümlenmiş tüketici modeli üzerinde oluşturulan Event Hubs, Kafka ve diğer benzer teklifler , Service Bus gibi bir ileti aracısında bazı temel özellikleri aslında desteklemez. Belki de bu farklılıkların en büyük göstergesi, okumaların yıkıcı olmamasıdır. Bu, İşlevler konağı tarafından okunan verilerin daha sonra kullanılabilir durumda kalmasını sağlar. Bunun yerine iletiler sabittir ve aynı tüketicinin yeniden okuması da dahil olmak üzere diğer tüketicilerin okuması için kalır. Bu nedenle , Rakip Tüketiciler gibi desenleri uygulayan çözümler Service Bus gibi bir ileti aracısı ile daha iyi kullanılabilir.

  • Eksik doğal dead-letter desteği: Dead-letter kanal, Event Hubs veya Kafka'da yerel bir özellik değildir. Genellikle, işlenemeyen verileri hesaba katmak için, akış çözümüne ölü harfleme kavramı entegre edilir. Bu işlev kasıtlı olarak Event Hubs'daki doğuştan gelen bir öğe değildir ve yalnızca tüketici tarafına benzer bir davranış veya etki üretmek için eklenir. Teslim edilemeyen ileti desteğine ihtiyacınız varsa, bir akış iletisi hizmeti seçiminizi gözden geçirmeniz gerekebilir.

  • Çalışma birimi, bölümleme birimidir: Geleneksel mesaj aracısında, çalışma birimi tek bir mesajdır. Akış çözümünde bölüm genellikle iş birimi olarak kabul edilir. Olay hub'ında her olay, sipariş işleme veya finansal işlem işleme gerektiren ayrı bir ileti olarak ele alınıyorsa, en iyi performans veya işleme için daha uygun bir mesajlaşma hizmetini keşfetme fırsatı sunar.

  • Sunucu tarafı filtrelemesi yok: Event Hubs'ın muazzam bir ölçek ve aktarım hızına sahip olmasının nedenlerinden biri, hizmetin kendisinde düşük ek yük olmasıdır. Sunucu tarafı filtreleme, dizinler ve aracılar arası koordinasyon gibi özellikler Event Hubs mimarisinin bir parçası değildir. İşlevler bazen olayları gövde veya üst bilgideki içeriklere göre diğer olay hub'larına yönlendirerek filtrelemek için kullanılır. Bu yaklaşım olay akışında yaygındır, ancak ilk işlevin her olayı okuması ve değerlendirmesiyle birlikte gelir.

  • Her okuyucunun tüm verileri okuması gerekir: Sunucu tarafı filtreleme kullanılamadığından, tüketici bir bölümdeki tüm verileri sırayla okur. Bu, ilgili olmayan veya hatta hatalı biçimlendirilmiş verileri içerir. Bu bölümün ilerleyen bölümlerinde ele alınan bu zorlukları telafi etmek için çeşitli seçenekler ve stratejiler kullanılabilir.

Bu tasarım kararları, Event Hubs'ın önemli bir olay akışını desteklemesine ve tüketicilerin okuması için dayanıklı bir hizmet sağlamasına olanak sağlar. Her tüketici uygulaması, bu olaylara kendi istemci tarafı uzaklıklarını veya imlecini koruma sorumluluğuyla görevlendirilmektedir. Düşük ek yük, Event Hubs'ı olay akışı için uygun maliyetli bir seçenek haline getirir.

İdempotentlik

Azure Event Hubs'ın temel kavramlarından biri en az bir kez teslim kavramıdır. Bu yaklaşım, etkinliklerin her zaman teslim edilmesini sağlar. Ayrıca olaylar, bir işlev gibi tüketiciler tarafından birden çok kez, hatta tekrar tekrar alınabileceği anlamına gelir. Bu nedenle, bir olay hub'ı ile tetiklenen işlevin idempotent tüketici desenini desteklemesi önemlidir.

Özellikle olay odaklı mimari bağlamında en az bir kez teslim varsayımı altında çalışmak, olayları güvenilir bir şekilde işlemeye yönelik sorumlu bir yaklaşımdır. İşlevinizin idempotent olması gerekir; böylece aynı olayı birden çok kez işlediğinizde, elde edilen sonuç tek bir kez işlediğinizdeki ile aynı olur.

Yinelenen olaylar

Bir işleve yinelenen olayların teslimine neden olabilecek birkaç farklı senaryo vardır:

  • Denetim noktası oluşturma: Azure İşlevleri konağı kilitlenirse veya toplu denetim noktası sıklığı için ayarlanan eşik karşılanmazsa, denetim noktası oluşturulmaz. Sonuç olarak, tüketicinin uzaklığı gelişmiş değildir ve işlev bir sonraki çağrılışında son denetim noktasından devam eder. Denetim noktası oluşturma, her tüketici için bölüm düzeyinde gerçekleşir.

  • Yinelenen olaylar yayımlandı: Birçok teknik aynı olayın bir akışta yayımlanma olasılığını azaltabilir, ancak tüketici yine de yinelenenleri aynı anda işlemekten sorumludur.

  • Eksik bildirimler: Bazı durumlarda, bir hizmete giden istek başarılı olabilir, ancak hizmetten bir bildirim (ACK) hiçbir zaman alınmaz. Bu algı, giden çağrının başarısız olduğu inancına neden olabilir ve işlevden tekrar denemeler veya başka sonuçlar tetikleyebilir. Sonunda yinelenen olaylar yayımlanabilir veya bir denetim noktası oluşturulmaz.

Yinelenenleri kaldırma teknikleri

İşlevlerinizi aynı giriş için tasarlamak, Event Hub tetikleyici bağlaması ile eşleştirildiğinde varsayılan yaklaşım olmalıdır. Aşağıdaki teknikleri dikkate almanız gerekir:

  • Yinelenenleri arama: İşlemeden önce, olayın işlenmesi gerektiğini doğrulamak için gerekli adımları uygulayın. Bazı durumlarda, bunun hala geçerli olduğunu doğrulamak için bir araştırma yapılması gerekir. Ayrıca, veri güncelliği veya olayı geçersiz hale getiren mantık nedeniyle olayı işlemenin artık gerekli olmaması da mümkün olabilir.

  • Eşzamanlılık için tasarım olayları: Olayın yükü içinde ek bilgiler sağlayarak, bunu birden çok kez işlemenin zarar verici bir etkisi olmadığından emin olmak mümkündür. Banka hesabından para çekme tutarı içeren bir olay örneğini inceleyin. Sorumlu bir şekilde işlenmezse hesabın bakiyesini birden çok kez azaltması mümkündür. Ancak, aynı olay hesaba güncelleştirilmiş bakiyeyi içeriyorsa, banka hesabı bakiyesine bir upsert işlemi gerçekleştirmek için kullanılabilir. Olay taşımalı bu durum aktarımı yaklaşımı bazen üreticiler ve tüketiciler arasında koordinasyon gerektirir ve katılan hizmetler için anlamlı olduğunda kullanılmalıdır.

Hata işleme ve yeniden deneme

Hata işleme ve yeniden denemeler dağıtılmış, olay temelli uygulamaların en önemli özelliklerinden birkaçıdır ve İşlevler özel durum değildir. Olay akışı çözümleri için doğru hata işleme desteğine ihtiyaç çok önemlidir çünkü binlerce olay doğru şekilde işlenmediği takdirde hızla eşit sayıda hataya dönüşebilir.

Hata işleme kılavuzu

Hata işleme olmadan, yeniden denemeleri uygulamak, çalışma zamanı özel durumlarını algılamak ve sorunları araştırmak zor olabilir. Her işlevin en az bir düzeyi veya hata işlemesi olmalıdır. Önerilen birkaç yönerge şunlardır:

  • Application Insights'ı kullanma: Hataları günlüğe kaydetmek ve işlevlerinizin durumunu izlemek için Application Insights'ı etkinleştirin ve kullanın. Yüksek hacimli olayları işleyen senaryolar için yapılandırılabilir örnekleme seçeneklerine dikkat edin.

  • Yapılandırılmış hata işleme ekleme: İşlev kodunuzda beklenen ve işlenmeyen özel durumları yakalamak, günlüğe kaydetmek ve algılamak için her programlama dili için uygun hata işleme yapılarını uygulayın. Örneğin, C#, Java ve JavaScript'te bir try/catch bloğu kullanın ve istisnaları işlemek için Python'daki try ve except bloklarından faydalanın.

  • Günlüğe kaydetme: Yürütme sırasında özel durum yakalamak, sorunları güvenilir bir şekilde algılamak, yeniden oluşturmak ve düzeltmek için kullanılabilecek kritik bilgileri günlüğe kaydetme fırsatı sağlar. Yalnızca mesajı değil, istisnanın içeriğini, dahili istisnayı ve daha sonra faydalı olacak diğer önemli bilgileri de günlüğe kaydedin.

  • Özel durumları yakalayıp yoksaymayın: Yapabileceğiniz en kötü şeylerden biri bir özel durumu yakalamak ve onunla hiçbir şey yapmaktır. Genel bir özel durum yakalarsanız bir yere kaydedin. Hataları günlüğe kaydetmezseniz hataları ve bildirilen sorunları araştırmak zordur.

Yeniden Denemeler

Olay akışı mimarisinde yeniden deneme mantığı uygulamak karmaşık olabilir. İptal belirteçlerini, yeniden deneme sayılarını ve üstel geri alma stratejilerini desteklemek, bunu zor hale getiren birkaç önemli noktadır. Neyse ki İşlevler, genellikle kendiniz kodladığınız bu görevlerin çoğu için yeniden deneme ilkeleri sağlar. Yeniden deneme stratejileri hakkında genel yönergeler için bkz. Geçici hataları işlemeye yönelik öneriler.

Olay Hub bağlamasıyla yeniden deneme stratejilerini kullanırken dikkate alınması gereken birkaç önemli faktör şunlardır:

  • Süresiz yeniden denemelerden kaçının:En yüksek yeniden deneme sayısı ayarı -1 değerine ayarlandığında işlev süresiz olarak yeniden denenir. Genel olarak, süresiz yeniden denemeler İşlevler ile ve neredeyse hiçbir zaman Event Hub tetikleyici bağlamasıyla kullanılmamalıdır.

  • Uygun yeniden deneme stratejisini seçin:Sabit bir gecikme stratejisi, diğer Azure hizmetlerinden geri baskı alan senaryolar için en uygun olabilir. Bu gibi durumlarda gecikme, kısıtlamayı ve bu hizmetlerde karşılaşılan diğer sınırlamaları önlemeye yardımcı olabilir. Üstel geri alma stratejisi, yeniden deneme gecikme aralıkları için daha fazla esneklik sunar ve genellikle üçüncü taraf hizmetler, REST uç noktaları ve diğer Azure hizmetleriyle tümleştirilirken kullanılır.

  • Aralıkları ve yeniden deneme sayılarını düşük tutun: Mümkün olduğunda, yeniden deneme aralığını bir dakikadan kısa tutmaya çalışın. Ayrıca, yeniden deneme denemesi sayısı üst sınırını makul düzeyde düşük bir sayının altında tutun. Bu ayarlar özellikle İşlev tüketimi planında çalıştırılırken geçerli olur.

  • Devre kesici düzeni: Zaman zaman geçici bir hata beklenir ve bu, yeniden denemeler için doğal bir kullanım örneğidir. Ancak, işlevin işlenmesi sırasında önemli sayıda hata veya sorun oluşuyorsa, işlevi durdurmak, sorunları çözmek ve daha sonra yeniden başlatmak mantıklı olabilir.

İşlevler'deki yeniden deneme ilkeleri için önemli bir nokta, olayların yeniden işlenmesi için en iyi çaba özelliğinin bu olmasıdır. Hata işleme, günlüğe kaydetme ve kodunuz için dayanıklılık sağlayan diğer önemli desenler gereksinimini değiştirmez.

Hatalar ve bozuk veriler için stratejiler

Dikkate değer çeşitli yaklaşımlar, bir olay akışındaki hatalar veya hatalı veriler nedeniyle oluşan sorunları telafi etme konusunda size yardımcı olabilir. Aşağıdaki temel stratejileri göz önünde bulundurun:

  • Göndermeyi ve okumayı durdurma: Temel sorunu düzeltmek için olayların okunmasını ve yazmasını duraklatın. Bu yaklaşımın avantajı, verilerin kaybolmaması ve bir düzeltme dağıtıldıktan sonra işlemlerin devam etmesidir. Bu yaklaşım, mimaride bir devre kesici bileşeni ve geçici durdurma gerçekleştirmek için ilgili hizmetlere bir bildirim gerektirebilir. Bazı durumlarda, sorunlar çözülene kadar bir işlevin durdurulması gerekebilir.

  • İletileri bırakma: İletiler önemli veya görev açısından kritik değilse, bunları işlemek yerine atabilirsiniz. Bu yaklaşım, bir satranç maçında veya finans tabanlı işlemlerde taşımaları kaydetme gibi güçlü tutarlılık gerektiren senaryolarda çalışmaz. Bir işlevin içinde hata işleme, işlenemeyen iletileri yakalamak ve bırakmak için önerilir.

  • Yeni -den deneme: Bir olayın yeniden işlenmesini garanti eden birçok durum vardır. En yaygın senaryo, başka bir hizmet veya bağımlılık çağrılırken karşılaşılan geçici bir hata olabilir. Ağ hataları, hizmet sınırları ve kullanılabilirlik ve güçlü tutarlılık, yeniden işleme girişimlerini haklı gösteren en sık kullanılan durumlar olabilir.

  • Geçersiz harf: Buradaki fikir, mevcut akışın kesintiye uğramaması için olayı farklı bir olay hub'ına yayımlamaktır. Algı, sıcak yoldan taşındığı ve daha sonra veya farklı bir işlemle ele alınabileceği şeklindedir. Bu çözüm, zehirli iletileri veya olayları işlemek için sık sık kullanılır. Farklı bir tüketici grubuyla yapılandırılan her işlev akışında yine hatalı veya bozuk verilerle karşılaşır ve bunu sorumlu bir şekilde işlemelidir.

  • Yeniden deneme ve ölü harf: Eşik karşılandığında, son olarak bir ölü harf akışına yayımlamadan önce yapılan çok sayıda yeniden deneme girişiminin birleşimi, bilinen bir diğer yöntemdir.

  • Şema kayıt defteri kullanma: Tutarlılığı ve veri kalitesini geliştirmeye yardımcı olmak için proaktif bir araç olarak bir şema kayıt defteri kullanılabilir. Azure Schema Registry, şemalar geliştikçe sürüm oluşturma ve farklı uyumluluk modlarıyla birlikte şemaların geçişini destekleyebilir. Şema, temel olarak üreticiler ve tüketiciler arasında bir sözleşme görevi görür ve bu da akışta geçersiz veya bozuk verilerin yayımlanma olasılığını azaltabilir.

Sonunda, mükemmel bir çözüm yoktur ve stratejilerin her birinin sonuçları ve dezavantajları ayrıntılı bir şekilde incelenmelidir. Gereksinimlere bağlı olarak, bu tekniklerin birkaçını birlikte kullanmak en iyi yaklaşım olabilir.

Katkıda Bulunanlar

Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazar:

Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.

Sonraki adımlar

Devam etmeden önce şu ilgili makaleleri gözden geçirmeyi göz önünde bulundurun:

Güvenlik

  • Last updated on