Dayanıklı Event Hubs ve Işlevleri tasarımı

Hata işleme, ıdesotlik tasarlama ve yeniden deneme davranışı yönetimi, Event Hubs tetiklenen işlevlerin dayanıklı olduğundan ve büyük hacimlerde veri işleyebilme yeteneği sağlamak için uygulayabileceğiniz kritik ölçülerden birkaçı. Bu makalede, bu önemli kavramlar ele alınmaktadır ve sunucusuz olay akışı çözümleri için öneriler sağlanır.

Azure, çok sayıda benzersiz ve olay odaklı senaryoyu desteklemek için Azure Işlevleri ile birlikte kullanılabilecek üç ana mesajlaşma hizmeti sağlar. Bölümlenmiş tüketici modeli ve verileri yüksek bir hızda alma özelliği nedeniyle Azure Event Hubs, genellikle olay akışı ve büyük veri senaryoları için kullanılır. Azure mesajlaşma hizmetleri hakkında ayrıntılı bir karşılaştırma için bkz. Azure mesajlaşma hizmetleri arasında seçim yapın-Event Grid, Event Hubs ve Service Bus.

Akış avantajları ve güçlükleri

Akışlarının avantajlarının ve dezavantajlarının anlaşılmasına, Event Hubs gibi bir hizmetin nasıl çalıştığını kavramanıza yardımcı olur. Ayrıca, etkili mimari kararlar verirken, sorunları giderirken ve performans için iyileştirirken bu bağlamı da kullanmanız gerekir. Hem Event Hubs hem de Işlevleri sağlayan çözümler hakkında aşağıdaki temel kavramları göz önünde bulundurun:

• Akışlar kuyruklar değil: Event Hubs, Kafka ve bölümlenmiş tüketici modelinde oluşturulan diğer benzer tekliflerde Service Busgibi bir ileti aracılarındaki bazı asıl özellikler desteklenmez. Belki de bunun en büyük göstergesi, okuma, yıkıcı olmayanbir olgu değildir. Bu, Işlevler ana bilgisayarı tarafından okunan verilerin daha sonra silinmeyeceği anlamına gelir. Bunun yerine, iletiler sabittir ve diğer tüketiciler tarafından okunmak üzere kalır, bu da aynı müşteri tarafından yeniden okunuyor. Bu nedenle, rakip tüketiciler gibi desenleri uygulayan çözümler geleneksel bir ileti Aracısı için daha uygundur.

• Devralma atılacak mektup desteği yok: Bir atılacak ileti kanalı, Event Hubs veya Kafka 'de yerel bir özellik değildir. Genellikle, ölü kanıtlama kavramı , işlenemeyen verileri hesaba yönelik bir akış çözümüne tümleştirilir. Bu işlevsellik, Event Hubs içinde bir Innate öğesi değildir ve yalnızca benzer bir davranış ya da efekt üretmek için tüketici tarafına eklenir. Atılacak ileti desteğine ihtiyacınız varsa, muhtemelen seçtiğiniz akış iletisi hizmetini gözden geçirmeniz gerekir.

• Çalışma birimi bir bölümdür: Geleneksel bir ileti aracıda bir iş birimi tek bir iletidir. Bir akış çözümünde, Bölüm genellikle iş birimi olarak kabul edilir. Bir olay hub 'ındaki her bir olay, bir sipariş işleme işlemi ya da finansal işlem gibi değerlendirilmesinin gerekli olduğu ayrı bir ileti olarak kabul edilir, büyük olasılıkla kullanılan yanlış mesajlaşma hizmeti göstergesidir.

• Sunucu tarafında filtreleme yok: Event Hubs nedenlerden biri, hizmet üzerindeki düşük yükün büyük ölçüde ölçeklendirilmesi ve verimlilik olmamasıdır. Sunucu tarafı filtreleme, dizinler ve çapraz aracı düzenlemesi gibi özellikler Event Hubs mimarisinin bir parçası değildir. İşlevler zaman zaman, gövde veya başlıktaki içeriğe göre diğer Event Hubs yönlendirerek olayları filtrelemek için kullanılır. Bu yaklaşım olay akışında yaygındır, ancak her olayın ilk işlev tarafından okunarak ve değerlendirilme desteklenmediği uyarısıyla ile birlikte gelir.

