Güvenilir olay işleme Azure İşlevleri

  • Makale

Olay işleme, sunucusuz mimariyle ilişkili en yaygın senaryolardan biridir. Bu makalede, iletilerin kaybolmasını önlemek için Azure İşlevleri ile güvenilir bir ileti işlemcisi oluşturma açıklanmaktadır.

Dağıtılmış sistemlerde olay akışlarının zorlukları

Olayları saniyede sabit 100 olay hızında gönderen bir sistem düşünün. Bu hızda, dakikalar içinde her saniye gelen 100 olayı birden çok paralel İşlev örneği kullanabilir.

Ancak, aşağıdaki en uygun olmayan koşullardan herhangi biri mümkündür:

  • Olay yayımcısı bozuk bir olay gönderirse ne olur?
  • İşlevler örneğiniz işlenmeyen özel durumlarla karşılaşırsa ne olur?
  • Aşağı akış sistemi çevrimdışı olursa ne olur?

Uygulamanızın aktarım hızını korurken bu durumlarla nasıl başa çıkabilirsiniz?

Kuyruklarda güvenilir mesajlaşma doğal olarak gelir. İşlev tetikleyicisi ile eşleştirildiğinde, işlev kuyruk iletisinde bir kilit oluşturur. İşleme başarısız olursa, başka bir örneğin işlemeyi yeniden denemesine izin vermek için kilit serbest bırakılır. ardından, ileti başarıyla değerlendirilene veya bir zehir kuyruğuna eklenene kadar işleme devam eder.

Tek bir kuyruk iletisi yeniden deneme döngüsünde kalsa bile, diğer paralel yürütmeler kalan iletilerin sırasını kaldırmaya devam eder. Sonuç, genel aktarım hızının tek bir hatalı iletiden büyük ölçüde etkilenmemesidir. Ancak depolama kuyrukları sıralamayı garanti etmez ve Event Hubs'ın gerektirdiği yüksek aktarım hızı talepleri için iyileştirilmemiştir.

Buna karşılık, Azure Event Hubs bir kilitleme kavramı içermez. Yüksek aktarım hızı, birden çok tüketici grubu ve yeniden yürütme özelliği gibi özelliklere izin vermek için Event Hubs olayları daha çok video oynatıcı gibi davranır. Olaylar akışta bölüm başına tek bir noktadan okunur. İşaretçiden bu konumdan ileri veya geri okuyabilirsiniz, ancak olayların işlenmesi için işaretçiyi taşımayı seçmeniz gerekir.

Akışta hatalar oluştuğunda, işaretçiyi aynı noktada tutmaya karar verirseniz, işaretçi gelişmiş olana kadar olay işleme engellenir. Başka bir deyişle, işaretçi tek bir olayı işleme sorunlarıyla başa çıkmak için durdurulursa, işlenmemiş olaylar birikmeye başlar.

Azure İşlevleri, başarılı veya başarısız olmasına bakılmaksızın akışın işaretçisini ilerleterek kilitlenmeleri önler. İşaretçi ilerlemeye devam ettiğinden işlevlerinizin hatalarla uygun şekilde ilgilenmesi gerekir.

Azure İşlevleri Event Hubs olaylarını nasıl tüketir?

Azure İşlevleri, aşağıdaki adımlarda döngü yaparken Event Hub olaylarını tüketir:

  1. Olay hub'ının her bölümü için Azure Depolama'da bir işaretçi oluşturulur ve kalıcı hale eklenir.
  2. Yeni iletiler alındığında (varsayılan olarak bir toplu işlemde), konak işlevi ileti toplu işlemiyle tetiklemeye çalışır.
  3. İşlev yürütmeyi tamamlarsa (özel durumla veya özel durum olmadan) işaretçi ilerler ve depolama hesabına bir denetim noktası kaydedilir.
  4. Koşullar işlev yürütmenin tamamlanmasını engellerse, konak işaretçiyi ilerletemez. İşaretçi gelişmiş değilse, daha sonra denetimler aynı iletileri işler.
  5. 2–4 arası adımları yineleyin

Bu davranış birkaç önemli noktayı ortaya koyuyor:

Özel durum işleme

Genel bir kural olarak, her işlev en yüksek kod düzeyinde bir try/catch bloğu içermelidir. Özellikle, Event Hubs olaylarını kullanan tüm işlevlerin bir catch bloğu olmalıdır. Bu şekilde, bir özel durum oluştuğunda, işaretçi ilerlemeden önce catch bloğu hatayı işler.

Yeniden deneme mekanizmaları ve ilkeleri

Bazı özel durumlar doğası gereği geçicidir ve birkaç dakika sonra bir işlem yeniden denendiğinde yeniden ortaya çıkmasın. bu nedenle ilk adım her zaman işlemi yeniden denemektir. İşlev uygulaması yeniden deneme ilkelerini kullanabilir veya işlev yürütmesi içinde yeniden deneme mantığı yazabilirsiniz.

İşlevlerinize hata işleme davranışları eklemek hem temel hem de gelişmiş yeniden deneme ilkeleri tanımlamanızı sağlar. Örneğin, aşağıdaki kuralların gösterildiği bir iş akışını izleyen bir ilke uygulayabilirsiniz:

  • İletiyi üç kez eklemeyi deneyin (yeniden denemeler arasında gecikme olabilir).
  • Tüm yeniden denemelerin nihai sonucu bir hataysa işlemenin akışta devam edebilmesi için kuyruğa bir ileti ekleyin.
  • Bozuk veya işlenmemiş iletiler daha sonra işlenir.

