Versionshantering av orkestrering i Durable Functions (Azure Functions) – offentlig förhandsversion

Versionshantering av orkestrering hanterar den grundläggande utmaningen med att distribuera ändringar till orkestrerarens funktioner samtidigt som den deterministiska körningsmodellen som Durable Functions kräver bibehålls. Utan denna funktion skulle låsta förändringar i orkestrerarelogik eller aktivitetsfunktionssignaturer leda till att orkestreringsinstanser misslyckas under uppspelningen, eftersom dessa skulle bryta mot determinismkravet som säkerställer tillförlitlig körning av orkestreringen. Den här inbyggda funktionen ger automatisk versionsisolering med minimal konfiguration. Det är serverdelsoberoende, så det kan användas av appar som använder någon av Durable Functions lagringsproviders, inklusive Durable Task Scheduler.

Terminology

Den här artikeln använder två relaterade men distinkta termer:

• Orchestrator-funktion (eller helt enkelt "orchestrator"): Refererar till funktionskoden som definierar arbetsflödeslogik – mallen eller skissen för hur ett arbetsflöde ska köras.
• Orkestreringsinstans (eller helt enkelt "orkestrering"): Refererar till en specifik körning av en orkestreringsfunktion med sitt eget tillstånd, instans-ID och indata. Flera orkestreringsinstanser kan köras samtidigt från samma orkestreringsfunktion.

Att förstå den här skillnaden är avgörande för versionshantering av orkestrering, där orchestrator-funktionskoden innehåller versionsmedveten logik, medan orkestreringsinstanser är permanent associerade med en specifik version när de skapas.

Så här fungerar det

Versionsfunktionen för orkestrering fungerar enligt följande grundläggande principer:

• Versionsassociation: När en orkestreringsinstans skapas hämtar den en version som är permanent associerad med den.

• Versionsmedveten körning: Orchestrator-funktionskoden kan undersöka versionsvärdet som är associerat med den aktuella orkestreringsinstansen och grenkörningen i enlighet med detta.

• Bakåtkompatibilitet: Arbetare som kör nyare orkestreringsversioner kan fortsätta köra orkestreringsinstanser som skapats av äldre orchestrator-versioner.

• Forward Protection: Körningen förhindrar automatiskt att arbetare som kör äldre orkestreringsversioner kör orkestreringar som startas av nyare orchestrator-versioner.

Förutsättningar

Innan du använder orkestreringsversioner kontrollerar du att du har de paketversioner som krävs för programmeringsspråket.

Om du använder ett non-.NET språk (JavaScript, Python, PowerShell eller Java) med tilläggspaket måste funktionsappen referera till Tilläggspaket version 4.26.0 eller senare. extensionBundle Konfigurera intervallet i host.json så att den lägsta versionen är minst 4.26.0, till exempel:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[4.26.0, 5.0.0)"
    }
}

Mer information om hur du väljer och uppdaterar paketversioner finns i konfigurationsdokumentationen för tilläggspaket .

Grundläggande användning

Det vanligaste användningsfallet för orkestreringsversioner är när du behöver göra brytande ändringar i din orkestreringslogik samtidigt som aktiva orkestreringsinstanser fortsätter att köras med sin ursprungliga version. Allt du behöver göra är att uppdatera defaultVersion i din host.json och ändra orkestreringskoden för att kontrollera orkestreringsversionen och grenkörningen i enlighet med detta. Nu ska vi gå igenom de steg som krävs.

Steg 1: defaultVersion-konfiguration

Om du vill konfigurera standardversionen för orkestreringarna måste du lägga till eller uppdatera defaultVersion inställningen i host.json filen i Azure Functions-projektet:

{
  "extensions": {
    "durableTask": {
      "defaultVersion": "<version>"
    }
  }
}

Versionssträngen kan följa valfritt format som passar din versionsstrategi:

• Versionshantering i flera delar: "1.0.0", "2.1.0"
• Enkel numrering: "1", "2"
• Datumbaserad: "2025-01-01"
• Anpassat format: "v1.0-release"

När du har angett defaultVersionassocieras alla nya orkestreringsinstanser permanent med den versionen.

Regler för versionsjämförelse

När Strict-strategin eller CurrentOrOlder-strategin har valts (se Versionsmatchning) jämför körningen versionen av orkestreringsinstansen med defaultVersion-värdet för arbetaren med hjälp av följande regler.