• Her okuyucu tüm verileri okummalıdır: Sunucu tarafı filtrelemesi kullanılamadığından, tüketici bir bölümdeki tüm verileri sıralı olarak okur. Bu, ilgili olmayan veya hatalı biçimlendirilmiş olabilecek verileri içerir. Bu bölümde daha sonra ele alınacaktır. bu zorluk dengelemek için kullanılabilecek birkaç seçenek ve çift strateji vardır.

Bu önemli tasarım kararları Event Hubs en iyi şeyi yapmasına izin verir: önemli bir etkileyen olayları destekleme ve tüketicilerin okuyabilecekleri sağlam ve dayanıklı bir hizmet sağlama. Her tüketici uygulaması, kendi, istemci tarafı farklarını veya imlecinizin bu olaylara karşı koruma sorumluluğunu sağlar. Düşük yük, olay akışı için uygun maliyetli ve güçlü bir seçenek Event Hubs olur.

Teklik

Azure Event Hubs 'ın temel kavramlarından biri en az bir kez teslim kavramıdır. Bu yaklaşım, olayların her zaman teslim edilmesini sağlar. Ayrıca, olayların bir işlev gibi bir kereden fazla kez alınabileceği anlamına gelir. Bu nedenle, bir olay hub 'ı tetiklediği işlevin ıdempotent tüketici modelini desteklemesi önemlidir.

Özellikle olay odaklı bir mimarinin bağlamında bir kez teslimin bir kez teslim varsayımıyla çalışarak, olayların güvenilir bir şekilde işlenmesi için sorumlu bir yaklaşım vardır. İşleviniz ıdempotent olmalıdır, böylece aynı olayı işlemek birden çok kez işleme sonucu, bir kez işlenmesiyle aynı olur.

Yinelenen olaylar

Yinelenen olayların bir işleve teslim edilmesine neden olabilecek birkaç farklı senaryo vardır:

• Checkişaret: Azure Işlevleri ana bilgisayarı kilitlenirse veya Batch denetim noktası sıklığı için eşik kümesi karşılanmazsa, bir denetim noktası oluşturulmaz. Sonuç olarak, tüketici için fark gelişmiş değildir ve işlevin bir sonraki çağrılışında son denetim noktasından sürdürülecek. Her tüketiciye yönelik bölüm düzeyinde onay işareti oluştuğunu unutmayın.

• Yayımlanan yinelenen olaylar: Aynı olayın bir akışa yayımlanmasının olasılığını ortadan kaldırmaya yönelik birçok teknik vardır, ancak yine de tüketicinin idempotently işlemesi gerekir.

• Eksik kaynaklar: Bazı durumlarda, bir hizmete giden istek başarılı olabilir, ancak hizmetten gelen bir bildirim (ACK) hiç alınmaz. Bu, giden çağrının başarısız olduğu ve işlevden bir seri veya yeniden deneme ya da başka sonuçlar Başlatan bir hata nedeniyle ortaya çıkabilir. Sonunda, yinelenen olaylar yayımlanabilir veya bir kontrol noktası oluşturulmaz.

Yinelenenleri kaldırma teknikleri

İşlevlerinizi özdeş giriş için tasarlamak, Olay Hub 'ı tetikleme bağlaması ile eşleştirildiği zaman gerçekleştirilen varsayılan yaklaşım olmalıdır. Aşağıdaki teknikleri göz önünde bulundurmanız gerekir:

• Yinelemeler aranıyor: İşlemeden önce, olayın işlenmesi gerektiğini doğrulamak için gerekli adımları uygulayın. Bazı durumlarda bu, hala geçerli olduğunu doğrulamak için bir araştırma gerektirir. Ayrıca, veri yeniliği veya olayı geçersiz kılan mantık nedeniyle olayı işlemeye artık gerek duyulmaz.

• Idempotlik Için tasarım olayları: Etkinliğin yükü içinde ek bilgiler sunarak, birden çok kez işlemenin hiç bir olumsuz etkiye sahip olmamasını sağlamak mümkün olabilir. Bir banka hesabından çekmek için bir miktar içeren bir olay örneğini alın. İşlenmezse, bir hesabın bakiyesini birden çok kez azaltabileceği için bu mümkün olabilir. Ancak, aynı olay hesaba güncelleştirilmiş bakiyeyi içeriyorsa, banka hesap bakiyesine bir ön e işlemi gerçekleştirmek için kullanılabilir. Bu olay taşınan durum aktarımı yaklaşımı bazen üreticileri ve tüketiciler arasında eşgüdüm gerektirir ve Katılımcı Hizmetleri 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 odaklı uygulamaların en önemli kalitelerinden ve Işlevlerinin bir istisna olmadığı bir durumdur. Olay akışı çözümleri için, düzgün bir şekilde işlenmezse binlerce olay daha hızlı bir şekilde hatalara sahip olduğunda, doğru hata işleme desteği çok önemlidir.

