Implementatie zonder downtime voor Durable Functions

Het betrouwbare uitvoeringsmodel van Durable Functions vereist dat indelingen deterministisch zijn, wat een extra uitdaging vormt om rekening mee te houden wanneer u updates implementeert. Wanneer een implementatie wijzigingen in de handtekeningen van activiteitsfuncties of orchestratorlogica bevat, mislukken in-flight indelingsexemplaren. Deze situatie is met name een probleem voor exemplaren van langlopende indelingen, die uren of dagen werk kunnen vertegenwoordigen.

Om te voorkomen dat deze fouten optreden, hebt u twee opties:

  • Stel de implementatie uit totdat alle actieve indelingsexemplaren zijn voltooid.
  • Zorg ervoor dat alle actieve indelingsexemplaren gebruikmaken van de bestaande versies van uw functies.

In de volgende grafiek worden de drie belangrijkste strategieën voor een implementatie zonder downtime vergeleken voor Durable Functions:

Strategie Wanneer gebruikt u dit? Voordelen Nadelen
Versiebeheer Toepassingen die niet vaak fouten veroorzaken . Eenvoudig te implementeren. Vergroot de grootte van de functie-app in het geheugen en het aantal functies.
Duplicatie van code.
Statuscontrole met sleuf Een systeem dat geen langlopende indelingen heeft die langer dan 24 uur duren of die vaak overlappende indelingen. Eenvoudige codebasis.
Hiervoor is geen extra beheer van functie-apps vereist.
Vereist extra opslagaccount- of taakhubbeheer.
Vereist perioden waarin er geen indelingen worden uitgevoerd.
Toepassingsroutering Een systeem dat geen perioden heeft waarin indelingen niet worden uitgevoerd, zoals perioden met indelingen die langer dan 24 uur duren of met vaak overlappende indelingen. Verwerkt nieuwe versies van systemen met voortdurend actieve indelingen die wijzigingen veroorzaken. Vereist een intelligente toepassingsrouter.
Het aantal functie-apps dat is toegestaan door uw abonnement, kan maximaal worden bereikt. De standaardwaarde is 100.

In de rest van dit document worden deze strategieën uitgebreider beschreven.

Notitie

In de beschrijvingen voor deze implementatiestrategieën zonder downtime wordt ervan uitgegaan dat u de standaard Azure Storage-provider gebruikt voor Durable Functions. De richtlijnen zijn mogelijk niet geschikt als u een andere opslagprovider gebruikt dan de standaard Azure Storage-provider. Zie de documentatie over Durable Functions opslagproviders voor meer informatie over de verschillende opties voor opslagproviders en hoe deze zich verhouden.

Versiebeheer

Definieer nieuwe versies van uw functies en laat de oude versies in uw functie-app staan. Zoals u in het diagram kunt zien, wordt de versie van een functie onderdeel van de naam. Omdat eerdere versies van functies behouden blijven, kunnen in-flight indelingsexemplaren ernaar blijven verwijzen. Ondertussen wordt voor aanvragen voor nieuwe indelingsexemplaren de nieuwste versie aangeroepen, waarnaar uw indelingsclientfunctie kan verwijzen vanuit een app-instelling.

Versiebeheerstrategie

In deze strategie moet elke functie worden gekopieerd en moeten de verwijzingen naar andere functies worden bijgewerkt. U kunt het eenvoudiger maken door een script te schrijven. Hier volgt een voorbeeldproject met een migratiescript.

Notitie

Deze strategie maakt gebruik van implementatiesites om downtime tijdens de implementatie te voorkomen. Zie Azure Functions implementatiesites voor meer gedetailleerde informatie over het maken en gebruiken van nieuwe implementatiesites.

Statuscontrole met sleuf

Terwijl de huidige versie van uw functie-app wordt uitgevoerd in uw productiesite, implementeert u de nieuwe versie van uw functie-app in uw staging-site. Voordat u uw productie- en faseringssites verwisselt, controleert u of er actieve indelingsexemplaren zijn. Nadat alle indelingsexemplaren zijn voltooid, kunt u de wisseling uitvoeren. Deze strategie werkt wanneer u voorspelbare perioden hebt waarin er geen indelingsexemplaren zijn. Dit is de beste aanpak wanneer uw indelingen niet lang duren en wanneer uw indelingsuitvoeringen elkaar niet vaak overlappen.

Configuratie van functie-app

Gebruik de volgende procedure om dit scenario in te stellen.

  1. Voeg implementatiesites toe aan uw functie-app voor fasering en productie.

  2. Stel voor elke site de toepassingsinstelling AzureWebJobsStorage in op de connection string van een gedeeld opslagaccount. Dit opslagaccount connection string wordt gebruikt door de Azure Functions runtime om de toegangssleutels van de functies veilig op te slaan.

  3. Maak voor elke site een nieuwe app-instelling, DurableManagementStoragebijvoorbeeld . Stel de waarde in op de connection string van verschillende opslagaccounts. Deze opslagaccounts worden gebruikt door de extensie Durable Functions voor een betrouwbare uitvoering. Gebruik een afzonderlijk opslagaccount voor elke site. Markeer deze instelling niet als een implementatiesite-instelling.

  4. Geef connectionStringName in de sectie durableTask van het host.json-bestand van uw functie-app (Durable 2.x) of azureStorageConnectionStringName (Durable 1.x) op als de naam van de app-instelling die u in stap 3 hebt gemaakt.