• Tomma eller null-versioner behandlas som lika.
• En tom eller null-version anses vara äldre än någon definierad version.
• Om båda versionerna kan parsas som System.VersionCompareTo används metoden.
• Annars utförs skiftlägesokänslig strängjämförelse.

Steg 2: Orchestrator-funktionslogik

Om du vill implementera versionsmedveten logik i din orchestrator-funktion kan du använda kontextparametern som skickas till orchestrator för att komma åt den aktuella orkestreringsinstansens version, vilket gör att du kan förgrena orkestreringslogik baserat på versionen.

[Function("MyOrchestrator")]
public static async Task<string> RunOrchestrator(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    if (context.Version == "1.0")
    {
        // Original logic for version 1.0
        ...
    }
    else if (context.Version == "2.0")
    {
        // New logic for version 2.0
        ...
    }
    ...
}

const df = require("durable-functions");

df.app.orchestrator(function* (context) {
    if (context.df.version === "1.0") {
        // Original logic for version 1.0
        // ...
    } else if (context.df.version === "2.0") {
        // New logic for version 2.0
        // ...
    }
    // ...
});

import azure.functions as func
import azure.durable_functions as df

myApp = df.DFApp(http_auth_level=func.AuthLevel.FUNCTION)

@myApp.orchestration_trigger(context_name="context")
def orchestrator_function(context: df.DurableOrchestrationContext):
    if context.version == "1.0":
        # Original logic for version 1.0
        # ...
    elif context.version == "2.0":
        # New logic for version 2.0
        # ...
    # ...

param($Context)

if ($Context.Version -eq "1.0") {
    # Original logic for version 1.0
    # ...
} elseif ($Context.Version -eq "2.0") {
    # New logic for version 2.0
    # ...
}
# ...

@FunctionName("MyOrchestrator")
public String myOrchestrator(
    @DurableOrchestrationTrigger(name = "context") 
    TaskOrchestrationContext context) {
    
    String version = context.getVersion();
    if ("1.0".equals(version)) {
        // Original logic for version 1.0
        // ...
    } else if ("2.0".equals(version)) {
        // New logic for version 2.0
        // ...
    }
    // ...
}

• C#: context.Version == null eller context.Version is null
• JavaScript: context.df.version == null
• Python: context.version is None
• PowerShell: $null -eq $Context.Version
• Java: context.getVersion() == null Observera också att det är ekvivalent att inte ange "defaultVersion": null alls i host.json.

Vad händer efter distributionen?

Här är vad du kan förvänta dig när du distribuerar din uppdaterade orchestrator-funktion med den nya versionslogik:

• Arbetssamarbete: Arbetare som innehåller den nya orchestrator-funktionskoden startar, medan vissa arbetare med den gamla koden är potentiellt fortfarande aktiva.

• Versionstilldelning för nya instanser: Alla nya orkestreringar och underorkestreringar som skapats av de nya arbetarna får versionen från defaultVersion tilldelad till dem.

• Ny arbetskompatibilitet: Nya arbetare kan bearbeta både de nyskapade orkestreringarna och de tidigare befintliga orkestreringarna eftersom ändringarna som utfördes i steg 2 i föregående avsnitt säkerställer bakåtkompatibilitet genom versionsmedveten förgreningslogik.

• Begränsningar för gamla arbetare: Gamla arbetare får endast bearbeta orkestreringarna med en version som är lika med eller lägre än den version som anges i deras egen defaultVersion i host.json, eftersom de inte förväntas ha orchestrator-kod som är kompatibel med nyare versioner. Den här begränsningen förhindrar körningsfel och oväntat beteende.

Exempel: Ersätta en aktivitet i sekvensen

Det här exemplet visar hur du ersätter en aktivitet med en annan aktivitet mitt i en sekvens med hjälp av orkestreringsversioner.

Version 1.0

host.json konfiguration:

{
  "extensions": {
    "durableTask": {
      "defaultVersion": "1.0"
    }
  }
}

Orchestrator-funktion:

[Function("ProcessOrderOrchestrator")]
public static async Task<string> ProcessOrder(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var orderId = context.GetInput<string>();
    
    await context.CallActivityAsync("ValidateOrder", orderId);
    await context.CallActivityAsync("ProcessPayment", orderId);
    await context.CallActivityAsync("ShipOrder", orderId);
    
    return "Order processed successfully";
}