Not

Polly , C# uygulamaları için dayanıklılık ve geçici hata işleme kitaplığı örneğidir.

Özel durum olmayan hatalar

Hata olmadığında bile bazı sorunlar ortaya çıkar. Örneğin, yürütmenin ortasında oluşan bir hatayı düşünün. Bu durumda, bir işlev yürütmeyi tamamlamazsa, uzaklık işaretçisi hiçbir zaman ilerletilmez. İşaretçi ilerlemezse, başarısız bir yürütmeden sonra çalışan tüm örnekler aynı iletileri okumaya devam eder. Bu durum "en az bir kez" garanti sağlar.

Her iletinin en az bir kez işlendiğinden emin olmak, bazı iletilerin birden çok kez işlenebileceğini gösterir. İşlev uygulamalarınızın bu olasılığın farkında olması ve bir kez daha etkili olma ilkelerine göre derlenmiş olması gerekir.

Yürütmeyi durdurma ve yeniden başlatma

Birkaç hata kabul edilebilir olsa da, uygulamanız önemli hatalarla karşılaşırsa ne olur? Sistem iyi durumda olana kadar olaylar üzerinde tetiklemeyi durdurmak isteyebilirsiniz. İşlemeyi duraklatma fırsatına sahip olmak genellikle bir devre kesici düzeniyle elde edilir. Devre kesici düzeni, uygulamanızın olay işleminin "devresini kesmesine" ve daha sonra devam etmesine olanak tanır.

Bir olay işleminde devre kesici uygulamak için gereken iki parça vardır:

  • Bağlantı hattının durumunu izlemek ve izlemek için tüm örneklerde paylaşılan durum
  • Bağlantı hattı durumunu yönetebilen ana işlem (açık veya kapalı)

Uygulama ayrıntıları farklılık gösterebilir, ancak durum bilgilerini örnekler arasında paylaşmak için bir depolama mekanizmasına ihtiyacınız vardır. Durumu Azure Depolama'da, Redis önbelleğinde veya bir işlev koleksiyonu tarafından erişilebilen başka bir hesapta depolamayı seçebilirsiniz.

Azure Logic Apps veya dayanıklı işlevler , iş akışını ve devre durumunu yönetmek için doğal olarak uygundur. Diğer hizmetler de aynı şekilde çalışabilir, ancak bu örnek için mantıksal uygulamalar kullanılır. Mantıksal uygulamaları kullanarak bir işlevin yürütülmesini duraklatabilir ve yeniden başlatarak devre kesici düzenini uygulamak için gereken denetimi sağlayabilirsiniz.

Örnekler arasında hata eşiği tanımlama

Olayları aynı anda işleyen birden çok örneği hesaba katmak için, bağlantı hattının durumunu izlemek için paylaşılan dış durumun kalıcı olması gerekir.

Uygulamayı seçebileceğiniz bir kural bunu zorunlu kılabilir:

  • Tüm örneklerde 30 saniye içinde 100'den fazla nihai hata varsa, devreyi kesin ve yeni iletilerde tetiklemeyi durdurun.

Uygulama ayrıntıları gereksinimlerinize göre farklılık gösterir, ancak genel olarak şunları sağlayan bir sistem oluşturabilirsiniz:

  1. Depolama hesabında günlük hataları (Azure Depolama, Redis vb.)
  2. Yeni hata günlüğe kaydedildiğinde, eşiğin karşılandığını görmek için sıralı sayıyı inceleyin (örneğin, son 30 saniyede 100'den fazla).
  3. Eşik karşılanırsa, sisteme devreyi kesmesini söyleyen Azure Event Grid bir olay yayın.

Azure Logic Apps ile devre durumunu yönetme

Aşağıdaki açıklama, İşlevler uygulamasının işlenmesini durdurmak için Bir Azure Mantıksal Uygulaması oluşturma yollarından birini vurgular.

Azure Logic Apps, farklı hizmetlere yerleşik bağlayıcılar, durum bilgisi olan düzenleme özellikleriyle birlikte gelir ve devre durumunu yönetmek için doğal bir seçimdir. Devrenin bozulması gerektiğini algıladıktan sonra, aşağıdaki iş akışını uygulamak için bir mantıksal uygulama oluşturabilirsiniz:

  1. Event Grid iş akışını tetikleme ve Azure İşlevini durdurma (Azure Kaynak bağlayıcısı ile)
  2. İş akışını yeniden başlatma seçeneği içeren bir bildirim e-postası gönderme

E-posta alıcısı bağlantı hattının durumunu araştırabilir ve uygun olduğunda, bildirim e-postasında yer alan bir bağlantı aracılığıyla bağlantı hattını yeniden başlatabilir. İş akışı işlevi yeniden başlatırken iletiler son Olay Hub'ı denetim noktasından işlenir.

Bu yaklaşımı kullanarak hiçbir ileti kaybolmaz, tüm iletiler sırayla işlenir ve bağlantı hattını gerektiği kadar kesebilirsiniz.

Kaynaklar

Sonraki adımlar

Daha fazla bilgi için aşağıdaki kaynaklara bakın: