Noll stilleståndstidsdistribution för Durable Functions

Den tillförlitliga körningsmodellen för Durable Functions kräver att orkestreringarna är deterministiska, vilket skapar ytterligare en utmaning att tänka på när du distribuerar uppdateringar. När en distribution innehåller ändringar i aktivitetsfunktionens signaturer eller orkestreringslogik misslyckas orkestreringsinstanser under flygning. Den här situationen är särskilt ett problem för instanser av långvariga orkestreringar, som kan representera timmar eller dagar av arbete.

För att förhindra att dessa fel inträffar har du flera alternativ:

• Fördröj distributionen tills alla orkestreringsinstanser som körs har slutförts.
• Använd orkestreringsversioner för att tillåta att olika versioner av orkestreringar samexisterar (rekommenderas).
• Kontrollera att alla orkestreringsinstanser som körs använder de befintliga versionerna av dina funktioner.

I följande diagram jämförs de fyra huvudstrategierna för att uppnå en distribution utan stilleståndstid för Durable Functions:

Resten av det här dokumentet beskriver dessa strategier mer detaljerat.

Versionshantering för orkestrering

Med versionsfunktionen för orkestrering kan du göra icke-bakåtkompatibla ändringar i orkestreringarna samtidigt som du undviker stilleståndstid under distributioner. Med den här inbyggda funktionen kan olika versioner av orkestreringar samexistera och köras samtidigt utan konflikter.

Med versionshantering för orkestrering:

• Varje orkestreringsinstans hämtar en version som är permanent associerad med den när den skapas.
• Arbetare som kör nyare orchestrator-versioner kan fortsätta köra äldre versionsinstanser.
• Arbetare som kör äldre orkestreringsversioner kan inte köra nyare versionsinstanser.
• Orchestrator-funktioner kan undersöka deras version och grenkörning i enlighet med detta.

Den här metoden underlättar löpande uppgraderingar där arbetare som kör olika versioner av ditt program kan samexistera på ett säkert sätt. Det är den rekommenderade strategin för program som behöver stöd för störande ändringar samtidigt som distributioner med noll driftstopp bibehålls. Versionsfunktionen för orkestrering är serverdelsoberoende, så du kan utnyttja den oavsett vilken lagringsserverdel som din Durable Function-app använder. Detaljerad vägledning för konfiguration och implementering finns i Versionshantering av orkestrering i Durable Functions.

Namnbaserad versionshantering

Definiera nya versioner av dina funktioner och lämna de gamla versionerna i funktionsappen. Som du ser i diagrammet blir en funktions version en del av dess namn. Eftersom tidigare versioner av funktioner bevaras kan orkestreringsinstanser under flygning fortsätta att referera till dem. Under tiden anropar begäranden om nya orkestreringsinstanser den senaste versionen, som din orkestreringsklientfunktion kan referera till från en appinställning.

I den här strategin måste varje funktion kopieras och dess referenser till andra funktioner måste uppdateras. Du kan göra det enklare genom att skriva ett skript. Här är ett exempelprojekt med ett migreringsskript.

Statuskontroll med fack

Medan den aktuella versionen av funktionsappen körs i produktionsplatsen distribuerar du den nya versionen av funktionsappen till mellanlagringsplatsen. Innan du byter produktions- och mellanlagringsplatser kontrollerar du om det finns orkestreringsinstanser som körs. När alla orkestreringsinstanser har slutförts kan du göra växlingen. Den här strategin fungerar när du har förutsägbara perioder när inga orkestreringsinstanser körs. Det här är den bästa metoden när orkestreringarna inte är tidskrävande och när orkestreringskörningarna inte ofta överlappar varandra.

Konfiguration av funktionsapp

Använd följande procedur för att konfigurera det här scenariot.

1. Lägg till distributionsplatser i funktionsappen för mellanlagring och produktion.

2. För varje fack anger du programinställningen AzureWebJobsStorage till anslutningen för ett delat lagringskonto. Den här anslutningen till lagringskontot används av Azure Functions-körningen för att lagra funktionernas åtkomstnycklar på ett säkert sätt. För den högsta säkerhetsnivån bör du använda en hanterad identitetsanslutning till ditt lagringskonto.

3. För varje fack skapar du en ny appinställning, DurableManagementStoragetill exempel . Ange dess värde till anslutningssträng för olika lagringskonton. Dessa lagringskonton används av Durable Functions-tillägget för tillförlitlig körning. Använd ett separat lagringskonto för varje fack. Markera inte den här inställningen som en distributionsplatsinställning. Återigen är hanterade identitetsbaserade anslutningar de säkraste.

4. I funktionsappens host.json fils durableTask-avsnitt anger du connectionStringName (Durable 2.x) eller azureStorageConnectionStringName (Durable 1.x) som namnet på appinställningen du skapade i steg 3.

Följande diagram visar den beskrivna konfigurationen av distributionsplatser och lagringskonton. I det här potentiella fördistributionsscenariot körs version 2 av en funktionsapp på produktionsplatsen, medan version 1 finns kvar i mellanlagringsplatsen.