const df = require("durable-functions");

df.app.orchestrator(function* (context) {
    const orderId = context.df.getInput();
    
    yield context.df.callActivity("ValidateOrder", orderId);
    yield context.df.callActivity("ProcessPayment", orderId);
    yield context.df.callActivity("ShipOrder", orderId);
    
    return "Order processed successfully";
});

import azure.functions as func
import azure.durable_functions as df

myApp = df.DFApp(http_auth_level=func.AuthLevel.FUNCTION)

@myApp.orchestration_trigger(context_name="context")
def orchestrator_function(context: df.DurableOrchestrationContext):
    order_id = context.get_input()
    
    yield context.call_activity("ValidateOrder", order_id)
    yield context.call_activity("ProcessPayment", order_id)
    yield context.call_activity("ShipOrder", order_id)
    
    return "Order processed successfully"

param($Context)

$orderId = $Context.Input

Invoke-DurableActivity -FunctionName "ValidateOrder" -Input $orderId
Invoke-DurableActivity -FunctionName "ProcessPayment" -Input $orderId
Invoke-DurableActivity -FunctionName "ShipOrder" -Input $orderId

return "Order processed successfully"

@FunctionName("ProcessOrderOrchestrator")
public String processOrder(
    @DurableOrchestrationTrigger(name = "context") 
    TaskOrchestrationContext context) {
    
    String orderId = context.getInput(String.class);
    
    context.callActivity("ValidateOrder", orderId).await();
    context.callActivity("ProcessPayment", orderId).await();
    context.callActivity("ShipOrder", orderId).await();
    
    return "Order processed successfully";
}

Version 2.0 med rabattbearbetning

host.json konfiguration:

{
  "extensions": {
    "durableTask": {
      "defaultVersion": "2.0"
    }
  }
}

Orchestrator-funktion:

using DurableTask.Core.Settings;

[Function("ProcessOrderOrchestrator")]
public static async Task<string> ProcessOrder(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var orderId = context.GetInput<string>();

    await context.CallActivityAsync("ValidateOrder", orderId);

    if (VersioningSettings.CompareVersions(context.Version, "1.0") <= 0)
    {
        // Preserve original logic for existing instances
        await context.CallActivityAsync("ProcessPayment", orderId);
    }
    else // a higher version (including 2.0)
    {
        // New logic with discount processing (replaces payment processing)
        await context.CallActivityAsync("ApplyDiscount", orderId);
        await context.CallActivityAsync("ProcessPaymentWithDiscount", orderId);
    }
    
    await context.CallActivityAsync("ShipOrder", orderId);

    return "Order processed successfully";
}

const df = require("durable-functions");
import semver from 'semver';

df.app.orchestrator(function* (context) {
    const orderId = context.df.getInput();

    yield context.df.callActivity("ValidateOrder", orderId);

    if (compareVersions(context.df.version, "1.0") <= 0) {
        // Preserve original logic for existing instances
        yield context.df.callActivity("ProcessPayment", orderId);
    } else {
        // New logic with discount processing (replaces payment processing)
        yield context.df.callActivity("ApplyDiscount", orderId);
        yield context.df.callActivity("ProcessPaymentWithDiscount", orderId);
    }
    
    yield context.df.callActivity("ShipOrder", orderId);

    return "Order processed successfully";
});

function compareVersions(version1, version2) {
  // Feel free to implement your own version comparison logic
  const v1 = semver.coerce(version1);
  const v2 = semver.coerce(version2);

  if (!v1 || !v2) {
    throw new Error(`Invalid version string(s): "${version1}" vs "${version2}"`);
  }
  return semver.compare(v1, v2);
}

import azure.functions as func
import azure.durable_functions as df
from packaging import version

myApp = df.DFApp(http_auth_level=func.AuthLevel.FUNCTION)

@myApp.orchestration_trigger(context_name="context")
def orchestrator_function(context: df.DurableOrchestrationContext):
    order_id = context.get_input()

    yield context.call_activity("ValidateOrder", order_id)

    if compare_versions(context.version, "1.0") <= 0:
        # Preserve original logic for existing instances
        yield context.call_activity("ProcessPayment", order_id)
    else:
        # New logic with discount processing (replaces payment processing)
        yield context.call_activity("ApplyDiscount", order_id)
        yield context.call_activity("ProcessPaymentWithDiscount", order_id)
    
    yield context.call_activity("ShipOrder", order_id)

    return "Order processed successfully"

