Orchestratieversiebeheer (preview)

Voorwaardelijke versiebeheer op basis van client/context

Om ervoor te zorgen dat een orkestratie een versie heeft, moet deze eerst in de client worden ingesteld. Voor de .NET SDK wordt dit gedaan via de standaarduitbreidingen voor hostbuilders, zoals hieronder wordt weergegeven:

builder.Services.AddDurableTaskClient(builder =>
{
    builder.UseDurableTaskScheduler(connectionString);
    builder.UseDefaultVersion("1.0.0");
});

public DurableTaskClient durableTaskClient(DurableTaskProperties properties) {
    // Create client using Azure-managed extensions
    return DurableTaskSchedulerClientExtensions.createClientBuilder(properties.getConnectionString())
        .defaultVersion("1.0")
        .build();
}

Zodra dat is toegevoegd, wordt voor elke orkestratie die door deze host is gestart, de versie 1.0.0 gebruikt. De versie zelf is een eenvoudige tekenreeks en accepteert elke waarde. De SDK probeert deze echter te converteren naar . NET's System.Version. Als het geconverteerd kan worden, wordt die bibliotheek gebruikt voor vergelijking. Zo niet, dan wordt een eenvoudige tekenreeksvergelijking gebruikt.

Door de versie in de client op te leveren, wordt deze ook beschikbaar in de TaskOrchestrationContext. Dit betekent dat de versie kan worden gebruikt in voorwaardelijke statements. Zolang nieuwere versies van een orkestratie de juiste versie-afbakening hebben, kunnen zowel de oude als de nieuwe versie van de orkestratie samen op dezelfde host worden uitgevoerd. Een voorbeeld van hoe de versie kan worden gebruikt, is:

[DurableTask]
class HelloCities : TaskOrchestrator<string, List<string>>
{
    private readonly string[] Cities = ["Seattle", "Amsterdam", "Hyderabad", "Kuala Lumpur", "Shanghai", "Tokyo"];

    public override async Task<List<string>> RunAsync(TaskOrchestrationContext context, string input)
    {
        List<string> results = [];
        foreach (var city in Cities)
        {
            results.Add(await context.CallSayHelloAsync($"{city} v{context.Version}"));
            if (context.CompareVersionTo("2.0.0") >= 0)
            {
                results.Add(await context.CallSayGoodbyeAsync($"{city} v{context.Version}"));
            }
        }

        Console.WriteLine("HelloCities orchestration completed.");
        return results;
    }
}

public TaskOrchestration create() {
    return ctx -> {
        List<String> results = new ArrayList<>();
        for (String city : new String[]{ "Seattle", "Amsterdam", "Hyderabad", "Kuala Lumpur", "Shanghai", "Tokyo" }) {
            results.add(ctx.callActivity("SayHello", city, String.class).await());
            if (VersionUtils.compareVersions(ctx.getVersion(), "2.0.0") >= 0) {
                // Simulate a delay for newer versions
                results.add(ctx.callActivity("SayGoodbye", city, String.class).await());
            }
        }
        ctx.complete(results);
    };
}

In dit voorbeeld hebben we een SayGoodbye activiteit toegevoegd aan de HelloCities orkestratie. Dit wordt alleen aangeroepen als de orkestratie ten minste versie 2.0.0 is. Met de eenvoudige voorwaardelijke instructie blijft elke orkestratie met een versie kleiner dan 2.0.0 functioneren en zal elke nieuwe orkestratie de nieuwe activiteit bevatten.

Wanneer clientversiebeheer gebruiken

Clientversiebeheer biedt het eenvoudigste mechanisme voor versiebeheer van orchestraties, maar interactie met de versie vereist ook de meeste programmeerwerk. In wezen biedt clientversiebeheer twee functies: de mogelijkheid om een versie in te stellen voor orkestraties en de mogelijkheid om de versie programmatisch te verwerken binnen de orkestratie. Deze moet worden gebruikt als een standaardversie gewenst is voor alle versies of als aangepaste logica rond specifieke versies vereist is.

Versiebeheer op basis van werknemers

Een extra strategie die kan worden gebruikt voor het afhandelen van versies is het instellen van worker-versies. Orkestraties hebben nog steeds een clientversie nodig om de versieset te kunnen instellen, maar met deze methode kan de gebruiker voorwaardelijke constructies in hun orkestraties vermijden. Met versiebeheer voor werknemers kan de werknemer zelf kiezen hoe het moet reageren op verschillende versies van orkestraties voordat deze orkestraties worden uitgevoerd. Om worker versiebeheer te implementeren, moeten de volgende velden worden ingesteld:

