Sdílet prostřednictvím

Úlohy na pozadí

  • Článek

Mnoho typů aplikací vyžaduje úlohy na pozadí, které běží nezávisle na uživatelském rozhraní (UI). Patří mezi ně dávkové úlohy, úlohy náročné na zpracování a dlouho běžící procesy, jako jsou pracovní postupy. Úlohy na pozadí se můžou provádět bez nutnosti zásahu uživatele – aplikace může spustit úlohu a potom pokračovat ve zpracování interaktivních požadavků od uživatelů. To může pomoct minimalizovat zatížení uživatelského rozhraní aplikace, což může zlepšit dostupnost a zkrátit interaktivní odezvy.

Například pokud aplikace musí vytvářet miniatury obrázků, které nahrávají uživatelé, může to udělat jako úlohu na pozadí a uložit miniaturu do úložiště, když je dokončená – bez nutnosti nechat uživatele čekat na dokončení procesu. Stejným způsobem může uživatel zadávající objednávku zahájit na pozadí pracovní postup, který objednávku zpracovává, zatímco uživatelské rozhraní umožňuje uživateli pokračovat v procházení webové aplikace. Po dokončení úlohy na pozadí se můžou aktualizovat uložená data objednávky a odeslat e-mail uživateli, který objednávku potvrdí.

Když zvažujete, jestli chcete úlohu implementovat jako úlohu na pozadí, hlavním kritériem je to, jestli úloha může běžet bez zásahu uživatele a bez nutnosti, aby uživatelské rozhraní muselo na dokončení úlohy počkat. Úlohy, které vyžadují čekání uživatele nebo uživatelského rozhraní na jejich dokončení, nemusí být jako úlohy na pozadí vhodné.

Typy úloh na pozadí

Úlohy na pozadí obvykle zahrnují jeden nebo několik z následujících typů úloh:

  • Úlohy náročné na prostředky procesoru, jako jsou matematické výpočty a analýzy strukturálního modelu.
  • Úlohy náročné na V/V, jako je například provádění řady transakcí s úložištěm nebo indexování souborů.
  • Dávkové úlohy, jako jsou noční aktualizace dat nebo naplánovaná zpracování.
  • Dlouho běžící pracovní postupy, například vyřizování objednávek nebo zřizování služeb a systémů.
  • Zpracování citlivých dat, kdy je úloha předána ke zpracování do bezpečnějšího umístění. Například nemusíte chtít zpracovávat citlivá data v rámci webové aplikace. Místo toho můžete použít vzor, jako je model Gatekeeper, k přenosu dat do izolovaného procesu na pozadí, který má přístup k chráněnému úložišti.

Aktivační události

Úlohy na pozadí lze inicializovat několika různými způsoby. Spadají do jedné z následujících kategorií:

  • Triggery řízené událostmi. Úloha je spuštěna v reakci na událost, obvykle akci provedenou uživatelem nebo krok v pracovním postupu.
  • Triggery řízené plánem. Úloha se vyvolá podle plánu na základě časovače. Může se jednat o opakovaný plán nebo jednorázové volání, které je nastavené na později.

Triggery řízené událostmi

Událostmi řízené vyvolání používá ke spuštění úlohy na pozadí trigger. Příklady použití triggerů řízených událostmi:

  • Uživatelské rozhraní nebo jiná úloha umístí zprávu do fronty. Zpráva obsahuje data o akci, která proběhla, jako je například zadání objednávky uživatelem. Úloha na pozadí naslouchá této frontě a zjistí příchod nové zprávy. Přečte zprávu a použije obsažená data jako vstup pro úlohu na pozadí. Tento model se označuje jako asynchronní komunikace založená na zprávách.
  • Uživatelské rozhraní nebo jiná úloha uloží nebo aktualizuje hodnotu v úložišti. Úlohy na pozadí monitoruje úložiště a zjišťuje změny. Přečte data a použije je jako vstup pro úlohu na pozadí.
  • Uživatelské rozhraní nebo jiná úloha odešle požadavek na koncový bod, jako je identifikátor URI HTTPS, nebo rozhraní API, které je zveřejněné jako webová služba. Předá data, která jsou nutná k dokončení úlohy na pozadí, jako součást požadavku. Koncový bod nebo webová služba vyvolá úlohu na pozadí, která použije data jako vstup.

Typické příklady úloh, které jsou vhodné k vyvolání řízenému událostmi, zahrnují zpracování obrázků, pracovní postupy, odesílání informací vzdáleným službám, odesílání e-mailových zpráv a zřizování nových uživatelů ve víceklientských aplikacích.

Triggery řízené plánem

