Sdílet prostřednictvím

Úlohy na pozadí

Mnoho typů aplikací vyžaduje úlohy na pozadí, které běží nezávisle na uživatelském rozhraní. Mezi příklady patří dávkové úlohy, úlohy náročné na zpracování a dlouhotrvající procesy, jako jsou pracovní postupy. Úlohy na pozadí je možné spouštět bez nutnosti interakce uživatele – aplikace může úlohu spustit a pak pokračovat v 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 snížit dobu interaktivní odezvy.

Pokud je třeba, aby aplikace vygenerovala miniatury obrázků, které uživatelé nahráli, může to udělat jako úlohu na pozadí a uložit miniaturu do úložiště po dokončení – bez nutnosti čekat na dokončení procesu. Stejným způsobem může uživatel, který zadá objednávku, zahájit pracovní postup na pozadí, který objednávku zpracuje, zatímco uživatelské rozhraní umožňuje uživateli pokračovat v procházení webové aplikace. Po dokončení úlohy na pozadí může aktualizovat uložená data objednávek a odeslat uživateli e-mail, který objednávku potvrdí.

Pokud zvažujete, jestli se má úloha implementovat jako úloha na pozadí, hlavními kritérii je to, jestli se úloha může spustit bez zásahu uživatele a bez nutnosti čekat na dokončení úlohy. Úlohy, které vyžadují, aby uživatel nebo uživatelské rozhraní čekali, než se dokončí, nemusí být vhodné jako úlohy na pozadí.

Typy úloh na pozadí

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

  • Úlohy náročné na procesor, jako jsou matematické výpočty nebo analýza strukturálního modelu.
  • Úlohy náročné na vstupně-výstupní operace, například provádění řady transakcí úložiště nebo indexování souborů.
  • Dávkové úlohy, jako jsou noční aktualizace dat nebo plánované zpracování.
  • Dlouhotrvající pracovní postupy, jako je plnění objednávek nebo zřizování služeb a systémů.
  • Zpracování citlivých dat, ve kterém je úloha předána do bezpečnějšího umístění pro zpracování. Například možná nebudete chtít zpracovávat citlivá data v rámci webové aplikace. Místo toho můžete použít vzor, jako je Vzor gatekeeper k přenosu dat do izolovaného procesu na pozadí, který má přístup k chráněnému úložišti.

Spouštěče

Úlohy na pozadí je možné zahájit několika různými způsoby. Spadají do jedné z následujících kategorií:

  • Triggery řízené událostmi Úkol se spustí v reakci na událost, obvykle akci prováděnou uživatelem nebo krokem v pracovním postupu.
  • Spouštěče řízené plánem Úkol se spouští podle časového plánu. Může se jednat o opakovaný plán nebo jednorázové vyvolání, které je určeno pro pozdější čas.

Spouštěče řízené událostmi

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

  • Uživatelské rozhraní nebo jiná úloha umístí zprávu do fronty. Zpráva obsahuje data o akci, která se proběhla, například o tom, že uživatel zadal objednávku. Úloha na pozadí naslouchá této frontě a rozpozná příchod nové zprávy. Přečte zprávu a použije v ní data jako vstup do úlohy 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. Úloha na pozadí monitoruje úložiště a detekuje změny. Čte data a používá je jako vstup pro běžící úlohu na pozadí.
  • Uživatelské rozhraní nebo jiná úloha odešle požadavek na koncový bod, například identifikátor URI HTTPS nebo rozhraní API, které je zveřejněné jako webová služba. Předá data potřebná 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 svůj vstup.

Mezi typické příklady úloh, které jsou vhodné pro vyvolání řízené událostmi, patří zpracování obrázků, pracovní postupy, odesílání informací do vzdálených služeb, odesílání e-mailových zpráv a zřizování nových uživatelů ve víceklientských aplikacích.

Plánované spouštěče

Volání řízené plánem používá časovač ke spuštění úlohy na pozadí. Mezi příklady použití triggerů řízených podle plánu patří:

  • Č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 na pozadí.
  • Samostatný proces nebo aplikace spustí časovač, který způsobí vyvolání úlohy na pozadí jednou po zadaném časovém zpoždění nebo v určitém čase.

Mezi typické příklady úloh, které jsou vhodné pro volání řízené podle plánu, patří rutiny dávkového zpracování (například aktualizace seznamů souvisejících produktů pro uživatele na základě jejich nedávného chování), běžné úlohy zpracování dat (například aktualizace indexů nebo generování kumulovaných výsledků), analýza dat pro denní sestavy, čištění dat a kontroly konzistence dat.

Pokud používáte úlohu řízenou plánem, která se musí spustit jako jedna instance, mějte na paměti následující skutečnosti:

  • Pokud se škáluje výpočetní instance, na které běží plánovač (například virtuální počítač s naplánovanými úlohami Windows), budete mít spuštěných více instancí plánovače. Je možné spustit více instancí úkolu. Další informace o tom najdete v tomto blogovém příspěvku o idempotenci.
  • Pokud se úkoly spouští déle, než je období mezi událostmi plánovače, může plánovač spustit jinou instanci úlohy, zatímco předchozí instance stále běží.

Vrácení výsledků

Úlohy na pozadí se spouštějí asynchronně v samostatném procesu nebo dokonce v samostatném umístění z uživatelského rozhraní nebo procesu, který vyvolal úlohu na pozadí. 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í úkolů. Proto nemůže automaticky rozpoznat, kdy úkol skončí.

Pokud potřebujete, aby úkol na pozadí komunikoval s volajícím úkolem za účelem indikace průběhu nebo dokončení, musíte pro to implementovat mechanismus. Mezi příklady patří:

  • Napište hodnotu ukazatele stavu do úložiště, které je přístupné pro úlohu uživatelského rozhraní nebo volajícího, která může tuto hodnotu v případě potřeby monitorovat nebo kontrolovat. Další data, která musí úloha na pozadí vrátit volajícímu, se dají umístit do stejného úložiště.
  • Vytvořte frontu odpovědí, na které uživatelské rozhraní nebo volající naslouchá. Úloha na pozadí může posílat zprávy do fronty, které označují stav a dokončení. Data, která musí úloha na pozadí vrátit volajícímu, mohou být umístěna do zpráv. Pokud používáte Azure Service Bus, můžete k implementaci této funkce použít vlastnosti ReplyTo a CorrelationId .
  • Vystavte API nebo koncový bod úlohy na pozadí, k nimž může mít přístup uživatelské rozhraní nebo volající, aby získali informace o stavu. Data, která musí úloha na pozadí vrátit volajícímu, mohou být zahrnuta v odpovědi.
  • Nechte úlohu na pozadí stručně informovat uživatelské rozhraní nebo volajícího prostřednictvím rozhraní API, aby oznamovala stav v předdefinovaných bodech nebo po dokončení. Může se jednat o události vyvolané místně nebo prostřednictvím mechanismu publikování a přihlášení k odběru. Data, která musí úloha na pozadí vrátit volajícímu, mohou být zahrnuta do datové části požadavku nebo 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 webové úlohy. WebJobs můžete použít ke spouštění vlastních úloh na základě řady různých typů skriptů nebo spustitelných programů v kontextu webové aplikace.
  • Azure Functions. Funkce můžete použít pro úlohy na pozadí, které dlouho neběží. Dalším případem použití je, když je vaše pracovní zátěž už hostovaná v plánu služby App Service a je nevyužívaná.
  • Virtuální počítače Azure. Pokud máte službu Windows nebo chcete použít Plánovač úloh systému Windows, je běžné hostovat úlohy na pozadí na vyhrazeném virtuálním počítači.
  • Azure Batch. Batch je služba platformy, která plánuje, aby se práce náročná na výpočetní výkon spouštěla na 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 ke spouštění vlastních úloh jako úloh na pozadí v rámci webové aplikace Azure. WebJobs běží v kontextu vaší webové aplikace jako průběžný proces. WebJobs se také spouští v reakci na spuštění z Azure Logic Apps nebo externích faktorů, jako jsou změny blobů úložiště a fronty zpráv. Úlohy je možné spustit a zastavit na vyžádání a řádně vypnout. Pokud se nepřetržitě spuštěná webová úloha nezdaří, automaticky se restartuje. Možnosti opakování a chyb jsou konfigurovatelné.

Při konfiguraci WebJobu:

  • Pokud chcete, aby úloha reagovala na trigger řízený událostmi, měli byste ji nakonfigurovat jako nepřetržitě spuštěnou. Skript nebo program se uloží do složky 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 Spustit podle plánu. Skript nebo program se uloží do složky s názvem site/wwwroot/app_data/jobs/triggered.
  • Pokud při konfiguraci úlohy zvolíte možnost Spustit na vyžádání , spustí se při spuštění stejný kód jako Spustit podle plánu .

Azure WebJobs běží v sandboxu webové aplikace. To znamená, že mají přístup k proměnným prostředí a sdílejí informace, jako jsou připojovací řetězce, s webovou aplikací. Úloha má přístup k jedinečnému identifikátoru počítače, na kterém je úloha spuštěná. Připojovací řetězec s názvem AzureWebJobsStorage poskytuje přístup k frontám, objektům blob a tabulkám služby 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í charakteristiky:

  • Zabezpečení: Webové úlohy jsou chráněné přihlašovacími údaji pro 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 (.sh.php), 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é spuštění: site/wwwroot/app_data/jobs/triggered/{název úlohy}
    • Pro průběžné spouštění: site/wwwroot/app_data/jobs/continuous/{název úlohy}
  • Protokolování: Console.Out je považováno (označeno) za INFO. Console.Error se považuje za CHYBU. Přístup k informacím o monitorování a diagnostice můžete získat pomocí webu Azure Portal. Soubory protokolu si můžete stáhnout přímo z webu. Ukládají se v následujících umístěních:
    • Pro vyvolané spuštění: Vfs/data/jobs/triggered/jobName
    • Pro průběžné spouštění: Vfs,data/jobs/continuous/jobName
  • Konfigurace: WebJobs můžete nakonfigurovat pomocí portálu, rozhraní REST API a PowerShellu. Konfigurační soubor s názvem settings.job můžete použít ve stejném kořenovém adresáři jako skript úlohy k poskytnutí konfiguračních informací pro úlohu. Například:
    • { "stopping_wait_time": 60 }
    • { "is_singleton": pravda }

Úvahy

  • Ve výchozím nastavení se webové úlohy škálují s webovou aplikací. Úlohy však můžete nakonfigurovat tak, aby běžely v jedné instanci tak, že nastavíte vlastnost konfigurace is_singleton na hodnotu true. Webové úlohy s jednou instancí jsou užitečné pro úlohy, které nechcete škálovat ani spouštět jako souběžné více instancí, jako je například přeindexování, 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 (cloudové funkce od Microsoftu)

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.

Úvahy

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ěží déle, stojí 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 najdete 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 systému Windows a nástroje třetích stran a spustitelné programy. Dalším příkladem mohou být programy napsané pro spouštěcí prostředí, které se liší od toho, co je hostitelem aplikace. Může to být například program systému Unix nebo Linux, který chcete spustit z aplikace systému Windows nebo .NET. Pro virtuální počítač Azure si můžete vybrat z celé řady operačních systémů a na daném virtuálním počítači spustit službu nebo spustitelný soubor.

Pokud si chcete vybrat, kdy se mají virtuální počítače používat, podívejte se na porovnání služeb 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 připravených obrazech, které jsou k dispozici pro virtuální počítače, naleznete na Azure Virtual Machines Marketplace.

Pokud chcete zahájit úlohu na pozadí na samostatném virtuálním počítači, máte řadu možností:

  • Úlohu můžete spustit přímo z aplikace odesláním požadavku do koncového bodu, který úloha zveřejňuje. Tím se předá všechna data, která úloha vyžaduje. Tento koncový bod spustí úlohu.
  • Úlohu můžete nakonfigurovat tak, aby běžela podle plánu pomocí plánovače nebo časovače, který je k dispozici ve zvoleném operačním systému. Například ve Windows můžete pomocí Plánovače úloh systému Windows spouštět skripty a úlohy. Nebo pokud máte na virtuálním počítači nainstalovaný SQL Server, můžete pomocí agenta SQL Serveru spouštět skripty a úlohy.
  • Azure Logic Apps můžete použít k zahájení úlohy přidáním zprávy do fronty, kterou úloha sleduje, nebo odesláním požadavku na API, které úloha zpřístupňuje.

Další informace o tom, jak zahájit úlohy na pozadí, najdete v předchozí části Triggery .

Úvahy

Při rozhodování o nasazení úloh na pozadí ve virtuálním počítači Azure zvažte následující body:

  • Hostování úloh na pozadí na samostatném virtuálním počítači Azure poskytuje flexibilitu a umožňuje přesnou kontrolu nad zahájením, spouštěním, plánováním a přidělováním prostředků. Pokud se ale virtuální počítač musí nasadit jenom pro spouštění úloh na pozadí, zvýší se náklady na běh.
  • Na portálu Azure není žádné zařízení pro monitorování úkolů ani automatická možnost restartování selhaných úkolů—i když můžete sledovat základní stav virtuálního počítače a spravovat ho pomocí cmdletů Azure Resource Manageru. Ve výpočetních uzlech ale nejsou k dispozici žádná zařízení pro řízení procesů a vláken. Použití virtuálního počítače obvykle bude 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žití sady System Center Management Pack pro Azure.
  • Můžete zvážit vytvoření monitorovacích sond, které jsou dostupné prostřednictvím koncových bodů HTTP. Kód těchto sond může provádět kontroly stavu, shromažďovat provozní informace a statistiky – nebo kompletovat informace o chybách a vracet je do aplikace pro správu. Další informace najdete v modelu monitorování koncových bodů stavu.

Další informace najdete tady:

Azure Batch

Pokud potřebujete spouštět velké, paralelní úlohy vysokovýkonného výpočetního prostředí (HPC) napříč desítkami, stovkami nebo tisíci virtuálních počítačů, zvažte Službu Azure Batch .

Služba Batch zřídí virtuální počítače, přiřadí úkoly virtuálním počítačům, spustí úlohy a sleduje průběh. Služba Batch může automaticky škálovat virtuální počítače v reakci na úlohu. Batch také poskytuje plánování úloh. Azure Batch podporuje virtuální počítače s Linuxem i Windows.

Úvahy

Služba Batch funguje dobře s vnitřně paralelními úlohami. Může také provádět paralelní výpočty s krokem redukce na konci nebo spouštět aplikace MPI (Message Passing Interface) pro paralelní úlohy, které vyžadují předávání zpráv mezi uzly.

Úloha Azure Batch běží ve fondu uzlů (virtuálních počítačů). Jedním z přístupů je vyčlenění prostředků pouze v případě potřeby a jejich následné odstranění po dokončení úlohy. Tím se maximalizuje využití, protože uzly nejsou nečinné, ale úloha musí počkat na přidělení uzlů. Případně můžete předem vytvořit fond. Tento přístup minimalizuje dobu potřebnou ke spuštění úlohy, ale může vést k tomu, že uzly zůstávají nečinné. Další informace najdete v tématu Životnost fondu a výpočetního uzlu.

