Dayanıklı İşlevler'de sürüm oluşturma zorlukları ve risk azaltma stratejileri

Dayanıklı İşlevler'de sürüm oluşturma, işlevler bir uygulamanın ömrü boyunca kaçınılmaz olarak eklendiğinden, kaldırıldığından ve değiştirildiğinden önemlidir. Dayanıklı İşlevler işlevleri daha önce mümkün olmayan yollarla zincirlemenize olanak tanır ve bu zincirleme sürüm oluşturmayı nasıl işlediğinizi etkiler.

Bu makale size yardımcı olur:

• Kod değişikliğinizin hataya neden olan bir değişiklik olup olmadığını belirleyin.
• Güvenli bir şekilde dağıtmak için doğru risk azaltma stratejisini seçin.

Hızlı strateji karşılaştırması

Eğer değişikliğinizin bozulmaya neden olduğunu zaten biliyorsanız, bir azaltma stratejisi seçmek için bu tabloyu kullanın.

Strateji	En iyi kullanım alanı:	Ayrıntılar
Orchestrasyon sürümleme (önerilir)	Çoğu uygulama, önemli değişikliklerle uyumlu değil. Yerleşik çalışma zamanı özelliği, herhangi bir depolama arka ucuyla çalışır.	Bölüme atla
Yan yana dağıtımlar	Orkestrasyon sürümlendirmesini kullanamayan veya ayrı görev hub'ları ya da depolama hesapları aracılığıyla tam yalıtıma ihtiyaç duyan uygulamalar.	Bölüme atla
Tüm uçuş içi örnekleri durdurma	Uçuş sırasında düzenlemelerin kaybedilmesinin kabul edilebilir olduğu prototipleme ve yerel geliştirme.	Bölüme atla

Tip

Çalışma zamanı düzeyinde otomatik sürüm yalıtımı sağlayan içerikli orkestrasyon sürümleme özelliğini arıyorsanız bkz. orkestrasyon sürümleme.

Önemli

Dağıtmadan önce, değişikliğinizin uyumsuzluk yaratan bir değişiklik olup olmadığını denetleyin.

• Bir etkinliğin veya varlık işlevinin adını, giriş türünü veya çıkış türünü değiştirdiniz mi?
• Orchestrator kodunda etkinliklere, alt düzenlemelere, zamanlayıcılara veya dış olaylara çağrılar eklediniz, kaldırdınız veya yeniden sıraladınız mı?
• Uçuş içi düzenlemelerin çağırabileceği bir işlevi yeniden adlandırdınız veya kaldırdınız mı?

Bunlardan herhangi birine evet yanıtı verdiyseniz, düzenleme çalıştırma hatalarından kaçınmak için aşağıdaki risk azaltma stratejilerinden birini kullanın.

Hataya neden olan değişiklik türleri

Hataya neden olan değişikliklerin birkaç örneği vardır. Bu makalede en yaygın türler ele alınmaktadır. Bunların ardındaki ana tema, işlev kodundaki değişikliklerin hem yeni hem de mevcut işlev düzenlemelerini etkilemesidir.

Etkinlik veya varlık işlev imzası değişiklikleri

İmza değişikliği işlevin adında, girişinde veya çıkışında yapılan değişikliği ifade eder. Bir etkinlik veya varlık işlevinde bu tür bir değişiklik yaparsanız, buna bağlı olan herhangi bir düzenleyici işlevi bozulabilir. Bu davranış özellikle tür açısından güvenli diller için geçerlidir. Orchestrator işlevini bu değişikliği karşılayacak şekilde güncelleştirirseniz mevcut uçuş içi örnekleri bozabilirsiniz.

Örneğin, aşağıdaki orkestratör işlevini göz önünde bulundurun.

C#

[FunctionName("FooBar")]
public static Task Run([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    bool result = await context.CallActivityAsync<bool>("Foo");
    await context.CallActivityAsync("Bar", result);
}

PowerShell

param($Context)

[bool]$Result = Invoke-DurableActivity -FunctionName 'Foo'
Invoke-DurableActivity -FunctionName 'Bar' -Input $Result

Java

@FunctionName("FooBar")
public void fooBarOrchestration(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    boolean result = ctx.callActivity("Foo", boolean.class).await();
    ctx.callActivity("Bar", result).await();
}

Bu işlev Foo'nun sonucunu alır ve Bar'a geçirir. Daha çeşitli sonuç değerlerini desteklemek için Foo'nun dönüş değerini Boole türünden Metin olarak değiştirmeniz gerektiğini farz edelim. Sonuç şöyle görünür:

C#

[FunctionName("FooBar")]
public static Task Run([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    string result = await context.CallActivityAsync<string>("Foo");
    await context.CallActivityAsync("Bar", result);
}

PowerShell

param($Context)

[string]$Result = Invoke-DurableActivity -FunctionName 'Foo'
Invoke-DurableActivity -FunctionName 'Bar' -Input $Result

Java

@FunctionName("FooBar")
public void fooBarOrchestration(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    String result = ctx.callActivity("Foo", String.class).await();
    ctx.callActivity("Bar", result).await();
}

Bu değişiklik orchestrator işlevinin tüm yeni örnekleri için düzgün çalışır ancak tüm uçuş içi örnekleri bozabilir. Örneğin, bir düzenleme örneğinin Foo adlı işlevi çağırdığı, boole değerini geri aldığı ve ardından denetim noktası kaydettiği durumu göz önünde bulundurun. İmza değişikliği bu noktada dağıtıldığında, denetim noktası oluşturulmuş örnek, çağrıyı Foo sürdürüp yeniden yürüttüğünde hemen başarısız olur. Bu hatanın nedeni, geçmiş tablosundaki sonucun boole değeri olmasıdır, ancak yeni kod bunu string olarak seri durumdan çıkarmaya çalıştığı için beklenmeyen davranışlara ve hatta tür güvenli programlama dilleri için çalışma zamanında özel durumla sonuçlanır.

Bu örnek, bir işlev imzası değişikliğinin, var olan örnekleri bozabilmesinin birçok yolundan biridir. Genel olarak, bir düzenleyicinin işlevi çağırma biçimini değiştirmesi gerekiyorsa, değişiklik büyük olasılıkla sorunlu olacaktır.

Orchestrator mantığı değişiklikleri

Sürüm oluşturma sorunlarının diğer sınıfı, orchestrator işlev kodunu uçuş içi örneklerin yürütme yolunu değiştirecek şekilde değiştirmekten gelir.

Aşağıdaki orchestrator işlevini göz önünde bulundurun:

C#

[FunctionName("FooBar")]
public static Task Run([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    bool result = await context.CallActivityAsync<bool>("Foo");
    await context.CallActivityAsync("Bar", result);
}

PowerShell

param($Context)

[bool]$Result = Invoke-DurableActivity -FunctionName 'Foo'
Invoke-DurableActivity -FunctionName 'Bar' -Input $Result

Java

@FunctionName("FooBar")
public void fooBarOrchestration(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    boolean result = ctx.callActivity("Foo", boolean.class).await();
    ctx.callActivity("Bar", result).await();
}

Şimdi mevcut iki işlev çağrısı arasına yeni bir işlev çağrısı eklemek istediğinizi varsayalım.

C#

[FunctionName("FooBar")]
public static Task Run([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    bool result = await context.CallActivityAsync<bool>("Foo");
    if (result)
    {
        await context.CallActivityAsync("SendNotification");
    }

    await context.CallActivityAsync("Bar", result);
}

PowerShell

param($Context)

[bool]$Result = Invoke-DurableActivity -FunctionName 'Foo'
if ($Result -eq $true) {
    Invoke-DurableActivity -FunctionName 'SendNotification'
}
Invoke-DurableActivity -FunctionName 'Bar' -Input $Result

Java

@FunctionName("FooBar")
public void fooBarOrchestration(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    boolean result = ctx.callActivity("Foo", boolean.class).await();
    if (result) {
        ctx.callActivity("SendNotification").await();
    }

    ctx.callActivity("Bar", result).await();
}

Bu değişiklik, SendNotification ve Foo arasına Bar yeni bir işlev çağrısı ekler. İmza değişikliği yok. Mevcut bir örnek Bar çağrısından devam ettiğinde sorun ortaya çıkar. Yeniden yürütme sırasında, eğer Foo özgün çağrı true döndürdüyse, düzenleyici SendNotification fonksiyonunu çağırır, bu da yürütme geçmişinde bulunmaz. Çalışma zamanı bu tutarsızlığı algılar ve çağrısıyla karşılaşıldığında SendNotification çağrısının beklenmesi nedeniyle bir Bar hatası oluşturur. Dayanıklı zamanlayıcılar oluşturma, dış olayları bekleme veya alt düzenleme çağırma gibi diğer dayanıklı işlemlere API çağrıları eklerken de aynı tür bir sorun oluşabilir.

Risk azaltma stratejileri

Uyarı

Kritik değişiklikleri azaltma stratejisi olmadan dağıtmak ("hiçbir şey yapma" yaklaşımı), düzenlemelerin nondeterministik düzenleme hatalarıyla başarısız olmasına, bir Running durumunda sonsuza kadar takılmasına veya performansı düşüren düşük düzeyli çalışma zamanı hatalarını tetiklemesine neden olabilir. Hataya neden olan değişiklikleri dağıtırken her zaman aşağıdaki stratejilerden birini kullanın.

Orkestrasyon sürümleme (önerilir)

Bu bölümdeki diğer stratejilerden farklı olarak, orkestrasyon sürümleme, otomatik sürüm yalıtımı sağlayan yerleşik bir çalışma zamanı özelliğidir. Ayrı dağıtımları, görev hub'larını veya depolama hesaplarını yönetmeniz gerekmez. Bunun yerine, çalışma zamanının kendisi sürüm bilgilerini izler ve düzenleme örneklerinin uyumlu çalışanlar tarafından işlenmesini sağlar.

Orkestrasyon sürümlendirme ile:

• Her orkestrasyon örneği, oluşturulduğunda kalıcı olarak kendisiyle ilişkilendirilmiş bir sürüm alır.
• Orchestrator işlevleri, eski ve yeni kod yollarını aynı kod tabanında tutarak sürüm ve dal yürütmelerini buna göre inceleyebilir.
• Daha yeni orchestrator işlev sürümlerini çalıştıran çalışanlar, eski sürümler tarafından oluşturulan düzenleme örneklerini yürütmeye devam edebilir.
• Çalışma zamanı, eski orchestrator işlev sürümlerini çalıştıran çalışanların daha yeni sürümlerin düzenlemelerini yürütmesini engeller.

Bu yaklaşım en düşük yapılandırmayı (sürüm dizesi ve isteğe bağlı eşleştirme stratejisi) gerektirir ve herhangi bir depolama sağlayıcısıyla uyumludur. Keskin değişiklikleri desteklemesi gereken uygulamalar için, kesintisiz dağıtımları korurken önerilen stratejidir.

Ayrıntılı yapılandırma ve uygulama yönergeleri için Orchestration sürümlendirme'ye bakın.

Tüm uçuş içi örnekleri durdurma

Diğer bir seçenek de tüm uçuş içi örnekleri durdurmaktır. Dayanıklı İşlevler için varsayılan Azure Depolama sağlayıcısını kullanıyorsanız, iç control-queue ve workitem-queue kuyruklarının içeriğini temizleyerek tüm örnekleri durdurun. Alternatif olarak işlev uygulamasını durdurun, bu kuyrukları silin ve uygulamayı yeniden başlatın. Uygulama yeniden başlatıldıktan sonra kuyruklar otomatik olarak yeniden oluşturulur. Önceki düzenleme örnekleri süresiz olarak "Çalışıyor" durumunda kalabilir, ancak hata iletileriyle günlüklerinizi karmaşık hale getirmez veya uygulamanıza herhangi bir zarar vermez. Bu yaklaşım, yerel geliştirme de dahil olmak üzere hızlı prototip geliştirme için idealdir.

Uyarı

Bu yaklaşım, temel alınan depolama kaynaklarına doğrudan erişim gerektirir ve Dayanıklı İşlevler tarafından desteklenen tüm depolama sağlayıcıları için uygun değildir.

Eş zamanlı dağıtımlar

Hataya neden olan değişikliklerin güvenli bir şekilde dağıtılmasını sağlamanın en iyi yolu, bunları eski sürümlerinizle yan yana dağıtmaktır. Aşağıdaki tekniklerden birini kullanabilirsiniz:

• Farklı depolama hesabı: Tüm güncelleştirmeleri farklı bir depolama hesabıyla yeni bir işlev uygulaması olarak dağıtın. Bu, yeni sürümün durumunu eski sürümden tamamen ayırır.
• Farklı görev hub'ı: İşlev uygulamasının yeni bir kopyasını aynı depolama hesabıyla ancak güncelleştirilmiş görev hub'ı adıyla dağıtın. Bu yaklaşım, eski sürüm mevcut yapıtlarını kullanmaya devam ederken yeni sürüm için yeni depolama yapıtları oluşturur.

Azure'da yan yana dağıtımlar yaparken, hem etkin hem de pasif olarak çalışacak şekilde her iki sürümü aynı anda çalıştırmak için dağıtım yuvalarını kullanabilirsiniz, erken yalnızca biri aktif üretim yuvası olarak çalışır. Yeni orkestrasyon mantığını kullanıma sunmaya hazır olduğunuzda yeni sürümü üretim yuvasına alın.

Uyarı

Bu kılavuzda Azure Depolama özel terimler kullanılır, ancak genellikle desteklenen tüm Dayanıklı İşlevler depolama sağlayıcıları için geçerlidir.

Uyarı

Dağıtım yuvası değiştirme işlemleri, HTTP ve web kancası tetikleyicileriyle en iyi şekilde çalışır. Kuyruklar veya Event Hubs gibi HTTP olmayan tetikleyiciler için tetikleyici tanımı, değiştirme işleminin bir parçası olarak güncelleştirilen bir uygulama ayarından türetilmelidir .

Sonraki Adımlar

Orkestrasyon sürümleme hakkında bilgi edinin

• Kesintisiz dağıtım stratejileri hakkında bilgi edinin
• Dayanıklı İşlevler