In het volgende diagram ziet u de beschreven configuratie van implementatiesites en opslagaccounts. In dit mogelijke scenario voor predeployment wordt versie 2 van een functie-app uitgevoerd in de productiesite, terwijl versie 1 in de staging-site blijft.

Implementatiesites en opslagaccounts

voorbeelden van host.json

De volgende JSON-fragmenten zijn voorbeelden van de instelling connection string in het bestand host.json.

Functies 2.0

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

Functions 1.x

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

CONFIGURATIE VAN CI/CD-pijplijn

Configureer uw CI/CD-pijplijn om alleen te implementeren wanneer uw functie-app geen in behandeling zijnde of actieve indelingsexemplaren heeft. Wanneer u Azure Pipelines gebruikt, kunt u een functie maken waarmee wordt gecontroleerd op deze voorwaarden, zoals in het volgende voorbeeld:

[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() });
}

Configureer vervolgens de faseringspoort om te wachten totdat er geen indelingen worden uitgevoerd. Zie Release deployment control using gates (Release deployment control using gates) voor meer informatie

Implementatiepoort

Azure Pipelines controleert uw functie-app op het uitvoeren van indelingsexemplaren voordat de implementatie wordt gestart.

Implementatiepoort (wordt uitgevoerd)

Nu moet de nieuwe versie van uw functie-app worden geïmplementeerd in de staging-site.

Staging-site

Verwissel tot slot slots.

Toepassingsinstellingen die niet zijn gemarkeerd als instellingen voor implementatiesites, worden ook verwisseld, zodat de app van versie 2 de verwijzing naar opslagaccount A behoudt. Omdat de indelingsstatus wordt bijgehouden in het opslagaccount, worden alle indelingen die worden uitgevoerd in de versie 2-app, zonder onderbreking uitgevoerd in de nieuwe site.

Implementatiesite

Als u hetzelfde opslagaccount wilt gebruiken voor beide sites, kunt u de namen van uw taakhubs wijzigen. In dit geval moet u de status van uw sites en de HubName-instellingen van uw app beheren. Zie Taakhubs in Durable Functions voor meer informatie.

Toepassingsroutering

Deze strategie is het meest complex. Het kan echter worden gebruikt voor functie-apps die geen tijd hebben tussen het uitvoeren van indelingen.

Voor deze strategie moet u vóór uw Durable Functions een toepassingsrouter maken. Deze router kan worden geïmplementeerd met Durable Functions. De router heeft de verantwoordelijkheid voor het volgende:

  • De functie-app implementeren.
  • De versie van Durable Functions beheren.
  • Indelingsaanvragen routeren naar functie-apps.

De eerste keer dat een indelingsaanvraag wordt ontvangen, voert de router de volgende taken uit:

  1. Hiermee maakt u een nieuwe functie-app in Azure.
  2. Hiermee implementeert u de code van uw functie-app in de nieuwe functie-app in Azure.
  3. Hiermee wordt de indelingsaanvraag doorgestuurd naar de nieuwe app.

De router beheert de status van welke versie van de code van uw app wordt geïmplementeerd voor welke functie-app in Azure.

Toepassingsroutering (eerste keer)

De router stuurt implementatie- en indelingsaanvragen naar de juiste functie-app op basis van de versie die met de aanvraag is verzonden. De patchversie wordt genegeerd.

Wanneer u een nieuwe versie van uw app implementeert zonder een wijziging die fouten veroorzaakt, kunt u de patchversie verhogen. De router implementeert naar uw bestaande functie-app en verzendt aanvragen voor de oude en nieuwe versie van de code, die worden gerouteerd naar dezelfde functie-app.

Toepassingsroutering (geen wijziging die fouten veroorzaakt)

Wanneer u een nieuwe versie van uw app implementeert met een wijziging die fouten veroorzaakt, kunt u de primaire of secundaire versie verhogen. Vervolgens maakt de toepassingsrouter een nieuwe functie-app in Azure, implementeert deze naar de app en stuurt aanvragen voor de nieuwe versie van uw app naar de app. In het volgende diagram worden actieve indelingen op de 1.0.1-versie van de app uitgevoerd, maar aanvragen voor versie 1.1.0 worden doorgestuurd naar de nieuwe functie-app.

Toepassingsroutering (wijziging die fouten veroorzaakt)

De router bewaakt de status van indelingen op versie 1.0.1 en verwijdert apps nadat alle indelingen zijn voltooid.

Instellingen voor traceringsarchief

Elke functie-app moet afzonderlijke planningswachtrijen gebruiken, mogelijk in afzonderlijke opslagaccounts. Als u een query wilt uitvoeren op alle indelingsexemplaren in alle versies van uw toepassing, kunt u exemplaar- en geschiedenistabellen delen in uw functie-apps. U kunt tabellen delen door de trackingStoreConnectionStringName instellingen en trackingStoreNamePrefix te configureren in het host.json-instellingenbestand , zodat ze allemaal dezelfde waarden gebruiken.

Zie Exemplaren beheren in Durable Functions in Azure voor meer informatie.

Instellingen voor traceringsarchief

Volgende stappen