Nasazení bez přerušení provozu pro Durable Functions

Important

Support pro model v procesu skončí 10. listopadu 2026. Důrazně doporučujeme migrovat aplikace do izolovaného modelu pracovních procesů pro plnou podporu.

poručný model spouštění Durable Functions vyžaduje, aby orchestrace byly deterministické, což při nasazování aktualizací vytváří výzvu. Pokud nasazení obsahuje zásadní změny — například změněné podpisy funkcí aktivity nebo změněnou logiku orchestrátoru — aktuální instance orchestrace selžou. Tato situace je zvlášť problémem pro dlouhotrvající orchestrace, které mohou představovat hodiny nebo dny práce.

Note

Strategie v tomto článku předpokládají, že používáte poskytovatele Azure Storage pro Durable Functions. Pokud používáte jiného poskytovatele úložiště, doporučení nemusí platit. Strategie správy verzí orchestrace je výjimkou – funguje s jakýmkoli úložným backendem. Další informace o možnostech poskytovatele úložiště najdete v tématu Durable Functions poskytovatelé úložiště.

Následující tabulka porovnává čtyři strategie pro dosažení nasazení bez výpadku. Zvolte strategii, která nejlépe odpovídá vaší úloze:

Strategy	Kdy ho použít	Pros	Cons
Verzování orchestrace (doporučeno)	Aplikace s zásadními změnami , které potřebují více souběžných verzí orchestrace.	Umožňuje nasazení s nulovými výpadky s zásadními změnami. Integrovaná funkce vyžadující minimální konfiguraci Funguje s jakýmkoli backendem úložiště.	Vyžaduje pečlivé úpravy kódu orchestrátoru pro kompatibilitu verzí.
Verzování podle názvu	Aplikace s nečastými zásadními změnami, u kterých je preferována jednoduchost.	Jednoduše implementovat.	Zvětšená velikost aplikace funkcí v paměti a zvýšený počet funkcí. Duplikace kódu
Kontrola stavu s slotem	Systémy s krátkodobými orchestracemi (do 24 hodin) a předvídatelnými mezerami mezi prováděními.	Jednoduchý základ kódu. Nevyžaduje další správu funkční aplikace.	Vyžaduje další účet úložiště nebo správu centra úloh. Vyžaduje časové období, kdy nejsou spuštěny žádné orchestrace.
Směrování aplikací	Systémy s orchestracemi běžícími nepřetržitě (více než 24 hodin) a/nebo s často překrývajícími se spuštěními bez nečinných období.	Zpracovává nové verze systémů s nepřetržitě běžícími orchestracemi, které mají zásadní změny.	Vyžaduje inteligentní směrovač aplikací. Maximální počet aplikací funkcí povolených vaším předplatným (výchozí hodnota je 100).

Verzování orchestrace

Funkce verzování orchestrace je doporučenou strategií pro nasazení s nulovými výpadky se zásadními změnami. Umožňuje, aby různé verze orchestrací spoluexistily a spouštěly souběžně bez konfliktů.

S verzováním orchestrace:

• Každá instance orchestrace získá trvale přiřazenou verzi k ní při vytváření.
• Pracovní uzly s novějšími verzemi orchestrátoru mohou nadále spouštět instance starší verze.
• Pracovní procesy se staršími verzemi orchestrace nemůžou spouštět novější instance verzí.
• Funkce orchestrátoru můžou zkoumat svou verzi a provádění větví odpovídajícím způsobem.

Tento přístup usnadňuje postupné upgrady, kdy pracovní procesy, na kterých běží různé verze vaší aplikace, mohou bezpečně existovat. Na rozdíl od ostatních strategií v tomto článku je správa verzí na back-endu nezávislá a funguje s jakýmkoli poskytovatelem úložiště.

Úplné kroky implementace — včetně postupu konfigurace správy verzí, zpracování větvení verzí v kódu orchestrátoru a správy průběžných upgradů — najdete v tématu Orchestration Versioning.

Zbývající strategie jsou možnosti pro scénáře, kdy verzování orchestrace není vhodné.

Verzování podle názvu