Plánem řízené vyvolání používá ke spuštění úlohy na pozadí časovač. Příklady použití triggerů řízených plánem:

  • Časovač spuštěný místně v aplikaci nebo jako součást operačního systému aplikace pravidelně vyvolává úlohu na pozadí.
  • Časovač, který běží v jiné aplikaci, jako je Azure Logic Apps, pravidelně odesílá požadavek do rozhraní API nebo webové služby. Rozhraní API nebo webová služba vyvolá úlohu běžící na pozadí.
  • Samostatný proces nebo aplikace spustí časovač, který způsobí, že úloha běžící na pozadí se vyvolá za určitou dobu nebo v určitý čas.

Typické příklady úloh, které jsou vhodné k plánem řízenému vyvolání, zahrnují dávkové rutiny (jako je aktualizace seznamů souvisejících produktů pro uživatele na základě jejich nedávného chování), úlohy běžného zpracování dat (třeba aktualizace indexů nebo generování kumulovaných výsledků), analýzy dat pro denní sestavy, čištění uchovávaných dat a kontroly konzistence dat.

Pokud používáte úlohy řízené plánem, které musí běžet jako jediná instance, mějte na paměti následující:

  • Při škálování výpočetní instance, kde je spuštěný plánovač (jako je virtuální počítač používající naplánované úlohy Windows), dostanete víc instancí se spuštěným plánovačem. Ty můžou spustit víc instancí úlohy. Další informace o tom najdete v tomto blogovém příspěvku o idempotenci.
  • Pokud úlohy běží po dobu delší, než je doba mezi událostmi plánovače, může plánovač spustit další instanci úlohy před dokončením předchozí.

Vracení výsledků

Úlohy na pozadí se spouští asynchronně v samostatném procesu nebo i v samostatném umístění, z uživatelského rozhraní nebo z procesu, který úlohu na pozadí vyvolá. V ideálním případě jsou úlohy na pozadí operace "aktivovat a zapomenout" a jejich průběh provádění nemá žádný vliv na uživatelské rozhraní nebo volající proces. To znamená, že volající proces nečeká na dokončení úlohy. Proto nemůže automaticky rozpoznat ukončení úlohy.

Pokud potřebujete, aby úloha na pozadí komunikovala s volající úlohou a oznamovala průběh nebo dokončení, musíte pro to implementovat mechanismus. Zde je několik příkladů:

  • Zapisujte do úložiště hodnotu ukazatele stavu, která je přístupná uživatelskému rozhraní nebo volající úloze a je možné tuto hodnotu sledovat a kontrolovat. Další data, která úloha běžící na pozadí musí vracet volajícímu, jde umístit do stejného úložiště.
  • Vytvořte frontu odpovědí, které uživatelské rozhraní nebo volající naslouchá. Úloha na pozadí může do fronty posílat zprávy, které uvádějí stav a dokončení. Data, která úloha běžící na pozadí musí vracet volajícímu, jde umístit do zpráv. Pokud používáte Azure Service Bus, můžete k implementaci této funkce použít vlastnosti ReplyTo a CorrelationId.
  • Zveřejněte z úlohy na pozadí rozhraní API nebo koncový bod, které může uživatelské rozhraní nebo volající použít k získání informací o stavu. Data, která úloha běžící na pozadí musí vracet volajícímu, jde zahrnout do odpovědi.
  • Zařiďte, aby úloha na pozadí volala zpět uživatelské rozhraní nebo volajícího prostřednictvím rozhraní API a v předdefinovaných bodech nebo při dokončení hlásila stav. To jde udělat prostřednictvím událostí vyvolaných místně nebo pomocí mechanismu publikování a odběru. Data, která úloha běžící na pozadí musí vracet volajícímu, jde zahrnout do požadavku nebo datové části události.

Hostitelské prostředí

Úlohy na pozadí můžete hostovat pomocí celé řady různých služeb platformy Azure:

  • Azure Web Apps a WebJobs. WebJobs můžete použít k provedení vlastních úloh v celé řadě různých typů skriptů nebo spustitelných programů v kontextu webové aplikace.
  • Funkce Azure Functions. Funkce můžete použít pro úlohy na pozadí, které dlouho neběží. Dalším případem použití je, že vaše úloha je už hostovaná v plánu služby App Service a je nedostatečně využitá.
  • Virtuální počítače Azure. Pokud máte službu Windows nebo chcete použít plánovače úloh Windows, je běžné hostovat vaše úlohy na pozadí v rámci vyhrazeného virtuálního počítače.
  • Azure Batch. Batch je služba platformy, která plánuje výpočetně náročné práce ke spuštění ve spravované kolekci virtuálních počítačů. Může automaticky škálovat výpočetní prostředky.
  • Azure Kubernetes Service (AKS) Azure Kubernetes Service poskytuje spravované hostitelské prostředí pro Kubernetes v Azure.
  • Azure Container Apps. Azure Container Apps umožňuje vytvářet bezserverové mikroslužby založené na kontejnerech.