Další informace najdete tady:

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í. Mezi výhody patří:

  • Kontejnery podporují hostování s vysokou hustotou. Izolovat úlohu na pozadí v kontejneru můžete při umístění více kontejnerů do každého virtuálního počítače.
  • Orchestrátor kontejnerů zpracovává interní vyrovnávání zatížení, konfiguruje interní síť a další úlohy konfigurace.
  • Kontejnery je možné podle potřeby spustit a zastavit.
  • Azure Container Registry umožňuje registrovat kontejnery v rámci hranic Azure. To přináší výhody zabezpečení, ochrany osobních údajů a blízkosti.

Úvahy

  • Vyžaduje pochopení toho, jak používat orchestrátor kontejnerů. V závislosti na sadě dovedností vašeho týmu DevOps to může nebo nemusí být problém.

Další informace najdete tady:

Azure Container Apps (aplikace pro kontejnery)

Azure Container Apps umožňuje vytvářet bezserverové mikroslužby založené na kontejnerech. Charakteristické rysy aplikací Container zahrnují:

Úvahy

Azure Container Apps neposkytuje přímý přístup k základním rozhraním API Kubernetes. Pokud potřebujete přístup k rozhraním API Kubernetes a k řídicí rovině, měli byste použít Azure Kubernetes Service. Pokud byste chtěli vytvářet aplikace ve stylu Kubernetes a nepotřebujete přímý přístup ke všem nativním API Kubernetes a správě clusteru, Container Apps poskytuje plně spravovaný zážitek založený na osvědčených postupech. Z těchto důvodů může mnoho týmů preferovat vytváření mikroslužeb kontejnerů pomocí Azure Container Apps.

Další informace najdete tady:

Můžete začít vytvářet svou první aplikaci pro kontejnery pomocí rychlých průvodců.

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í. Tyto faktory vám pomohou rozhodnout, zda chcete úkoly umístit společně do existujícího výpočetního prostředí nebo je oddělit do samostatného výpočetního prostředí.

  • Dostupnost: Úlohy na pozadí nemusí mít stejnou úroveň dostupnosti jako jiné části aplikace, zejména uživatelské rozhraní a další části, které jsou přímo zapojeny do interakce uživatele. Úlohy na pozadí můžou být odolnější vůči latenci, opakovaným selháním připojení a dalším faktorům, které ovlivňují dostupnost, protože operace se dají zařadit do fronty. Musí však existovat dostatečná kapacita, aby se zabránilo hromadění požadavků, které by mohly blokovat fronty a ovlivnit aplikaci celkově.

  • Škálovatelnost: Úlohy na pozadí budou pravděpodobně mít jiný požadavek 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ě rušných období lze dokončit nevyřízené úlohy na pozadí díky menšímu počtu výpočetních instancí.

  • Odolnost: Selhání výpočetní instance, která pouze hostuje úlohy na pozadí, nemusí závažně ovlivnit aplikaci jako celek, pokud se požadavky na tyto úlohy dají zařadit do fronty nebo odložit, dokud nebude úloha znovu 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 omezení než uživatelské rozhraní nebo jiné části aplikace. Pomocí samostatné výpočetní instance můžete pro úlohy zadat jiné prostředí zabezpečení. Pomocí vzorů, jako je Gatekeeper, můžete také izolovat výpočetní instance na pozadí od uživatelského rozhraní, aby se maximalizovalo zabezpečení a oddělení.

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

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

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

Další informace najdete ve vzoru volby vůdce a vzoru konkurenčních spotřebitelů.

Konflikty

Pokud máte více exemplářů úlohy na pozadí, je možné, že budou konkurovat při přístupu 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 kolizím prostředků, což může způsobit konflikty v dostupnosti služeb a integrity dat v úložišti. Kolize prostředků můžete vyřešit pomocí pesimistického zamykání. Tím se zabrání tomu, aby konkurenční instance úlohy souběžně přistupovaly ke službě nebo poškodily data.