V této strategii vytvoříte nové verze funkcí společně se starými verzemi ve stejné aplikaci funkcí. Verze každé funkce se stane součástí jejího názvu (například MyOrchestrator_v1, ). MyOrchestrator_v2 Vzhledem k tomu, že předchozí verze jsou zachovány, probíhající instance orchestrace na ně mohou dále odkazovat. Požadavky na nové instance orchestrace volají nejnovější verzi, na kterou může funkce klienta orchestrace odkazovat z nastavení aplikace. Tento přístup znázorňuje následující diagram.

V této strategii musí být každá funkce zkopírována a její odkazy na jiné funkce musí být aktualizovány. Můžete to usnadnit napsáním skriptu. Tady je ukázkový projekt se skriptem migrace.

Note

Tato strategie využívá sloty nasazení k zabránění výpadkům během nasazení. Podrobnější informace o tom, jak vytvářet a používat nové sloty nasazení, najdete v tématu Azure Functions sloty nasazení.

Kontrola stavu se slotem

Zatímco aktuální verze vaší aplikace funkcí běží v produkčním slotu, nasaďte novou verzi aplikace funkcí do přípravného slotu. Před prohozením produkčních a přípravných slotů zkontrolujte, jestli nejsou spuštěné instance orchestrace. Po dokončení všech instancí orchestrace můžete provést přepnutí. Tato strategie funguje, když máte předvídatelná období bez aktivních instancí orchestrace. Tento přístup je nejlepší, pokud vaše orchestrace nejsou dlouhotrvající a provádění vašich orchestrací se často nepřekrývají.

Konfigurace funkční aplikace

K nastavení tohoto scénáře použijte následující postup.

1. Přidejte sloty nasazení do funkční aplikace pro staging a produkci.

2. Pro každý slot nastavte nastavení aplikace AzureWebJobsStorage na připojení sdíleného účtu úložiště. Toto připojení účtu úložiště používá modul runtime Azure Functions k bezpečnému uložení přístupových klíčů funkce. Pro nejvyšší úroveň zabezpečení byste měli ke svému účtu úložiště použít připojení spravované identity.

3. Pro každý slot vytvořte nové nastavení aplikace, DurableManagementStoragenapříklad . Nastavte jeho hodnotu na připojovací řetězec různých účtů úložiště. Tyto účty úložiště používá rozšíření Durable Functions pro spolehlivé provedení. Pro každý slot použijte samostatný účet úložiště. Neoznačujte toto nastavení jako nastavení slotu nasazení. Spravovaná připojení založená na identitách jsou opět nejbezpečnější.

4. V oddílu durableTask ve vašem souboru host.json vaší funkční aplikace zadejte azureStorageConnectionStringName (Durable 2.x) nebo (Durable 1.x) jako název nastavení aplikace, které jste vytvořili v kroku 3.

Následující diagram ukazuje konfiguraci nasazovacích slotů a úložných účtů, která byla popsána. V tomto potenciálním scénáři předběžného nasazení běží verze 2 aplikace funkcí v produkčním slotu, zatímco verze 1 zůstává v přípravném slotu.

příklad host.json

Následující fragment JSON ukazuje nastavení připojovací řetězec v souboru host.json.

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

Note

Pro starší verze aplikací Functions 1.x použijte azureStorageConnectionStringName vlastnost přímo v oddílu durableTask místo storageProvider.connectionStringName.

Konfigurace kanálu CI/CD

Nakonfigurujte kanál CI/CD tak, aby se nasazoval jenom v případě, že vaše aplikace funkcí nemá žádné čekající nebo spuštěné instance orchestrace. Když používáte Azure Pipelines, můžete vytvořit funkci, která tyto podmínky kontroluje, jak je uvedeno v následujících příkladech v C#. Stejný vzorec platí i pro jiné jazyky – zadejte dotaz na instance orchestrace se stavem Pending nebo Running a vraťte informaci, zda nějaké existují.

Izolovaný model pracovního procesu

[Function("StatusCheck")]
public static async Task<HttpResponseData> StatusCheck(
  [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestData req,
  [DurableClient] DurableTaskClient client)
{
  var query = new OrchestrationQuery
  {
    Statuses = new[] { OrchestrationRuntimeStatus.Pending, OrchestrationRuntimeStatus.Running }
  };

  bool hasRunning = false;

  await foreach (OrchestrationMetadata instance in client.GetAllInstancesAsync(query))
  {
    hasRunning = true;
    break;
  }

  HttpResponseData response = req.CreateResponse(HttpStatusCode.OK);
  await response.WriteAsJsonAsync(new { HasRunning = hasRunning });
  return response;
}

Model v probíhajícím procesu

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

Dále nakonfigurujte přípravnou bránu tak, aby čekala, dokud nebudou žádné orchestrace spuštěny. Další informace najdete v tématu Řízení nasazení pomocí bran.

Azure Pipelines kontroluje funkční aplikaci, zda má aktivní orchestrační instance předtím, než začne nasazení.

Snímek obrazovky běžící kontroly brány nasazení Azure Pipelines pro instance orchestrace.

Nyní by se měla nová verze vaší funkční aplikace nasadit do přípravného slotu.

Nakonec prohoďte sloty.

Nastavení aplikace, která nejsou označená jako nastavení slotu nasazení, se také prohodí, takže aplikace verze 2 uchovává svůj odkaz na účet úložiště A. Vzhledem k tomu, že stav orchestrace se sleduje v účtu úložiště, všechny orchestrace spuštěné v aplikaci verze 2 budou běžet v novém slotu bez přerušení.

Pokud chcete použít stejný účet úložiště pro oba sloty, můžete změnit názvy center úloh. V tomto případě potřebujete spravovat stav slotů a nastavení HubName vaší aplikace. Další informace najdete v Task Hubs v Durable Functions.

Směrování přihlášek

Tato strategie je nejsložitější, ale je to jediná možnost pro systémy s nepřetržitě spuštěnými orchestracemi, které nikdy nemají volné okno pro výměnu slotů.

Pro tuto strategii vytvoříte před svými Durable Functions směrovač aplikací – například funkci Azure s HTTP triggery nebo instanci služby API Management, která směruje na základě hlaviček verzí. Směrovač zodpovídá za:

• Nasazení funkční aplikace
• Správa aktivní verze aplikace.
• Směrování žádostí o orchestraci do příslušné funkční aplikace na základě verze.

Při prvním přijetí žádosti o orchestraci směrovač provede následující úlohy:

1. Vytvoří novou aplikaci funkcí v Azure.
2. Nasadí kód aplikace funkcí do nové aplikace funkcí v Azure.
3. Předá žádost o orchestraci nové aplikaci.

Směrovač spravuje stav, která verze kódu vaší aplikace je nasazena do které funkční aplikace v Azure.

Směrovač směruje požadavky na nasazení a orchestraci do příslušné aplikace funkcí na základě verze odeslané s požadavkem. Ignoruje verzi opravy.

Když nasadíte novou verzi aplikace bez zásadní změny, můžete zvýšit verzi opravy. Směrovač se nasadí do vaší stávající aplikace funkcí a odešle požadavky na staré a nové verze kódu, které se směrují do stejné aplikace funkcí.

Screenshot směrování aplikace, když v nasazení Durable Functions nedošlo k žádné zásadní změně.

Když nasadíte novou verzi aplikace se zásadní změnou, můžete zvýšit hlavní nebo dílčí verzi. Pak směrovač aplikace vytvoří novou funkční aplikaci v Azure, nasadí ji a směruje požadavky na novou verzi vaší aplikace. V následujícím diagramu pokračují v běhu orchestrace ve verzi aplikace 1.0.1, ale požadavky na verzi 1.1.0 jsou směrovány do nové funkční aplikace.

Směrovač monitoruje stav orchestrací ve verzi 1.0.1 a po dokončení všech orchestrací odebere aplikace.

Nastavení úložiště sledování

Každá aplikace funkcí by měla používat samostatné fronty plánování, případně v samostatných účtech úložiště. Pokud chcete dotazovat všechny instance orchestrací ve všech verzích aplikace, můžete sdílet tabulky instancí a historie napříč aplikacemi funkcí. Můžete sdílet tabulky tak, že nakonfigurujete nastavení trackingStoreConnectionStringName a trackingStoreNamePrefix v souboru host.json tak, aby všechny používaly stejné hodnoty.

Další informace najdete v tématu Spravování instancí v Durable Functions v Azure.

Další kroky

Verzování Durable Functions