Následující části popisují tyto možnosti podrobněji a obsahují důležité informace, které vám pomůžou zvolit příslušnou možnost.

Azure Web Apps a WebJobs

Azure WebJobs můžete použít k provedení vlastních úloh jako úloh na pozadí v rámci webové aplikace Azure. WebJobs běží jako nepřetržitý proces v kontextu webové aplikace. WebJobs se také spouští v reakci na událost triggeru z Azure Logic Apps nebo externích faktorů, jako jsou změny objektů blob úložiště a front zpráv. Úlohy jde spustit a zastavit na vyžádání a korektně vypnout. V případě selhání se nepřetržitě běžící webová úloha automaticky restartuje. Opakování a akce při chybě se dají konfigurovat.

Během konfigurace webové úlohy:

  • Pokud chcete, aby úloha reagovala na trigger řízený událostmi, měli byste ji nakonfigurovat jako Spouštět nepřetržitě. Skript nebo program je uložený ve složce s názvem site/wwwroot/app_data/jobs/continuous.
  • Pokud chcete, aby úloha reagovala na trigger řízený plánem, měli byste ji nakonfigurovat jako Spouštět podle plánu. Skript nebo program je uložený ve složce s názvem site/wwwroot/app_data/jobs/triggered.
  • Pokud při konfiguraci úlohy zvolíte možnost Spouštět na vyžádání, provede se při spuštění stejný kód jako u možnosti Spouštět podle plánu.

Azure WebJobs běží v rámci sandboxu webové aplikace. To znamená, že mají přístup k proměnným prostředí a sdílejí s webovou aplikací informace, jako jsou připojovací řetězce. Úloha má přístup k jedinečnému identifikátoru počítače, ve kterém běží. Připojovací řetězec s názvem AzureWebJobsStorage poskytuje přístup k frontám, objektům blob a tabulkám azure Storage pro data aplikací a přístup ke službě Service Bus pro zasílání zpráv a komunikaci. Připojovací řetězec s názvem AzureWebJobsDashboard poskytuje přístup k souborům protokolu akcí úlohy.

Azure WebJobs mají následující vlastnosti:

  • Zabezpečení: WebJobs jsou chráněné přihlašovacími údaji nasazení webové aplikace.
  • Podporované typy souborů: WebJobs můžete definovat pomocí skriptů příkazů (), dávkových souborů (.cmd.bat), skriptů PowerShellu (.ps1), skriptů prostředí Bash (), skriptů PHP (.php.sh), skriptů Pythonu (.py), kódu JavaScriptu (.js) a spustitelných programů (.exe, .jara dalších).
  • Nasazení: Skripty a spustitelné soubory můžete nasadit pomocí webu Azure Portal, pomocí sady Visual Studio, pomocí sady Azure WebJobs SDK nebo jejich zkopírováním přímo do následujících umístění:
    • Pro aktivované provádění: site/wwwroot/app_data/jobs/triggered/{název úlohy}
    • Pro nepřetržité provádění: site/wwwroot/app_data/jobs/continuous/{název úlohy}
  • Protokolování: Console.Out se považuje (je označeno) za INFO. Console.Error se považuje za ERROR. Monitorování a diagnostické informace jsou k dispozici pomocí webu Azure Portal. Soubory protokolů je možné stáhnout přímo z webu. Ukládají se v následujících umístěních:
    • Pro aktivované provádění: Vfs/data/jobs/triggered/jobName
    • Pro nepřetržité provádění: Vfs/data/úlohy/průběžné/název úlohy
  • Konfigurace: WebJobs můžete konfigurovat pomocí portálu, rozhraní REST API a PowerShellu. K zadání konfiguračních informací pro úlohu můžete použít konfigurační soubor s názvem settings.job ve stejném kořenovém adresáři jako skript úlohy. Příklad:
    • { "stopping_wait_time": 60 }
    • { "is_singleton": true }

Důležité informace

  • Ve výchozím nastavení se WebJobs škálují s webovou aplikací. Ale můžete nakonfigurovat úlohy, které se spouští na jedné instanci, nastavením konfigurační vlastnosti is_singleton na hodnotu true. WebJobs s jednou instancí jsou užitečné pro úlohy, které nechcete škálovat nebo spouštět jako více souběžných instancí, například reindexace, analýza dat a podobné úlohy.
  • Pokud chcete minimalizovat dopad úloh na výkon webové aplikace, zvažte vytvoření prázdné instance webové aplikace Azure v novém plánu služby App Service pro hostování dlouhotrvajících webových úloh nebo webových úloh náročných na prostředky.