Dalším přístupem k řešení konfliktů je definování úloh na pozadí jako jediného typu, takže je spuštěná pouze jedna instance. Tím ale eliminujete výhody spolehlivosti a výkonu, které může poskytnout konfigurace s více instancemi. To platí zejména v případě, že uživatelské rozhraní dokáže poskytnout dostatek práce, aby bylo zaneprázdněno více než jeden úkol na pozadí.

Je důležité zajistit, aby se úloha na pozadí automaticky restartovala a aby byla dostatečná kapacita 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, který zařazuje požadavky do fronty pro pozdější spuštění při poklesu poptávky, nebo pomocí 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 úkol do menších diskrétních kroků nebo dílčích úkolů, které může provést více vykonavatelů. Úlohy s více kroky můžou být efektivnější a flexibilnější, protože jednotlivé kroky můžou být opakovaně použitelné ve více úlohách. Je také snadné přidat, odebrat nebo upravit pořadí kroků.

Koordinace několika úloh a kroků může být náročná, ale existují tři běžné vzory, které můžete použít k vedení implementace řešení:

  • Rozdělení úkolu do několika opakovaně použitelných kroků Aplikace může být nutná k provádění různých úloh s různou složitostí informací, které zpracovává. Jednoduchým, ale nepružným přístupem k implementaci této aplikace může být provedení tohoto zpracování jako monolitický modul. Tento přístup ale pravděpodobně sníží příležitosti k refaktoringu kódu, jeho optimalizaci nebo opakovanému použití, pokud se části stejného zpracování vyžadují jinde v aplikaci. Další informace najdete v modelu Kanály a filtry.

  • Správa provádění kroků pro úlohu Aplikace může provádět úlohy, které tvoří řadu kroků (některé z nich můžou vyvolat 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 modelu Plánovač agentů Supervisor.

  • Zvládání obnovy pro kroky úkolu, které selžou. Aplikace může potřebovat vrátit zpět práci prováděnou řadou kroků (které společně definují nakonec konzistentní operaci), pokud jeden nebo více kroků selže. Další informace naleznete v modelu kompenzační transakce.

Úvahy o odolnosti

Úlohy na pozadí musí být odolné, aby mohla aplikace poskytovat spolehlivé služby. Při plánování a navrhování ú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ího bodu uložením stavu úloh do trvalého úložiště nebo jako zprávy ve frontě, pokud je to vhodné. Můžete například zachovat informace o stavu ve zprávě ve frontě a přírůstkově aktualizovat tyto informace o stavu průběhem úkolu, aby bylo možné úkol zpracovat z posledního známého dobrého kontrolního bodu – místo restartování od začátku. Pokud používáte fronty služby Azure Service Bus, můžete stejný scénář povolit pomocí relací zpráv. Sezení umožňují uložit a načíst stav 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.

  • Když ke komunikaci s úlohami na pozadí používáte fronty, fronty mohou fungovat jako vyrovnávací paměť pro ukládání požadavků, které jsou odesílány nim, zatímco je aplikace vystavena větším než obvyklým zatížením. To umožňuje úkolům synchronizovat se s uživatelským rozhraním během méně vytížených období. Také to znamená, že restartování nebude blokovat uživatelské rozhraní. Další informace najdete v Queue-Based vzoru vyrovnávání zatížení. 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í iniciované zprávami nebo procesovými zprávami musí být navržené tak, aby zpracovávaly nekonzistence, jako jsou zprávy přicházející mimo pořadí, zprávy, které opakovaně způsobují chybu (často označované jako zprávy o jedu) a zprávy, které se doručují více než jednou. Vezměte v úvahu následující skutečnosti:

    • Zprávy, které musí být zpracovány v určitém pořadí, například zprávy, které mění data na základě existující hodnoty dat (například přidání hodnoty do existující hodnoty), nemusí docházet do původního pořadí, ve kterém byly odeslány. Případně je různé instance úlohy na pozadí mohou zpracovat v odlišném pořadí vzhledem k rozdílnému zatížení každé instance. Zprávy, které musí být zpracovány v určitém pořadí, by měly obsahovat pořadové číslo, klíč nebo jiný indikátor, který můžou úlohy na pozadí použít k zajištění jejich zpracování ve správném pořadí. Pokud používáte Azure Service Bus, můžete pomocí relací zpráv zaručit pořadí doručení. Je však obvykle efektivnější, pokud je to možné, navrhnout proces tak, aby pořadí zpráv nebylo důležité.

    • Úloha na pozadí obvykle zobrazí náhled zpráv ve frontě, která je dočasně skryje před ostatními příjemci zpráv. Potom zprávy po úspěšném zpracování odstraní. Pokud úloha na pozadí selže při zpracování zprávy, tato zpráva se znovu zobrazí ve frontě po vypršení časového limitu náhledu. Bude zpracována jinou instancí úlohy nebo během dalšího cyklu zpracování této instance. Pokud zpráva stále způsobuje chybu v příjemci, zablokuje úlohu, frontu a nakonec i samotnou aplikaci, když se fronta zcela naplní. Proto je důležité detekovat a odstraňovat jedové zprávy 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 používají mechanismy doručování, které zaručují doručení alespoň jednou, ale mohou doručit stejnou zprávu více než jednou. Kromě toho, pokud úloha na pozadí selže po zpracování zprávy, ale před odstraněním z fronty, bude 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. Operace, jako je přidání hodnoty do existující uložené hodnoty, ale bez kontroly, že uložená hodnota je stále stejná, jako když byla zpráva původně odeslána, způsobí nekonzistence. Fronty služby Azure Service Bus mohou být nakonfigurovány tak, aby automaticky odstraňovaly duplicitní 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 odebrání z fronty, 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 jedových zpráv. Další informace naleznete v tématu Asynchronní zasílání zpráv Primer a Idempotentní vzory.

Záležitosti škálování a výkonu

Úlohy na pozadí musí nabízet dostatečný výkon, aby se zajistilo, že neblokují aplikaci nebo způsobují nekonzistence kvůli zpožděné operaci při zatížení systému. Výkon se obvykle vylepšuje škálováním výpočetních instancí, které hostují úlohy na pozadí. Při plánování a navrhování úloh na pozadí zvažte následující body ohledně škálovatelnosti a výkonu:

  • Azure podporuje automatické škálování (rozšíření horizontálně i zúžení horizontálně) na základě aktuální poptávky a zatížení nebo podle předdefinovaného plánu pro nasazení hostovaná ve službách Web Apps a Virtual Machines. Pomocí této funkce zajistíte, že aplikace jako celek má dostatečné možnosti výkonu a současně minimalizuje náklady na 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 provozní náklady.

  • 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í. Můžete také potřebovat škálovat fronty úložiště a další prostředky, aby se zabránilo kritickému bodu celého řetězu zpracování. Zvažte také další omezení, jako je maximální propustnost úložiště a dalších služeb, na které aplikace a úlohy na pozadí spoléhají.

  • Úlohy na pozadí musí být navržené pro škálování. Musí být například schopna dynamicky zjišťovat počet front úložiště, které se používají, aby mohly naslouchat nebo odesílat zprávy do příslušné fronty.

  • Ve výchozím nastavení se webové úlohy škálují s přidruženou instancí Azure Web Apps. Pokud ale chcete, aby webová úloha běžela pouze jako jedna instance, můžete vytvořit soubor Settings.job, který obsahuje data JSON { "is_singleton": true }. Azure tak vynutí spuštění pouze jedné instance WebJobu, a to i v případě, že existuje více instancí přidružené webové aplikace. To může být užitečná technika pro naplánované úlohy, které se musí spouštět pouze jako jedna instance.

Další kroky