def compare_versions(version1, version2):
    # Feel free to implement your own version comparison logic
    v1 = version.parse(version1)
    v2 = version.parse(version2)

    if v1 < v2:
        return -1
    elif v1 > v2:
        return 1
    return 0

param($Context)

$orderId = $Context.Input

Invoke-DurableActivity -FunctionName "ValidateOrder" -Input $orderId

if (Compare-Version $Context.Version "1.0" -le 0) {
    # Preserve original logic for existing instances
    Invoke-DurableActivity -FunctionName "ProcessPayment" -Input $orderId
} else {
    # New logic with discount processing (replaces payment processing)
    Invoke-DurableActivity -FunctionName "ApplyDiscount" -Input $orderId
    Invoke-DurableActivity -FunctionName "ProcessPaymentWithDiscount" -Input $orderId
}

Invoke-DurableActivity -FunctionName "ShipOrder" -Input $orderId

return "Order processed successfully"

function Compare-Version([string]$version1, [string]$version2) {
    # Feel free to implement your own version comparison logic
    $v1 = [Version]$version1
    $v2 = [Version]$version2

    if ($v1 -lt $v2) { return -1 }
    elseif ($v1 -gt $v2) { return 1 }
    else { return 0 }
}

import org.apache.maven.artifact.versioning.ComparableVersion;

@FunctionName("ProcessOrderOrchestrator")
public String processOrder(
    @DurableOrchestrationTrigger(name = "taskOrchestrationContext") 
    TaskOrchestrationContext context) {
    
    String orderId = context.getInput(String.class);

    context.callActivity("ValidateOrder", orderId).await();

    if (compareVersions(context.getVersion(), "1.0") <= 0) {
        // Preserve original logic for existing instances
        context.callActivity("ProcessPayment", orderId).await();
    } else {
        // New logic with discount processing (replaces payment processing)
        context.callActivity("ApplyDiscount", orderId).await();
        context.callActivity("ProcessPaymentWithDiscount", orderId).await();
    }
    
    context.callActivity("ShipOrder", orderId).await();

    return "Order processed successfully";
}

private int compareVersions(String version1, String version2) {
    // Feel free to implement your own version comparison logic
    ComparableVersion v1 = new ComparableVersion(version1);
    ComparableVersion v2 = new ComparableVersion(version2);
    return v1.compareTo(v2);
}

Avancerad användning

För mer avancerade versionsscenarier kan du konfigurera andra inställningar för att styra hur runtime hanterar versionsöverensstämmelser och avvikelser.

Versionsmatchning

Inställningen versionMatchStrategy avgör hur körmiljön matchar orkestreringsversioner när orkestreringsfunktioner läses in. Den styr vilka orkestreringsinstanser som en arbetare kan bearbeta baserat på versionskompatibilitet.

Configuration

{
  "extensions": {
    "durableTask": {
      "defaultVersion": "<version>",
      "versionMatchStrategy": "CurrentOrOlder"
    }
  }
}

Tillgängliga strategier

• None (rekommenderas inte): Ignorera orkestreringsversionen helt. Allt arbete som tas emot bearbetas oavsett version. Den här strategin inaktiverar effektivt versionskontroll och gör att alla arbetare kan bearbeta alla orkestreringsinstanser.

• Strict: Bearbeta endast uppgifter från orkestreringar med exakt samma version som den version som anges av defaultVersion i arbetarens host.json. Den här strategin ger den högsta nivån av versionsisolering men kräver noggrann distributionssamordning för att undvika övergivna orkestrationer. Konsekvenserna av versionsmatchningsfel beskrivs i avsnittet Hantering av versionsmatchningsfel .

• CurrentOrOlder (standard): Bearbeta uppgifter från orkestreringar vars version är mindre än eller lika med den version som anges av defaultVersion i arbetarens host.json. Den här strategin möjliggör bakåtkompatibilitet, vilket gör det möjligt för nyare arbetare att hantera orkestreringar som startats av äldre orkestreringsversioner samtidigt som äldre arbetare inte kan bearbeta nyare orkestreringar. Konsekvenserna av versionsmatchningsfel beskrivs i avsnittet Hantering av versionsmatchningsfel .

Hantering av versionsmatchningsfel