Azure Functions

Možnost podobná službě WebJobs je Azure Functions. Tato služba je bezserverová, která je nejvhodnější pro triggery řízené událostmi, které běží po krátkou dobu. Funkci lze také použít ke spouštění naplánovaných úloh prostřednictvím aktivačních událostí časovače při konfiguraci spouštění v nastavených časech.

Azure Functions není doporučenou možností pro velké dlouhotrvající úlohy, protože můžou způsobit neočekávané problémy s vypršením časového limitu. V závislosti na plánu hostování je však možné je zvážit pro aktivační události řízené podle plánu.

Důležité informace

Pokud se očekává, že úloha na pozadí poběží po krátkou dobu v reakci na událost, zvažte spuštění úkolu v plánu Consumption. Doba provádění je konfigurovatelná až do maximální doby. Funkce, která běží pro delší náklady, více. Také úlohy náročné na procesor, které spotřebovávají více paměti, můžou být dražší. Pokud jako součást úkolu použijete další triggery pro služby, fakturují se samostatně.

Plán Premium je vhodnější, pokud máte velký počet úloh, které jsou krátké, ale očekává se, že se budou spouštět nepřetržitě. Tento plán je dražší, protože potřebuje více paměti a procesoru. Výhodou je, že můžete používat funkce, jako je integrace virtuální sítě.

Plán Dedicated je nejvhodnější pro úlohy na pozadí, pokud na něm už vaše úloha běží. Pokud máte nevyužité virtuální počítače, můžete je spustit na stejném virtuálním počítači a sdílet náklady na výpočetní prostředky.

Další informace naleznete v těchto článcích:

Azure Virtual Machines

Úlohy na pozadí můžou být implementovány způsobem, který brání jejich nasazení do Azure Web Apps nebo tyto možnosti nemusí být vhodné. Typické příklady jsou služby Windows nebo nástroje a spustitelné programy jiných dodavatelů. Dalším příkladem můžou být programy vytvořené pro spouštěcí prostředí, které se liší od prostředí hostujícího aplikaci. Například to může být program pro Unix nebo Linux, který chcete spustit z aplikace Windows nebo .NET. Můžete si vybrat z nabídky operačních systémů pro virtuální počítač Azure a spustit službu nebo spustitelný soubor na tomto virtuálním počítači.

Pokud potřebujete určit, kdy se má používat Virtual Machines, přečtěte si srovnání Azure App Services, Cloud Services a Virtual Machines. Informace o možnostech virtuálních počítačů najdete v tématu Velikosti virtuálních počítačů s Windows v Azure. Další informace o operačních systémech a předem sestavených imagí, které jsou k dispozici pro Virtual Machines, najdete na webu Azure Virtual Machines Marketplace.

Chcete-li úlohu na pozadí iniciovat na samostatném virtuálním počítači, máte celou řadu možností:

  • Úloh můžete spustit na vyžádání přímo z vaší aplikace odesláním požadavku na koncový bod, který úloha zveřejňuje. Tím se předají všechna data, která úloha vyžaduje. Tento koncový bod úlohu vyvolá.
  • Můžete nakonfigurovat spuštění úlohy podle plánu pomocí plánovače nebo časovače, který je k dispozici ve vybraném operačním systému. Například ve Windows můžete spustit skripty a úlohy pomocí Plánovače úloh systému Windows. Nebo pokud máte na virtuálním počítači nainstalovaný SQL Server, můžete spustit skripty a úlohy pomocí Agenta SQL Serveru.
  • Azure Logic Apps můžete použít k zahájení úlohy přidáním zprávy do fronty, na které úkol naslouchá, nebo odesláním požadavku do rozhraní API, které úloha zveřejňuje.

Další informace o tom, jak můžete iniciovat úlohy na pozadí, najdete v dřívější části Triggery.

Důležité informace

Při rozhodování, jestli se mají nasadit úlohy na pozadí ve virtuálním počítači Azure, zvažte následující body:

  • Hostování úloh na pozadí v samostatném virtuálním počítači Azure poskytuje flexibilitu a umožňuje přesné řízení spuštění, provádění, plánování a přidělování prostředků. Zvýší se tak ale běhové náklady, pokud virtuální počítač musí být nasazený jenom ke spouštění úloh na pozadí.
  • Neexistuje žádné zařízení ke sledování úloh na webu Azure Portal a žádné možnosti automatického restartování neúspěšných úloh, i když můžete monitorovat základní stav virtuálního počítače a spravovat ho pomocí rutin Azure Resource Manageru. Neexistují však žádná zařízení k řízení procesů a vláken ve výpočetních uzlech. Používání virtuálních počítačů bude obvykle vyžadovat další úsilí k implementaci mechanismu, který shromažďuje data z instrumentace v úloze a z operačního systému ve virtuálním počítači. Jedno řešení, které může být vhodné, je použít System Center Management Pack pro Azure.
  • Zvažte vytvoření monitorovacích sond, které jsou zveřejněné prostřednictvím koncových bodů protokolu HTTP. Kód pro tyto sondy by měl provádět kontroly stavu, shromažďovat provozní informace a statistiky, nebo shromažďovat informace o chybách a vracet je zpět aplikaci pro správu. Další informace najdete v modelu monitorování koncových bodů stavu.