Hata işleme Kılavuzu

Hata işleme olmadan yeniden denemeler uygulamak, çalışma zamanı özel durumlarını algılamak ve sorunları araştırmak için bu durum karmaşık olabilir. Her işlevde en az bir düzey veya hata işlemesi olmalıdır. Önerilen birkaç yönerge şunlardır:

• Application Insights kullanın: Application Insights kullanarak hataları günlüğe kaydedin ve işlevlerinizin durumunu izleyin. Yüksek hacimli olayları işleyen senaryolar için yapılandırılabilir örnekleme seçeneklerinin en az olması önerilir.

• Yapılandırılmış hata Işleme Ekle: İşlev kodunuzda beklenen ve işlenmemiş özel durumları yakalamak, günlüğe kaydetmek ve algılamak için her bir 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 özel durumları işlemek için Python 'daki try ve except blokları avantajlarından yararlanın.

• Günlüğe kaydetme: Yürütme sırasında bir özel durum yakalamak, sorunları güvenilir bir şekilde algılamak, yeniden oluşturmak ve gidermek için kullanılabilecek kritik bilgileri günlüğe kaydetmek için bir fırsat sağlar. Özel durumu yalnızca iletiyi değil, iç özel durumu ve daha sonra yararlı olacak diğer yararlı yapıları günlüğe kaydedin.

• Özel durumları yakalamayın ve yoksayın: Yapabileceğiniz en kötü işlemlerden biri bir özel durum yakalar ve onunla hiçbir şey yapmaz. Genel bir özel durumu yakalarsanız, bir yere kaydedin. Hataları günlüğe kaydetmek istemiyorsanız, hataları ve bildirilen sorunları araştırmak zordur.

Yeniden deneme sayısı

Olay akışı mimarisinde yeniden deneme mantığını uygulamak karmaşık olabilir. İptal belirteçlerini destekleme, yeniden deneme sayısı ve üstel geri alma stratejileri, bunu zorlayıcı hale getirmek için önemli noktalara dikkat edin. Neyse ki Işlevler, genellikle kendinize kodlarınızın pek çok görevi yapabilecek yeniden deneme ilkeleri sağlar.

Yeniden deneme ilkeleri Olay Hub 'ı bağlamasıyla kullanılırken göz önünde bulundurmanız gereken birkaç önemli etken şunlardır:

• Belirsiz yeniden denemelerden kaçının:En fazla yeniden deneme sayısı ayarı-1 değerine ayarlandığında, işlev süresiz olarak yeniden dener. Genel olarak, belirsiz yeniden denemeler Işlevleri ile gelişigüzel bir şekilde kullanılmalıdır ve Olay Hub 'ı tetikleme bağlantısı ile neredeyse asla hiçbir şekilde kullanılmamalıdır.

• Uygun yeniden deneme stratejisini seçin: Bir sabit gecikme stratejisi, diğer Azure hizmetlerinden basınç elde eden senaryolar için idealdir. Bu gibi durumlarda, gecikme azaltma ve bu hizmetlerden gelen diğer kısıtlamaların önlenmesine yardımcı olabilir. Üstel geri kapatma stratejisi, yeniden deneme gecikmesi aralıklarında 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ı koru ve yeniden deneme sayısı düşük: Mümkün olduğunda, bir dakikadan kısa bir yeniden deneme aralığı tutmaya çalışın. Ayrıca, yeniden deneme sayısı üst sınırını olabildiğince düşük bir sayıya tutun. Bu ayarlar özellikle Işlevler tüketim planında çalışırken geçerlidir.

• Devre kesici stili: Zaman zaman için geçici bir hata hatası ve yeniden denemeler için doğal kullanım örneği bekleniyor. Ancak, işlevin işlenmesi sırasında önemli sayıda başarısızlık veya sorun oluşuyorsa, işlevi durdurmak, sorunları gidermek ve daha sonra yeniden başlatmak mantıklı olabilir.