1. De versie van de worker
2. De standaardversie die wordt toegepast op suborchestraties die door de worker zijn gestart
3. De strategie die de werknemer gebruikt om af te stemmen op de versie van de orchestratie.
4. De strategie die de werknemer moet toepassen als de versie niet voldoet aan de overeenkomstige strategie.

De verschillende matchstrategieën zijn als volgt:

De verschillende foutstrategieën zijn als volgt:

Net als bij de clientversiebeheer zijn deze allemaal ingesteld via het standaard-hostbouwerpatroon:

builder.Services.AddDurableTaskWorker(builder =>
{
    builder.AddTasks(r => r.AddAllGeneratedTasks());
    builder.UseDurableTaskScheduler(connectionString);
    builder.UseVersioning(new DurableTaskWorkerOptions.VersioningOptions
    {
        Version = "1.0.0",
        DefaultVersion = "1.0.0",
        MatchStrategy = DurableTaskWorkerOptions.VersionMatchStrategy.Strict,
        FailureStrategy = DurableTaskWorkerOptions.VersionFailureStrategy.Reject,
    });
});

private static DurableTaskGrpcWorker createTaskHubServer() {
    DurableTaskGrpcWorkerBuilder builder = new DurableTaskGrpcWorkerBuilder();
    builder.useVersioning(new DurableTaskGrpcWorkerVersioningOptions(
            "1.0",
            "1.0",
            DurableTaskGrpcWorkerVersioningOptions.VersionMatchStrategy.CURRENTOROLDER,
            DurableTaskGrpcWorkerVersioningOptions.VersionFailureStrategy.REJECT));

    // Orchestrations can be defined inline as anonymous classes or as concrete classes
    builder.addOrchestration(new TaskOrchestrationFactory() {
        @Override
        public String getName() { return "HelloCities"; }

        @Override
        public TaskOrchestration create() {
            return ctx -> {
                List<String> results = new ArrayList<>();
                for (String city : new String[]{ "Seattle", "Amsterdam", "Hyderabad", "Kuala Lumpur", "Shanghai", "Tokyo" }) {
                    results.add(ctx.callActivity("SayHello", city, String.class).await());
                }
                ctx.complete(results);
            };
        }
    });

    // Activities can be defined inline as anonymous classes or as concrete classes
    builder.addActivity(new TaskActivityFactory() {
        @Override
        public String getName() { return "SayHello"; }

        @Override
        public TaskActivity create() {
            return ctx -> {
                String input = ctx.getInput(String.class);
                return "Hello, " + input + "!";
            };
        }
    });

    return builder.build();
}

De Reject foutstrategie moet worden gebruikt wanneer het gewenste gedrag is om de orkestratie opnieuw te proberen op een later tijdstip of op een andere worker. Wanneer een orchestratie wordt geweigerd, wordt deze simpelweg teruggeplaatst in de werkwachtrij. Wanneer het weer uit de wachtrij wordt gehaald, kan het op een andere werker of dezelfde terechtkomen. Het proces wordt herhaald totdat er een werknemer beschikbaar is die de orkestratie daadwerkelijk kan afhandelen. Met deze strategie kunt u implementaties naadloos verwerken waarin een orchestratie wordt bijgewerkt. Naarmate de implementatie vordert, zullen werknemers die de orkestratie niet aankunnen, deze weigeren, terwijl de werknemers die deze aankunnen, deze verwerken. De mogelijkheid om gemengde werkrollen/indelingsversies te hebben, maakt scenario's zoals blauwgroene implementaties mogelijk.

De Fail foutstrategie moet worden gebruikt wanneer er geen andere versies worden verwacht. In dit geval is de nieuwe versie een anomalie en moet geen werknemer zelfs proberen er aan te werken. De Durable Task Scheduler zal de orchestratie laten mislukken en deze in een terminale status brengen.

Wanneer versiebeheer voor medewerkers gebruiken

Versiebeheer van werkers moet worden gebruikt in scenario's waarin orkestraties van een onbekende of niet-ondersteunde versie helemaal niet mogen worden uitgevoerd. In plaats van versieafhandelingscode in de worker te plaatsen, voorkomt versiebeheer van workers dat de orkestratie ooit wordt uitgevoerd. Dit maakt veel eenvoudigere orkestratiecode mogelijk. Zonder codewijzigingen kunnen verschillende implementatiescenario's worden verwerkt, zoals eerder genoemde blauwgroene implementaties.