Další informace naleznete v tématu:

Azure Batch

Vezměte v úvahu Azure Batch, pokud potřebujete spustit velké, paralelní úlohy vysokovýkonného výpočetního prostředí (HPC) mezi desítkami, stovkami nebo tisíci virtuálními počítači.

Služba Batch zřizuje virtuální počítače, přiřazuje jim úlohy, spouští úlohy a sleduje jejich průběh. Batch může automaticky škálovat virtuální počítače na více instancí v reakci na zatížení. Batch také poskytuje plánování úloh. Azure Batch podporuje virtuální počítače s Linuxem i Windows.

Důležité informace

Batch dobře funguje pro vnitřně paralelní úlohy. Dokáže taky provádět paralelní výpočty s fází redukce na konci nebo spustit aplikace rozhraní MPI (Message Passing Interface) pro paralelní úlohy, které vyžadují předávání zpráv mezi uzly.

Úloha služby Azure Batch běží na fondu uzlů (virtuálních počítačů). Jedním z přístupů je přidělení fondu jenom v případě potřeby a jeho odstranění po dokončení úlohy. To maximalizuje využití, protože uzly nezahálejí, ale úloha musí čekat na přidělení uzlů. Případně můžete vytvořit fond předem. Tento přístup minimalizuje čas, který je potřeba pro spuštění úlohy, ale může vést k tomu, že máte nečinné uzly. Další informace najdete v tématu Životnost fondu a výpočetního uzlu.

Další informace naleznete v tématu:

Azure Kubernetes Service

Azure Kubernetes Service (AKS) spravuje hostované prostředí Kubernetes, což usnadňuje nasazování a správu kontejnerizovaných aplikací.

Kontejnery můžou být užitečné pro spouštění úloh na pozadí. Některé výhody tohoto postupu:

  • Kontejnery podporují hostování s vysokou hustotou. Úlohy na pozadí můžete v kontejneru izolovat a do každého virtuálního počítače umístit několik kontejnerů.
  • Orchestrátor kontejnerů zpracovává interní vyrovnávání zatížení, konfiguraci interní sítě a další konfigurační úlohy.
  • Kontejnery jde podle potřeby spustit nebo zastavit.
  • Azure Container Registry umožňuje registrovat kontejnery v rámci Azure. To poskytuje výhody zabezpečení, ochrany osobních údajů a blízkosti.

Důležité informace

  • Jsou nutné znalosti toho, jak používat orchestrator kontejnerů. V závislosti na sadě dovedností vašeho týmu DevOps to může nebo nemusí být problém.

Další informace naleznete v tématu:

Azure Container Apps

Azure Container Apps umožňuje vytvářet bezserverové mikroslužby založené na kontejnerech. Mezi charakteristické rysy kontejnerových aplikací patří:

Důležité informace

Azure Container Apps neposkytuje přímý přístup k podkladovým rozhraním API Kubernetes. Pokud potřebujete přístup k rozhraním API Kubernetes a řídicí rovině, měli byste použít službu Azure Kubernetes Service. Pokud ale chcete vytvářet aplikace ve stylu Kubernetes a nevyžadujete přímý přístup ke všem nativním rozhraním API Kubernetes a správě clusterů, služba Container Apps poskytuje plně spravované prostředí na základě osvědčených postupů. Z těchto důvodů může mnoho týmů preferovat vytváření mikroslužeb kontejnerů pomocí Azure Container Apps.

Další informace naleznete v tématu:

První aplikaci kontejneru můžete začít vytvářet pomocí rychlých startů.

dělení na části