host.json exempel

Följande JSON-fragment är exempel på inställningen anslutningssträng i host.json-filen.

Funktioner 2.0

{
  "version": 2.0,
  "extensions": {
    "durableTask": {
      "hubName": "MyTaskHub",
      "storageProvider": {
        "connectionStringName": "DurableManagementStorage"
      }
    }
  }
}

Funktioner 1.x

{
  "durableTask": {
    "azureStorageConnectionStringName": "DurableManagementStorage"
  }
}

Konfiguration av CI/CD-pipeline

Konfigurera CI/CD-pipelinen så att den endast distribueras när funktionsappen inte har några väntande eller pågående orkestreringsinstanser. När du använder Azure Pipelines kan du skapa en funktion som söker efter dessa villkor, som i följande exempel:

[FunctionName("StatusCheck")]
public static async Task<IActionResult> StatusCheck(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestMessage req,
    [DurableClient] IDurableOrchestrationClient client,
    ILogger log)
{
    var runtimeStatus = new List<OrchestrationRuntimeStatus>();

    runtimeStatus.Add(OrchestrationRuntimeStatus.Pending);
    runtimeStatus.Add(OrchestrationRuntimeStatus.Running);

    var result = await client.ListInstancesAsync(new OrchestrationStatusQueryCondition() { RuntimeStatus = runtimeStatus }, CancellationToken.None);
    return (ActionResult)new OkObjectResult(new { HasRunning = result.DurableOrchestrationState.Any() });
}

Konfigurera sedan mellanlagringsporten så att den väntar tills inga orkestreringar körs. Mer information finns i Release deployment control using gates (Versionsdistributionskontroll med portar)

Azure Pipelines kontrollerar din funktionsapp för att köra orkestreringsinstanser innan distributionen startar.

Nu ska den nya versionen av funktionsappen distribueras till mellanlagringsplatsen.

Slutligen växlar du fack.

Programinställningar som inte har markerats som inställningar för distributionsfack växlas också, så version 2-appen behåller sin referens till lagringskonto A. Eftersom orkestreringstillståndet spåras i lagringskontot fortsätter alla orkestreringar som körs i version 2-appen att köras i det nya facket utan avbrott.

Om du vill använda samma lagringskonto för båda platserna kan du ändra namnen på dina aktivitetshubbar. I det här fallet måste du hantera tillståndet för dina fack och appens HubName-inställningar. Mer information finns i Uppgiftshubbar i Durable Functions.

Ansökningsflöde

Den här strategin är den mest komplexa. Den kan dock användas för funktionsappar som inte har tid mellan att köra orkestreringar.

För den här strategin måste du skapa en programrouter framför durable functions. Den här routern kan implementeras med Durable Functions. Routern har ansvaret för att:

• Distribuera funktionsappen.
• Hantera versionen av Durable Functions.
• Dirigera orkestreringsbegäranden till funktionsappar.

Första gången en orkestreringsbegäran tas emot utför routern följande uppgifter:

1. Skapar en ny funktionsapp i Azure.
2. Distribuerar funktionsappens kod till den nya funktionsappen i Azure.
3. Vidarebefordrar orkestreringsbegäran till den nya appen.

Routern hanterar tillståndet för vilken version av appens kod som distribueras till vilken funktionsapp i Azure.

Routern dirigerar distributions- och orkestreringsbegäranden till lämplig funktionsapp baserat på den version som skickas med begäran. Den ignorerar korrigeringsversionen.

När du distribuerar en ny version av appen utan en icke-bakåtkompatibel ändring kan du öka korrigeringsversionen. Routern distribuerar till din befintliga funktionsapp och skickar begäranden för de gamla och nya versionerna av koden, som dirigeras till samma funktionsapp.

När du distribuerar en ny version av din app med en icke-bakåtkompatibel ändring kan du öka huvudversionen eller delversionen. Sedan skapar programroutern en ny funktionsapp i Azure, distribuerar till den och dirigerar begäranden för den nya versionen av din app till den. I följande diagram fortsätter körningen av orkestreringar på 1.0.1-versionen av appen att köras, men begäranden för 1.1.0-versionen dirigeras till den nya funktionsappen.

Routern övervakar statusen för orkestreringar på 1.0.1-versionen och tar bort appar när alla orkestreringar har slutförts.

Inställningar för spårningsarkiv

Varje funktionsapp bör använda separata schemaläggningsköer, eventuellt i separata lagringskonton. Om du vill köra frågor mot alla orkestreringsinstanser i alla versioner av programmet kan du dela instans- och historiktabeller i dina funktionsappar. Du kan dela tabeller genom att trackingStoreConnectionStringName konfigurera inställningarna och trackingStoreNamePrefix i filen host.json inställningar så att alla använder samma värden.

Mer information finns i Hantera instanser i Durable Functions i Azure.

Nästa steg