Işlevlerdeki yeniden deneme ilkeleri için önemli bir kalkış, olayların yeniden işlenmesine yönelik en iyi çaba bir özelliktir. Hata işleme, günlüğe kaydetme ve kodunuza dayanıklılık sağlayan diğer önemli desenler gereksinimini ortadan kaldırmaz.

Hatalara ve bozuk verilere yönelik stratejiler

Bir olay akışındaki hatalardan veya hatalı verilerden kaynaklanan sorunları dengelemek için kullanabileceğiniz birkaç önemli yaklaşım vardır. Bazı temel stratejiler şunlardır:

• Göndermeyi ve okumayı Durdur: Temel sorunu giderecek olay okumayı ve yazmayı duraklatın. Bu yaklaşımın avantajı, verilerin kaybolmaması ve bir onarım alındıktan sonra işlemler sürdürülemez. Bu yaklaşım, mimaride bir devre kesici bileşeni ve bir duraklatma sağlamak için etkilenen hizmetlere yönelik bir bildirimde bulunabilir. Bazı durumlarda, sorunlar çözümlenene kadar bir işlevin durdurulması gerekebilir.

• İletileri bırakma: İletiler önemli değilse veya görev açısından kritik olarak kabul edilirse, bunları işlemeden devam edin. Bu, bir eşleşme veya finans tabanlı işlemlere yapılan kayıtların kaydı gibi güçlü tutarlılık gerektiren senaryolarda işe uygun değildir. İşlevin içindeki hata işleme, işlenmeyecek iletileri yakalamak ve bırakmak için önerilir.

• Yeni -den deneme: Bir olayın yeniden işlenmeyi 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 hatadır. Ağ hataları, hizmet sınırları ve kullanılabilirlik ve güçlü tutarlılık, yeniden işleme girişimlerini haklı bulan en sık kullanım örnekleri olabilir.

• Harfin yazılma tarihi: Buradaki fikir, mevcut akışın kesintiye uğraması için olayı farklı bir olay hub'sinde yayımlamaktır. Algı, bu dosyanın sıcak yoldan taşındığını ve daha sonra veya farklı bir işlemle ilgilenilebilirsiniz. Bu çözüm, sık sık iletilerin veya olayların işlenmesi için kullanılır. Farklı bir tüketici grubuyla yapılandırılan her işlevin, akışlarında kötü veya bozuk verilerle yine de karşılaşacak ve bunu sorumlu bir şekilde işlemesi gerektiğine de yer verilsin.

• Yeniden deneme ve geri gelen harf: Eşik karşılanana kadar son olarak bir harf akışında yayımlamadan önce çok sayıda yeniden deneme girişiminin birleşimi tanıdık bir yöntemdir.

• Şema kayıt defteri kullanma: Şema kayıt defteri, tutarlılığı ve veri kalitesini geliştirmeye yardımcı olmak için proaktif bir araç olarak kullanılabilir. Azure Schema Registry, şemalar geliştikçe sürüm ve farklı uyumluluk modlarının yanı sıra şemaların geçişlerini de destekleyebilirsiniz. Şema, temel olarak üreticiler ve tüketiciler arasında bir sözleşme olarak görev yapacak ve bu da akışta geçersiz veya bozuk verilerin yayımlanma olasılığını düşürecek.

Sonunda mükemmel bir çözüm yok ve stratejilerden her biri için sonuçların ve takasların kapsamlı bir şekilde incelenmesi gerekiyor. Gereksinimlere bağlı olarak, bu tekniklerden birkaçını birlikte kullanmak en iyi yaklaşım olabilir.

Sonraki adımlar

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

• Azure İşlevleri olay işleme
• Aynı Azure İşlevleri için tasarım
• Azure İşlevleri işleme ve yeniden deneme kılavuzu

İlgili kaynaklar

• Sunucusuz olay işlemeyi izleme, sunucusuz olay odaklı mimarileri izleme konusunda rehberlik sağlar.
• Sunucusuz olay işleme, kod örnekleri ve önemli konuların tartışmaları ile birlikte bu tür tipik bir mimariyi ayrıntılı olarak ele alan bir başvuru mimarisidir.
• Event Hubs ile sunucusuz olay işlemede toplu işi Event Hubs, başvuru mimarisinin bu bölümlerinin nasıl işlemektedir?