Pokud se rozhodnete zahrnout úlohy na pozadí do existující výpočetní instance, musíte zvážit, jak to ovlivní atributy kvality výpočetní instance a samotné úlohy na pozadí. S rozhodnutím, jestli úlohy umístit společně do existující výpočetní instance nebo je rozdělit do samostatné výpočetní instance, vám pomůžou tyto faktory:

  • Dostupnost: Úlohy na pozadí nemusí potřebovat stejnou úroveň dostupnosti jako jiné části aplikace, zejména uživatelské rozhraní a další části, které se přímo podílí na interakci s uživatelem. Úlohy na pozadí můžou být tolerantnější z hlediska latence, opakovaných selhání připojení a dalších faktorů ovlivňujících dostupnost, protože operace je možné zařadit do fronty. Musí však být k dispozici dostatečná kapacita, aby se zabránilo zálohování požadavků, které můžou blokovat fronty a ovlivňovat aplikaci jako celek.

  • Škálovatelnost: Úlohy na pozadí pravděpodobně budou mít jiné požadavky na škálovatelnost než uživatelské rozhraní a interaktivní části aplikace. Škálování uživatelského rozhraní může být nezbytné ke splnění špiček v poptávce, zatímco během méně zaneprázdněných instancí výpočetních instancí se můžou dokončit nevyrovnané úlohy na pozadí.

  • Odolnost: Selhání výpočetní instance, která je pouze hostitelem úloh na pozadí, nemusí fatálně ovlivnit aplikaci jako celek, pokud je možné požadavky na tyto úlohy zařadit do fronty nebo odložit, dokud úlohy nebudou opět dostupné. Pokud je možné výpočetní instanci nebo úlohy restartovat v příslušném intervalu, nemusí to mít vliv na uživatele aplikace.

  • Zabezpečení: Úlohy na pozadí můžou mít jiné požadavky na zabezpečení nebo jiná omezení zabezpečení než uživatelské rozhraní nebo jiné části aplikace. Díky použití samostatné výpočetní instance můžete pro úlohy určit jiné prostředí zabezpečení. S využitím modelů, jako je Vrátný, můžete také izolovat výpočetní instance na pozadí od uživatelského rozhraní za účelem maximalizace zabezpečení a oddělení.

  • Výkon: Pro úlohy na pozadí můžete zvolit typ výpočetní instance tak, aby odpovídala konkrétním požadavkům úloh na výkon. To může znamenat použití levnější možnosti výpočetního prostředí, pokud úlohy nevyžadují stejné možnosti zpracování jako uživatelské rozhraní, nebo větší instance, pokud vyžadují další kapacitu a prostředky.

  • Možnosti správy: Úlohy na pozadí můžou mít jiný rytmus vývoje a nasazení než hlavní kód aplikace nebo uživatelské rozhraní. Jejich nasazení do samostatné výpočetní instance může zjednodušit aktualizace a správu verzí.

  • Náklady: Přidávání výpočetních instancí pro provádění úloh na pozadí zvyšuje náklady na hosting. Měli byste pečlivě zvážit kompromisy mezi dodatečnou kapacitou a těmito dalšími náklady.

Další informace najdete v modelu volby vedoucího procesu a modelu Konkurenční spotřebitelé.

Konflikty

Pokud máte více instancí úlohy na pozadí, může se stát, že budou soupeřit o přístup k prostředkům a službám, jako jsou databáze a úložiště. Tento souběžný přístup může vést ke kolizi prostředků, což může způsobit konflikty v dostupnosti těchto služeb a integritě dat v úložišti. Kolizi prostředků můžete vyřešit pomocí přístupu využívajícího pesimistické zamykání. Ten brání souběžnému přístupu soupeřících instancí úlohy ke službě nebo poškození dat.

Dalším způsobem řešení konfliktů je definovat úlohy na pozadí jako jednoznačné, aby vždy byla spuštěná pouze jedna instance. Tím se však eliminují výhody spolehlivosti a výkonu, které může poskytovat konfigurace s více instancemi. To platí zejména v případě, že uživatelské rozhraní dokáže zajistit dostatečné množství práce, které zaměstná více než jednu úlohu na pozadí.

Je důležité zajistit, aby úlohu na pozadí bylo možné automaticky restartovat a aby měla dostatečnou kapacitu pro zvládnutí špiček v poptávce. Toho můžete dosáhnout přidělením výpočetní instance s dostatečnými prostředky, implementací mechanismu zařazování do fronty, který může ukládat požadavky pro pozdější provedení po poklesu poptávky, nebo použitím kombinace těchto technik.

Koordinace

Úlohy na pozadí můžou být složité a k dosažení výsledku nebo splnění všech požadavků můžou vyžadovat několik jednotlivých úkolů. V těchto scénářích je běžné rozdělit úlohu na menší diskrétní kroky neboli dílčí úlohy, které může provádět několik příjemců. Vícekrokové úlohy můžou být efektivnější a flexibilnější, protože jednotlivé kroky je možné opakovaně používat ve více úlohách. Tyto kroky je také snadné přidat a odebrat nebo změnit jejich pořadí.