Inställningen versionFailureStrategy avgör vad som händer när en orkestreringsinstansversion inte matchar den aktuella defaultVersion.

Configuration:

{
  "extensions": {
    "durableTask": {
      "defaultVersion": "<version>",
      "versionFailureStrategy": "Reject"
    }
  }
}

Tillgängliga strategier:

• Reject (standard): Bearbeta inte orkestreringen. Orkestreringsinstansen förblir i sitt aktuella tillstånd och kan göras om senare när en kompatibel arbetare blir tillgänglig. Den här strategin är det säkraste alternativet eftersom den bevarar orkestreringstillståndet.

• Fail: Orkestreringen misslyckades. Den här strategin avslutar omedelbart orkestreringsinstansen med ett feltillstånd, detta kan vara lämpligt i situationer där versionsinkonsekvenser indikerar allvarliga distributionsproblem.

Starta nya orkestreringar och underorkestreringar med specifika versioner

Som standardinställning skapas alla nya orkestreringsinstanser med den aktuella defaultVersion som anges i host.json konfigurationen. Du kan dock ha scenarier där du behöver skapa orkestreringar med en viss version, även om den skiljer sig från den aktuella standardinställningen.

När du ska använda specifika versioner:

• Gradvis migrering: Du vill fortsätta att skapa orkestreringar med en äldre version även när du har distribuerat en nyare version.
• Testscenarier: Du måste testa specifika versionsbeteenden i produktionen.
• Återställningssituationer: Du måste tillfälligt återgå till att skapa instanser med en tidigare version.
• Versionsspecifika arbetsflöden: Olika affärsprocesser kräver olika orkestreringsversioner.

Du kan åsidosätta standardversionen genom att ange ett specifikt versionsvärde när du skapar nya orkestreringsinstanser med hjälp av dirigeringsklient-API:erna. Detta ger detaljerad kontroll över vilken version varje ny orkestreringsinstans använder.

[Function("HttpStart")]
public static async Task<HttpResponseData> HttpStart(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")] HttpRequestData req,
    [DurableClient] DurableTaskClient client,
    FunctionContext executionContext)
{
    var options = new StartOrchestrationOptions
    {
        Version = "1.0"
    };
    
    string instanceId = await client.ScheduleNewOrchestrationInstanceAsync("ProcessOrderOrchestrator", orderId, options);

    // ...
}

@FunctionName("HttpStart")
public HttpResponseMessage httpStart(
    @HttpTrigger(name = "req", methods = {HttpMethod.GET, HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS) 
    HttpRequestMessage<Optional<String>> request,
    @DurableClientInput(name = "durableContext") 
    DurableClientContext durableContext,
    final ExecutionContext context) {
    
    DurableTaskClient client = durableContext.getClient();

    NewOrchestrationInstanceOptions options = new NewOrchestrationInstanceOptions().setVersion("1.0");

    String instanceId = client.scheduleNewOrchestrationInstance("ProcessOrderOrchestrator", orderId, options);

    // ...
}

Du kan också starta underorkestreringar med specifika versioner från en orkestreringsfunktion:

[Function("MainOrchestrator")]
public static async Task<string> RunMainOrchestrator(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var subOptions = new SubOrchestratorOptions
    {
        Version = "1.0"
    };
    
    var result = await context.CallSubOrchestratorAsync<string>("ProcessPaymentOrchestrator", orderId, subOptions);
    
    // ...
}

@FunctionName("MainOrchestrator")
public String runMainOrchestrator(
    @DurableOrchestrationTrigger(name = "taskOrchestrationContext") 
    TaskOrchestrationContext context) {

    NewSubOrchestrationInstanceOptions subOptions = new NewSubOrchestrationInstanceOptions().setVersion("1.0");

    String result = context.callSubOrchestrator("ProcessPaymentOrchestrator", orderId, String.class, subOptions).await();
    
    // ...
}

Ta bort äldre kodvägar

Med tiden kanske du vill ta bort legacykodvägar från dina orkestreringsfunktioner för att förenkla underhåll och minska teknisk skuld. Att ta bort kod måste dock göras noggrant för att undvika att bryta befintliga orkestreringsinstanser.

När det är säkert att ta bort äldre kod:

• Alla orkestreringsexemplar som använder den gamla versionen har slutförts: har lyckats, har misslyckats eller har blivit avslutade.
• Inga nya orkestreringsinstanser skapas med den gamla versionen
• Du har verifierat genom övervakning eller frågor att inga instanser körs med den äldre versionen
• En tillräcklig tidsperiod har passerat sedan den gamla versionen senast distribuerades (med tanke på dina krav på affärskontinuitet)

Metodtips för borttagning:

• Övervaka aktivt aktiva instanser: Använd DURABLE Functions-hanterings-API:er för att fråga efter instanser med hjälp av specifika versioner.
• Ange kvarhållningsprinciper: Definiera hur länge du tänker upprätthålla bakåtkompatibilitet för varje version.
• Ta bort stegvis: Överväg att ta bort en version i taget i stället för flera versioner samtidigt.
• Borttagning av dokument: Underhålla tydliga poster för när versioner togs bort och varför.

Metodtips

Versionshantering

• Använd versionshantering i flera delar: Anta ett konsekvent versionsschema som major.minor.patch.
• Dokumentera viktiga ändringar: Dokumentera tydligt vilka ändringar som kräver en ny version.
• Planera versionslivscykeln: Definiera när du vill ta bort äldre kodsökvägar.

Kodorganisation

• Separat versionslogik: Använd tydlig förgrening eller separata metoder för olika versioner.
• Bevara determinism: Undvik att ändra befintlig versionslogik när den har distribuerats. Om ändringar är absolut nödvändiga (till exempel kritiska felkorrigeringar) ser du till att de behåller deterministiskt beteende och inte ändrar åtgärdssekvensen, eller förväntar sig att de nyare orkestreringsversionerna misslyckas vid bearbetning av äldre orkestreringar.
• Testa noggrant: Testa alla versionssökvägar, särskilt under övergångar.

Övervakning och observerbarhet

• Loggversionsinformation: Inkludera version i loggningen för enklare felsökning.
• Övervaka versionsdistribution: Spåra vilka versioner som körs aktivt.
• Konfigurera aviseringar: Övervaka eventuella versionsrelaterade fel.

Troubleshooting

Vanliga problem

• Problem: Orkestreringsinstanser som skapats med version 1.0 misslyckas när version 2.0 har distribuerats

  • Lösning: Se till att kodvägen version 1.0 i din orkestrator förblir precis densamma. Eventuella ändringar i körningssekvensen kan bryta deterministisk repris.

• Problem: Arbetare som kör äldre orkestreringsversioner kan inte köra nya orkestreringar

  • Lösning: Detta är förväntat beteende. Körsystemet förhindrar avsiktligt äldre arbetarprocesser från att exekvera orkestreringar med nyare versioner för att upprätthålla säkerheten. Se till att alla medarbetare uppdateras till den senaste orchestratormjukvaran och att deras defaultVersion-inställning i host.json uppdateras i enlighet med detta. Du kan ändra det här beteendet om det behövs med hjälp av avancerade konfigurationsalternativ (se Avancerad användning för mer information).

• Problem: Versionsinformationen är inte tillgänglig i orchestrator (context.Version eller context.getVersion() är null, oavsett defaultVersion inställning)

  • Lösning: Kontrollera avsnittet Krav för att säkerställa att din miljö uppfyller alla krav för orkestreringsversioner.

• Problem: Orkestreringar av en nyare version gör mycket långsamma framsteg eller har fastnat helt

  • Lösning: Problemet kan ha olika rotåtgärder:
    1. Otillräckligt med nyare arbetare: Se till att ett tillräckligt antal arbetare som innehåller en likvärdig eller högre version i defaultVersion distribueras och är aktiva för att hantera nyare orkestreringar.
    2. Orkestreringsdirigeringsinterferens från äldre arbetare: Gamla arbetare kan störa dirigeringsmekanismen för orkestrering, vilket gör det svårare för nya arbetare att plocka upp orkestreringar för bearbetning. Detta kan vara särskilt märkbart när du använder vissa lagringsproviders (Azure Storage eller MSSQL). Normalt sett säkerställer Azure Functions-plattformen att gamla arbetare tas bort strax efter en distribution, så eventuella fördröjningar är vanligtvis inte betydande. Men om du använder en konfiguration som gör att du kan styra livscykeln för äldre arbetare kontrollerar du att de äldre arbetarna slutligen stängs av. Du kan också överväga att använda Durable Task Scheduler eftersom det ger en förbättrad routningsmekanism som är mindre känslig för det här problemet.

Nästa steg