Durable Task'ın değeri her arka plan çalışanının, ileti kuyruğunun veya veritabanının yerini almasında değil; uzun süren, harici bir olayı beklemek üzere duran ya da adımlarının bir bölümü yürütüldükten sonra kesintiye uğrayabilen işlemleri düzenlemesinde yatar. .NET blogu, Durable Task .NET SDK sürüm 1.26.0 ile Durable Task Scheduler kullanarak beş pratik örnek sunuyor ve aracın askıya alınmış CLR yürütme yığınını kurtarmadığını, orkestrasyon geçmişini koruduğunu vurguluyor.
Temel fikir, iş akışı motorunun koordine ettiği şeylerle uygulamanın sorumluluğunda kalan şeyleri birbirinden ayırmaktır. Durable Task ilerleme noktalarını kaydedebilir, meşgul bir yürütme iş parçacığını tutmadan bekleyebilir ve kaydedilmiş sonuçlara dayanarak orkestratör kodunu yeniden çalıştırabilir. Ancak kullanıcı yetkilerine karar vermez, harici etkilerin tek seferlik yürütülmesini garanti etmez ve silinmesi güvenli kaynakları ya da bir ödeme paketinin gerçekten ulaşıp ulaşmadığını tek başına belirlemez.
İnsan onayı çalışanı durdurmak anlamına gelmez
Fatura işlemede her fatura ayrı bir alt orkestrasyon içinde çalıştırılabilir. İnceleme gerektirmeyen faturalar yollarına devam ederken, insan onayı gerektiren fatura sağlam bir harici olay ve zaman aşımı bekler. Çalışan durursa başka bir çalışan orkestratörü yeniden çalıştırabilir ve durumu elle yeniden oluşturmaktansa bekleme noktasına geri dönebilir.
Bununla birlikte onay olayı yalnızca bir sinyaldir. Belgelenmiş bir uç nokta, sinyali göndermeden önce nihai kararı uygulamanın veri deposuna atomik olarak kaydetmeli ve muhasebe adımı sabit bir dağıtım kimliğini ve değiştirilemez bir istek parmak izini doğrulamalıdır. Muhasebe kaydı kabul edilip etkinlik onayı kaybolursa, yinelenmeyi önlemek için yalnızca Durable Task geçmişi yeterli değildir; muhasebe sistemiyle bir mutabakat protokolü gerekir.
Azure ortamını hazırlama: ARM'ın rolü nerede biter?
Makale, ARM ve Bicep'in belirli kaynakları dağıtmak için yeterli olabileceğini belirtiyor; çünkü bunlar bağımlılıkların sıralanmasını, paralel yürütmeyi ve sabit kimliklerle istenen durumun yeniden uygulanmasını sağlar. Bu nedenle ARM'ın zaten sağladığı bir dağıtım planını yeniden oluşturmak için Durable Task eklemek değerli değildir.
Fayda, akış kaynakların dağıtımını aşarak kiracı isteğinin kabul edilmesine, ilerlemenin bildirilmesine, hazır olmanın beklenmesine ve ardından kiracının etkinleştirilmesine ulaştığında ortaya çıkar. Örnek, hazırlama isteğinin ve tanımlayıcılarının bir outbox ile birlikte uygulama veritabanına kaydedilmesini, ardından ağ, veritabanı, depolama, uygulama ve DNS aşamalarını ve hazır olma denetimini birbirine bağlayan bir orkestrasyon kullanılmasını öneriyor. Azure işlemlerinin kendisi ise yanıtların kaybolması durumunda işlem günlüklerine, sabit kimliklere ve mutabakata ihtiyaç duymaya devam eder.
Makale, telafiyi bir geri alma düğmesi olarak görmemek konusunda uyarıyor. Depolama başarısız olduktan sonra Azure hâlâ bir veritabanı oluşturuyor olabilir. Bu nedenle eski denemenin yeni işlemler başlatması engellenmeli, daha önce gönderilmiş işlemler denetlenmeli ve gecikmiş işlemlerin kaynakları yeniden oluşturmayacağından emin olunduktan sonra yalnızca denemeye özel kaynaklar silinmelidir. Durum veya sahiplik kanıtlanamıyorsa güvenli sonuç tahmine dayalı silme değil, NeedsIntervention'dır.
Ödeme zaman aşımı ret anlamına gelmez
Abonelik döngüsünde işlem kabul edildikten sonra ödeme sağlayıcısının yanıtı kaybolabilir. Hemen yeniden denemek çifte ücretlendirmeye yol açabilirken işlemi reddedilmiş saymak yanıltıcı bir bildirim gönderebilir. Örnek, her ödeme döngüsünü bir döngü kimliğine ve sabit bir ödeme anahtarına bağlamayı, ardından durable zamanlayıcıları, geri çağrıları, periyodik denetimleri ve belirlenmiş bir ek süreyi kullanmayı öneriyor.
Ödemeler defteri Unknown, Pending, Declined, Paid ve NotCharged durumları için authoritative kaynaktır. Döngü, makbuz doğrulanıp mevcut döngü kapatılmadan bir sonrakine geçmez. Zaman aşımı sona erdiğinde durum hâlâ çözümlenmemişse sonuç, ödemenin başarılı ya da başarısız olduğunu varsaymak yerine NeedsReconciliation olur.
Geç gelen olayların hedefte korunmaya ihtiyacı vardır
Haber makaleleri için bir arama dizini güncellenirken 12. sürüm 13. sürümden sonra gelebilir veya dizinleme işlemleri ters sırayla tamamlanabilir. Durable entity, görülen en yüksek sürümü ve sayaç güncellemelerinin sırasını saklayabilir; ancak harici dizini kilitlemez veya iki isteğin paralel olarak yazmasını engellemez.
Bu nedenle hedefin kendisi, daha yeni bir sürüm sabitlendikten sonra daha eski bir sürümün yazılmasını reddeden atomik bir sürüm engeli uygulamalıdır. Sistem ayrıca güvenilir bir inbox'a, takip için bir dağıtıcıya ve kaynakla periyodik mutabakata ihtiyaç duyar. Tek kimlikli orkestratör deseni bile harici etkiler için tek seferlik yürütme garantisi sunmaz.
Bu, yapay zekâ aracıları için ne anlama gelir?
Olay yardımcısı iş akışında süreç, belirli model önerisinin kaydedilmesini, mühendisin öneriyi onaylamasının beklenmesini ve olası bir arızadan sonra onaylanan aracın yürütülmesini gerektirir. Buradaki değer, her yeniden çalıştırmadan sonra yeni bir öneri üretmek değil, onay ve karar yolunun kendisini kurtarmaktır. Önerinin kimliği, aracın geçerliliği ve eski ya da yinelenen bir isteğin yürütülmesinin engellenmesi ise uygulamanın sorumluluğunda kalır.
Beş örnekten çıkan pratik sonuç, «sırada ne olacağının» kaydedilmesi başlı başına bir sistem hâline geldiğinde Durable Task'ın uygun olduğudur. Uygulama zaten kuyruklara, zamanlayıcılara ve açık mutabakat günlüklerine sahipse veya sistem dışı taraf ARM gibi güvenilir bir orkestrasyon sağlıyorsa, çerçeve değerinden daha fazla karmaşıklık katabilir. Ayrıca tüm örnekler açık harici sınırlara dayanır: yetkili kayıt, idempotency anahtarı, sürüm engeli, outbox veya mutabakat protokolü.