Koordinace několika úloh a kroků může být náročná, ale existují tři běžné modely, které můžete při implementaci řešení použít jako vodítko:

  • Rozložení úlohy na několik opakovaně použitelných kroků. Po aplikaci se může požadovat, aby na zpracovávaných informacích prováděla různé úlohy s různou složitostí. Jasným, ale nepřizpůsobitelným přístupem k implementaci této aplikace může být provádění tohoto zpracování v podobě monolitického modulu. Tento přístup však pravděpodobně omezí možnosti refaktorování kódu, jeho optimalizace nebo opakovaného použití v případě, že se části stejného zpracování vyžadují jinde v rámci aplikace. Další informace najdete v modelu Kanály a filtry.

  • Správa provádění kroků pro úlohu. Aplikace může provádět úlohy skládající se z několika kroků (některé z těchto kroků můžou volat vzdálené služby nebo přistupovat ke vzdáleným prostředkům). Jednotlivé kroky můžou být navzájem nezávislé, ale orchestruje je logika aplikace, která úlohu implementuje. Další informace najdete v tématu Model plánovače agenta supervisor.

  • Správa obnovení kroků úloh, které selžou. Aplikace může potřebovat vrátit zpět práci prováděnou pomocí posloupnosti kroků (které společně definují operaci s konečnou konzistencí) v případě, že se některé kroky nezdaří. Další informace naleznete v modelu kompenzační transakce.

Důležité informace o odolnosti

Úlohy na pozadí musí být odolné, aby pro aplikaci mohly zajišťovat spolehlivé služby. Při plánování a návrhu úloh na pozadí zvažte následující body:

  • Úlohy na pozadí musí být schopné řádně zpracovat restartování bez poškození dat nebo zavedení nekonzistence do aplikace. U dlouhotrvajících nebo vícekrokových úloh zvažte použití kontrolních bodů prostřednictvím ukládání stavu úloh do odolného úložiště nebo jako zpráv do fronty, pokud je to vhodné. Ve zprávě ve frontě můžete například uchovávat informace o stavu a přírůstkově aktualizovat v těchto informacích o stavu průběh úlohy, aby se úloha mohla zpracovat od posledního známého dobrého kontrolního bodu místo toho, aby se začínalo znovu od začátku. Pokud používáte fronty Azure Service Bus, můžete stejný scénář umožnit pomocí relací zpráv. Relace umožňují ukládání a načítání stavu zpracování aplikace pomocí metod SetState a GetState. Další informace o návrhu spolehlivých vícekrokových procesů a pracovních postupů najdete v modelu Plánovač agenta Supervisor.

  • Pokud ke komunikaci s úlohami na pozadí používáte fronty, tyto fronty můžou fungovat jako vyrovnávací paměť pro ukládání požadavků odesílaných do úloh, zatímco je zatížení aplikace vyšší než obvykle. To umožní úlohám dohnat uživatelské rozhraní v době menší vytíženosti. Také to znamená, že restartování nebude blokovat uživatelské rozhraní. Další informace najdete v modelu vyrovnávání zatížení na základě fronty. Pokud jsou některé úlohy důležitější než jiné, zvažte implementaci modelu Prioritní fronta, abyste zajistili, že tyto úlohy běží před méně důležitými.

  • Úlohy na pozadí, které jsou spouštěné zprávami nebo které zprávy zpracovávají, musí být navržené tak, aby zvládly nekonzistence, jako jsou například zprávy přicházející v jiném pořadí, zprávy opakovaně způsobující chybu (často označované jako nezpracovatelné zprávy) a zprávy doručené více než jednou. Zvažte použití těchto zdrojů:

    • Zprávy, které je potřeba zpracovat v určitém pořadí, jako jsou zprávy měnící data na základě jejich stávající hodnoty (například přidáním hodnoty ke stávající hodnotě), nemusí přicházet v původním pořadí, ve kterém byly odeslané. Případně je můžou kvůli rozdílnému zatížení jednotlivých instancí zpracovávat různé instance úlohy na pozadí v jiném pořadí. Zprávy, které je potřeba zpracovat v určitém pořadí, by měly zahrnovat pořadové číslo, klíč nebo nějaký jiný indikátor, pomocí kterého můžou úlohy na pozadí zajistit jejich zpracování ve správném pořadí. Pokud používáte službu Azure Service Bus, můžete k zaručení správného pořadí doručení použít relace zpráv. Nicméně pokud je to možné, je obvykle efektivnější navrhovat procesy tak, aby na pořadí zpráv nezáleželo.

    • Úloha na pozadí obvykle bude prohlížet zprávy ve frontě, což je dočasně skryje před ostatními příjemci zpráv. Po úspěšném zpracování pak zprávy odstraní. Pokud úloha na pozadí při zpracování nějaké zprávy selže, tato zpráva se ve frontě znovu objeví, jakmile vyprší časový limit prohlížení. Zpracuje se jinou instancí úlohy nebo během dalšího cyklu zpracování této instance. Pokud zpráva v příjemci soustavně způsobuje chybu, zablokuje úlohu, frontu a nakonec i samotnou aplikaci, jakmile se fronta zaplní. Proto je důležité nezpracovatelné zprávy detekovat a odebírat je z fronty. Pokud používáte Službu Azure Service Bus, můžou se zprávy, které způsobí chybu, přesunout automaticky nebo ručně do přidružené fronty nedoručených zpráv.

    • Fronty jsou mechanismem zaručujícím alespoň jedno doručení, ale stejnou zprávu můžou doručit více než jednou. Pokud navíc úloha na pozadí selže po zpracování zprávy, ale před jejím odstraněním z fronty, bude tato zpráva opět k dispozici ke zpracování. Úlohy na pozadí by měly být idempotentní, což znamená, že zpracování stejné zprávy vícekrát nezpůsobí chybu nebo nekonzistenci dat aplikace. Některé operace jsou přirozeně idempotentní, například nastavení uložené hodnoty na konkrétní novou hodnotu. Nicméně operace, jako je například přidání hodnoty ke stávající uložené hodnotě bez kontroly, jestli je uložená hodnota stále stejná jako v době původního odeslání zprávy, způsobí nekonzistence. Fronty Azure Service Bus je možné nakonfigurovat tak, aby automaticky odebíraly duplikované zprávy. Další informace o problémech s doručováním aspoň jednou zpráv najdete v doprovodných materiálech k idempotentnímu zpracování zpráv.

    • Některé systémy zasílání zpráv, jako je Azure Queue Storage a fronty Azure Service Bus, podporují vlastnost počtu de-queue, která označuje, kolikrát byla zpráva načtena z fronty. To může být užitečné při zpracování opakovaných a nezpracovatelných zpráv. Další informace najdete v tématech Úvod k asynchronnímu zasílání zpráv a Model idempotence.

Důležité informace o škálování a výkonu

Úlohy na pozadí musí nabízet dostatečný výkon, aby se zajistilo, že nebudou blokovat aplikaci nebo způsobovat nekonzistence kvůli zpožděným operacím v době zatížení systému. Výkon se obvykle zlepšuje škálováním výpočetních instancí, které jsou hostiteli úloh na pozadí. Při plánování a návrhu úloh na pozadí zvažte následující body související se škálovatelností a výkonem:

  • podpora Azure automatické škálování (horizontální navýšení kapacity i horizontální navýšení kapacity) na základě aktuální poptávky a zatížení nebo předdefinovaného plánu pro nasazení hostovaná službou Web Apps a Virtual Machines. Pomocí této funkce zajistíte, aby aplikace jako celek měla dostatečné výkonové schopnosti, a to při současné minimalizaci nákladů na její běh.

  • Pokud úlohy na pozadí mají jinou funkci výkonu než ostatní části aplikace (například uživatelské rozhraní nebo komponenty, jako je vrstva přístupu k datům), hostování úloh na pozadí v samostatné výpočetní službě umožňuje, aby uživatelské rozhraní a úlohy na pozadí škálovaly nezávisle na správě zatížení. Pokud má více úloh na pozadí výrazně odlišné možnosti výkonu, zvažte jejich rozdělení a nezávislé škálování jednotlivých typů. Mějte však na paměti, že to může zvýšit náklady za běhu.

  • Pouhé škálování výpočetních prostředků nemusí být dostatečné, aby se zabránilo ztrátě výkonu při zatížení. Možná budete muset škálovat také fronty úložiště a další prostředky, abyste zabránili tomu, že se z jednoho bodu celého řetězu zpracování stane kritický bod. Zvažte také další omezení, jako je maximální propustnost úložiště a dalších služeb, které aplikace a úlohy na pozadí využívají.

  • Úlohy na pozadí musí být navržené pro škálování. Musí být například schopné dynamicky detekovat počet používaných front úložiště, aby mohly naslouchat zprávám z odpovídající fronty nebo do odpovídající fronty zprávy odesílat.

  • Ve výchozím nastavení se webové úlohy škálují společně se svou přidruženou instancí Azure Web Apps. Pokud však chcete, aby se webová úloha spouštěla pouze jako jedna instance, můžete vytvořit soubor Settings.job obsahující data JSON { "is_singleton": true }. Tím se v Azure vynutí spuštění pouze jedné instance webové úlohy i v případě, že existuje více instancí přidružené webové aplikace. Tato technika může být užitečná pro plánované úlohy, které se musí spustit pouze jako jedna instance.

Další kroky