Doporučení pro vývoj úloh na pozadí

  • Článek

Platí pro toto doporučení kontrolního seznamu spolehlivosti azure Well-Architected Framework:

RE:07 Posílení odolnosti a obnovitelnosti úloh implementací sebezáchovy a samoopravných opatření Zabudujte do řešení funkce pomocí vzorců spolehlivosti založených na infrastruktuře a softwarových vzorů návrhu pro zpracování selhání komponent a přechodných chyb. Zabudujte do systému funkce, které detekují selhání součástí řešení a automaticky zahájí nápravnou akci, zatímco úloha bude dál fungovat s plnou nebo omezenou funkčností.

Související příručky:Přechodné chybySebezáchovy |

Tato příručka popisuje doporučení pro vývoj úloh na pozadí. Úlohy na pozadí se spouští automaticky bez nutnosti interakce uživatele. Mnoho aplikací vyžaduje úlohy na pozadí, které běží nezávisle na uživatelském rozhraní.

Mezi příklady úloh na pozadí patří dávkové úlohy, úlohy náročného zpracování a dlouhotrvající procesy, jako jsou pracovní postupy. Aplikace spustí úlohu a zpracuje interaktivní požadavky od uživatelů. Pokud například aplikace potřebuje generovat miniatury obrázků, které uživatelé nahrají, je možné provést úlohu na pozadí, která vygeneruje miniaturu a uloží ji do úložiště. Uživatel nemusí čekat na dokončení procesu. Jako další příklad zákazník umístí objednávku, která zahájí pracovní postup na pozadí, který objednávku zpracuje. Zákazník pokračuje v procházení webové aplikace, zatímco běží úloha na pozadí. Po dokončení úlohy na pozadí aktualizuje uložená data objednávky a odešle zákazníkovi e-mail s potvrzením objednávky.

Úlohy na pozadí pomáhají minimalizovat zatížení uživatelského rozhraní aplikace, což zlepšuje dostupnost a zkracuje dobu interaktivní odezvy.

Klíčové strategie návrhu

Pokud chcete zvolit úlohu, kterou chcete označit jako úlohu na pozadí, zvažte, jestli se úloha spustí bez zásahu uživatele a jestli uživatelské rozhraní musí čekat na dokončení úkolu. Úlohy, které vyžadují, aby uživatel nebo uživatelské rozhraní čekal na spuštění, obvykle nejsou vhodné úlohy na pozadí.

Typy úloh na pozadí

Mezi příklady úloh na pozadí patří:

  • Ú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 vstupně-výstupní operace, jako je spouštění řady transakcí úložiště nebo indexování souborů.

  • Dávkové úlohy, jako jsou noční aktualizace dat nebo naplánovaná zpracování.

  • Dlouhotrvající pracovní postupy, jako jsou plnění objednávek nebo služby a systémy zřizování.

  • Zpracování citlivých dat, které přenáší úlohu do bezpečnějšího umístění pro zpracová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

Zahájení úloh na pozadí pomocí:

Triggery řízené událostmi

Akce aktivuje vyvolání řízené událostí, které spustí úlohu na pozadí. Mezi příklady triggerů řízených událostmi patří:

  • Uživatelské rozhraní nebo jiná úloha umístí zprávu do fronty, jak je popsáno ve stylu architektury Web-Queue-Worker. Zpráva obsahuje data o dříve provedené akci, například o zákazníkovi, který zadal objednávku. Úloha na pozadí tuto frontu monitoruje a zjišťuje příchod nové zprávy. Přečte zprávu a použije data zprávy jako vstup pro úlohu na pozadí. Tento model se nazývá asynchronní komunikace na základě zpráv.

  • Uživatelské rozhraní nebo jiná úloha uloží nebo aktualizuje hodnotu, která je v úložišti. Úloha na pozadí monitoruje úložiště a zjišťuje změny. Čte data a používá je jako vstup pro úlohu na pozadí.

  • Uživatelské rozhraní nebo jiná úloha vytvoří požadavek na koncový bod, například identifikátor URI HTTPS nebo rozhraní API, které je zveřejněné jako webová služba. Jako součást požadavku uživatelské rozhraní nebo úloha přenese data, která úloha na pozadí vyžaduje. Koncový bod nebo webová služba vyvolá úlohu na pozadí, která použije data jako vstup.

Mezi další 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.

Triggery řízené plánem

Časovač aktivuje naplánované vyvolání, které spustí úlohu na pozadí. Mezi příklady aktivačních událostí řízených plánem patří:

  • Časovač, který běží 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, například 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ý vyvolá úlohu na pozadí po časové prodlevě nebo v určitém čase.

Mezi další příklady úkolů, které jsou vhodné pro plánované vyvolání, patří rutiny dávkového zpracování (například aktualizace seznamů souvisejících produktů pro zákazníky na základě jejich nedávného chování), rutinní úlohy zpracování dat (například aktualizace indexů nebo generování kumulovaných výsledků), analýza dat pro denní sestavy, čištění uchovávání dat a kontroly konzistence dat.

Pokud používáte plánem řízenou úlohu, která se musí spustit jako jedna instance, projděte si následující aspekty:

  • Pokud je výpočetní instance, která spouští plánovač, například virtuální počítač, který používá naplánované úlohy Windows, škálovaná, pak spouštíte více instancí plánovače. Více instancí plánovače může spustit více instancí úlohy. Další informace najdete v tématu Co znamená idempotentní v softwarových systémech?

  • Pokud úkoly běží déle než období mezi událostmi plánovače, může plánovač spustit jinou instanci úlohy, zatímco předchozí úkol běží.

Vrácení výsledků

Úlohy na pozadí se spouští 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ě se úlohy na pozadí aktivují a zapomenou . Průběh jejich modulu runtime nemá vliv na uživatelské rozhraní nebo proces volání, což znamená, že volající proces nečeká na dokončení úkolů. Uživatelské rozhraní a proces volání nemůžou zjistit, kdy úloha skončí.

Pokud potřebujete úlohu na pozadí ke komunikaci s volající úlohou, která označuje průběh nebo dokončení, musíte implementovat mechanismus. Mezi příklady patří:

  • Zapište hodnotu ukazatele stavu do úložiště, která je přístupná pro uživatelské rozhraní nebo úlohu volajícího, která může tuto hodnotu monitorovat nebo zkontrolovat. Další data, která úloha na pozadí vrátí volajícímu, se dají umístit do stejného úložiště.

  • Vytvořte frontu odpovědí, kterou uživatelské rozhraní nebo volající monitoruje. Úloha na pozadí může odesílat zprávy do fronty, které označují stav. Data, která úloha na pozadí vrátí volajícímu, se dají umístit do zpráv. Pro Azure Service Bus použijte ReplyTo vlastnosti a CorrelationId k implementaci této funkce.

  • 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. Odpověď může obsahovat data, která úloha na pozadí vrátí volajícímu.

  • Nakonfigurujte úlohu na pozadí tak, aby prostřednictvím rozhraní API volala zpět do uživatelského rozhraní nebo volajícího a indikovala stav v předdefinovaných bodech nebo po dokončení. Můžete použít události vyvolané místně nebo mechanismus publikování a odběru. Požadavek nebo datová část události může obsahovat data, která úloha na pozadí vrátí volajícímu.

Úlohy dělení na pozadí

Pokud do existující výpočetní instance zahrnete úlohy na pozadí, zvažte, jak tyto změny ovlivní atributy kvality výpočetní instance a úlohy na pozadí. Zvažte tyto faktory a rozhodněte se, jestli se mají úlohy společně umístit se stávající výpočetní instancí nebo je rozdělit do jiné výpočetní instance:

  • Dostupnost: Úlohy na pozadí nemusí potřebovat stejnou úroveň dostupnosti jako jiné části aplikace, zejména uživatelské rozhraní a části, které přímo zahrnují interakci uživatele. Úlohy na pozadí můžou mít vyšší odolnost vůči latenci, opakovaným pokusům o selhání připojení a dalším faktorům, které mají vliv na dostupnost, protože operace je možné zařadit do fronty. Musí však existovat dostatečná kapacita, aby se zabránilo zálohovaným požadavkům, které můžou blokovat fronty a ovlivnit celou aplikaci.

  • Škálovatelnost: Úlohy na pozadí mají pravděpodobně jiné požadavky na škálovatelnost ve srovnání s uživatelským rozhraním a interaktivními částmi aplikace. Možná budete muset škálovat uživatelské rozhraní tak, aby splňovalo špičky v poptávce. Nezaplacené úlohy na pozadí se můžou spouštět v méně zaneprázdněných časech a s menším počtem výpočetních instancí.

  • Odolnost: Pokud výpočetní instance, která hostuje jenom úlohy na pozadí, selže, nemusí to mít fatální dopad na celou aplikaci. Požadavky na tyto úlohy lze zařadit do fronty nebo odložit, dokud nebude úkol k dispozici. Pokud se výpočetní instance nebo úlohy můžou restartovat v odpovídajícím intervalu, nemusí to mít vliv na uživatele aplikace.

  • Zabezpečení: Úlohy na pozadí můžou mít v porovnání s uživatelským rozhraním nebo jinými částmi aplikace jiné požadavky na zabezpečení nebo omezení. K určení jiného prostředí zabezpečení pro úlohy použijte samostatnou výpočetní instanci. Pokud chcete maximalizovat zabezpečení a oddělení, můžete také použít vzory, jako je Gatekeeper, a izolovat výpočetní instance na pozadí od uživatelského rozhraní.

  • Výkon: Zvolte typ výpočetní instance pro úlohy na pozadí, který konkrétně odpovídá požadavkům úlohy na výkon. Pokud úlohy nevyžadují stejné možnosti zpracování jako uživatelské rozhraní, můžete použít možnost levnějších výpočetních prostředků. Nebo můžete použít větší instanci, pokud úkoly vyžadují více kapacity a prostředků.

  • Spravovatelnost: Úlohy na pozadí můžou mít jiný rytmus vývoje a nasazení ve srovnání s hlavním kódem aplikace nebo uživatelským rozhraním. Pokud chcete zjednodušit aktualizace a správu verzí, nasaďte úlohy na pozadí do samostatné výpočetní instance.

  • Náklady: Pokud přidáte výpočetní instance pro spouštění úloh na pozadí, zvýší se náklady na hostování. Pečlivě zvažte kompromis mezi větší kapacitou a dodatečnými náklady.

Další informace najdete v tématech Model volby lídra a Model konkurenčních spotřebitelů.

Konflikty

Pokud máte více instancí úlohy na pozadí, můžou soutěž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 způsobit kolize prostředků, což může způsobit konflikty dostupnosti služeb a poškodit integritu dat v úložišti. Při řešení kolizí prostředků použijte pesimistické zamykání. Tento přístup zabraňuje konkurenčním instancím úlohy v souběžných přístupech ke službě nebo poškození dat.

Dalším přístupem k řešení konfliktů je definovat úlohy na pozadí jako jednu instanci, aby běžela jenom jedna instance. Tento přístup však eliminuje výhody spolehlivosti a výkonu, které poskytuje konfigurace s více instancemi. Tato nevýhoda platí zejména v případě, že uživatelské rozhraní poskytuje dostatek práce, aby bylo zaneprázdněno více než jeden úkol na pozadí.

Ujistěte se, že se úloha na pozadí může automaticky restartovat a že má dostatečnou kapacitu pro zvládnutí špiček v poptávce. Přidělte výpočetní instanci s dostatkem prostředků, implementujte mechanismus řazení do fronty, který ukládá požadavky ke spuštění při poklesu poptávky, nebo použijte kombinaci těchto technik.

Koordinace

Úlohy na pozadí můžou být složité a ke spuštění vyžadují více úloh. V těchto scénářích je běžné rozdělit úlohu do menších samostatných kroků nebo dílčích úkolů, které může spustit více příjemců. Vícekrokové úlohy jsou efektivnější a flexibilnější, protože jednotlivé kroky jsou často opakovaně použitelné ve více úlohách. Můžete také snadno přidat, odebrat nebo změnit pořadí kroků.

Koordinovat více úkolů a kroků může být náročné, ale existují tři běžné vzory, které vaše řešení povedou:

  • Rozložte úkol do několika opakovaně použitelných kroků. Aplikace může být vyžadována k provádění různých úloh různé složitosti s informacemi, které zpracovává. Jednoduchým, ale nepružným přístupem k implementaci takové aplikace je provést toto 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 aplikace vyžaduje části stejného zpracování jinde. Další informace najdete v tématu Vzor kanálů a filtrů.

  • Umožňuje spravovat orchestraci kroků pro úlohu. Aplikace může provádět úlohy, které tvoří mnoho kroků, z nichž některé můžou vyvolat vzdálené služby nebo přistupovat ke vzdáleným prostředkům. Někdy jsou jednotlivé kroky na sobě nezávislé, ale orchestruje je logika aplikace, která úlohu implementuje. Další informace najdete v tématu Vzor správce agenta plánovače.

  • Spravujte obnovení pro kroky úlohy, které selžou. Pokud jeden nebo více kroků selže, aplikace může potřebovat vrátit zpět práci, kterou provádí řada kroků, což společně definuje nakonec konzistentní operaci. Další informace najdete v tématu Model kompenzační transakce.

Důležité informace o odolnosti

Vytvořte odolné úlohy na pozadí, které poskytují spolehlivé služby pro aplikaci. Při plánování a návrhu úloh na pozadí vezměte v úvahu následující body:

  • Úlohy na pozadí musí řádně zpracovávat 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ů. Pomocí kontrolních bodů můžete uložit stav úloh v trvalém úložišti nebo jako zprávy ve frontě. Můžete například uložit informace o stavu ve zprávě, která je ve frontě, a postupně aktualizovat tyto informace o stavu s průběhem úkolu. Úkol je možné zpracovat z posledního známého kontrolního bodu místo restartování od začátku.

    Pro fronty služby Service Bus k tomuto účelu použijte relace zpráv. Pomocí relací zpráv uložte a načtěte 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 tématu Model správce agenta plánovače.

  • 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. Úlohy můžou uživatelské rozhraní dohánět v obdobích s menším vytížením a restartování uživatelské rozhraní neblokuje. Další informace najdete v tématu Model vyrovnávání zatížení na základě fronty. Pokud jsou některé úkoly důležitější než jiné, zvažte implementaci modelu Prioritní fronta , abyste zajistili, že se tyto úlohy spustí jako první.

Zprávy

Nakonfigurujte úlohy na pozadí, které jsou inicializovány zprávami nebo zpracovávají zprávy pro zpracování nekonzistence, jako jsou zprávy, které přicházejí mimo pořadí, zprávy, které opakovaně způsobují chybu (otravné zprávy) a zprávy, které se doručují více než jednou. Zvažte následující doporučení:

  • Někdy potřebujete zpracovávat zprávy 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 k existující hodnotě. Zprávy nepřicházejí vždy v pořadí, v jakém byly odeslány. Různé instance úlohy na pozadí také můžou zpracovávat zprávy v jiném pořadí kvůli různým zatížením jednotlivých instancí.

    U zpráv, které musí být zpracovány v určitém pořadí, zahrňte pořadové číslo, klíč nebo jiný indikátor, který můžou úlohy na pozadí používat ke zpracování zpráv ve správném pořadí. V případě služby Service Bus použijte relace zpráv k zajištění správného pořadí doručení. Efektivnější je navrhnout proces tak, aby pořadí zpráv nebylo důležité. Další informace najdete v tématu sekvencování zpráv a časová razítka.

  • Úloha na pozadí obvykle nahlédne do zpráv ve frontě, což je dočasně skryje před ostatními příjemci zpráv. Jakmile úkol zprávu úspěšně zpracuje, zprávu odstraní. Pokud úloha na pozadí selže při zpracování zprávy, po vypršení časového limitu náhledu se tato zpráva znovu zobrazí ve frontě. Zprávu zpracuje jiná instance úlohy nebo další cyklus zpracování původní instance zpracuje zprávu.

    Pokud zpráva konzistentně způsobuje chybu v příjemci, zablokuje úlohu, frontu a nakonec samotnou aplikaci, když se fronta zaplní. Je důležité detekovat a odstranit zprávy o jedu z fronty. Pokud používáte službu Service Bus, automaticky nebo ručně přesunete zprávy o jedu do přidružené fronty nedoručených zpráv.

  • Fronty jsou alespoň jednou mechanismy doručení, ale můžou doručovat stejnou zprávu více než jednou. Pokud úloha na pozadí selže poté, co zpracuje zprávu, ale ještě před jejím odstraněním z fronty, bude zpráva znovu k dispozici ke zpracování.

    Úlohy na pozadí by měly být idempotentní, což znamená, že když úkol zpracuje stejnou zprávu více než jednou, nezpůsobí chybu nebo nekonzistence v datech aplikace. Některé operace jsou přirozeně idempotentní, například pokud je uložená hodnota nastavená na konkrétní novou hodnotu. Některé operace však způsobují nekonzistence, například pokud je hodnota přidána k existující uložené hodnotě bez ověření, že uložená hodnota je stále stejná, jako když byla zpráva původně odeslána. Nakonfigurujte fronty služby Service Bus tak, aby automaticky odebíraly duplicitní zprávy. Další informace najdete v tématu Zpracování idempotentní zprávy.

  • Některé systémy zasílání zpráv, jako jsou fronty služby Azure Storage a fronty služby Service Bus, podporují vlastnost počet vyřazení z fronty, která udává, kolikrát je zpráva z fronty přečtená. Tato data jsou užitečná pro zpracování opakovaných zpráv a zpráv o jedu. Další informace najdete v tématech Úvod do asynchronního zasílání zpráv a Vzory 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 neblokují aplikaci nebo nezpozdí operaci, když je systém zatížený. Výkon se obvykle zvyšuje, když škálujete výpočetní instance, které hostují úlohy na pozadí. Při plánování a návrhu úloh na pozadí vezměte v úvahu následující body související se škálovatelností a výkonem:

  • Azure Virtual Machines a Web Apps funkce Azure App Service může hostovat nasazení. Podporují automatické škálování, a to jak horizontálním navýšením kapacity, tak horizontálním navýšením kapacity. Automatické škálování je určeno poptávkou a zatížením nebo předdefinovaným plánem. Pomocí automatického škálování můžete zajistit, aby aplikace byla dostatečně výkonná a zároveň minimalizovala náklady za běhu.

  • Některé úlohy na pozadí mají v porovnání s jinými částmi aplikace jiné funkce výkonu, například uživatelské rozhraní nebo komponenty, jako je vrstva přístupu k datům. V tomto scénáři hostujte úlohy na pozadí společně v samostatné výpočetní službě, aby se uživatelské rozhraní a úlohy na pozadí mohly nezávisle škálovat a spravovat zatížení. Pokud má více úloh na pozadí výrazně odlišné možnosti výkonu, rozdělte je a škálujte každý typ nezávisle. Tato technika může zvýšit náklady za běhu.

  • Pokud chcete zabránit ztrátě výkonu při zatížení, možná budete muset škálovat také fronty úložiště a další prostředky, aby jediný bod řetězce zpracování nezpůsobil kritický bod. Zvažte další omezení, například maximální propustnost úložiště a dalších služeb, na které aplikace a úlohy na pozadí spoléhají.

  • Návrh úloh na pozadí pro škálování Úlohy na pozadí například musí dynamicky zjišťovat počet využitých front úložiště k monitorování zpráv nebo odesílání zpráv do příslušné fronty.

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

  • Úlohy na pozadí můžou vytvářet výzvy pro synchronizaci dat a koordinaci procesů, zejména pokud úkoly na pozadí závisejí na sobě navzájem nebo na jiných zdrojích dat. Úlohy na pozadí můžou například zpracovávat problémy s konzistencí dat, podmínkami časování, vzájemnými zablokováními nebo vypršením časových limitů.

  • Úlohy na pozadí můžou mít vliv na uživatelské prostředí, pokud se uživateli zobrazí výsledky úloh na pozadí. Úlohy na pozadí můžou například vyžadovat, aby uživatel čekal na oznámení, aktualizoval stránku nebo ručně zkontroloval stav úlohy. Toto chování může zvýšit složitost interakce uživatele a negativně ovlivnit činnost uživatele.

Kompromis: Úlohy na pozadí přinášejí do systému více komponent a závislostí, což může zvýšit složitost a náklady na údržbu řešení. Úlohy na pozadí můžou například vyžadovat samostatnou frontovou službu, službu pracovního procesu, monitorovací službu a mechanismus opakování.

Usnadnění Azure

Následující části popisují služby Azure, které můžete použít k hostování, spouštění, konfiguraci a správě úloh na pozadí.

Hostitelská prostředí

Existuje několik služeb platformy Azure, které můžou hostovat úlohy na pozadí:

  • Web Apps a webové úlohy: Pomocí funkce WebJobs App Service můžete spouštět vlastní úlohy založené na různých skriptech nebo programech, které můžete spouštět ve webové aplikaci.

  • Azure Functions: Aplikace funkcí používejte pro úlohy na pozadí, které dlouho neběží. Aplikace funkcí můžete použít také v případě, že úlohu hostujete v nedostatečně využité App Service plánu.

  • Virtual Machines: Pokud máte službu windows nebo chcete používat Plánovač úloh Windows, hostujte úlohy na pozadí ve vyhrazeném virtuálním počítači.

  • Azure Batch: Batch je služba platformy, kterou můžete použít k naplánování práce náročné na výpočetní výkon na spravované kolekci virtuálních počítačů. Může automaticky škálovat výpočetní prostředky.

  • Azure Kubernetes Service (AKS): AKS poskytuje spravované hostitelské prostředí pro Kubernetes v Azure.

  • Azure Container Apps: Pomocí aplikací kontejneru můžete vytvářet bezserverové mikroslužby založené na kontejnerech.

Následující části obsahují důležité informace o každé z těchto možností, které vám pomůžou vybrat nejvhodnější možnost.

Web Apps a WebJobs

Pomocí funkce WebJobs můžete ve webové aplikaci spouštět vlastní úlohy jako úlohy na pozadí. Webová úloha běží v kontextu webové aplikace jako nepřetržitý proces. Webová úloha se může spustit také v reakci na aktivační událost z Logic Apps nebo externích faktorů, jako jsou změny objektů blob úložiště nebo front zpráv. WebJobs je možné spustit a zastavit na vyžádání a řádně se vypnout. Pokud nepřetržitě spuštěná webová úloha selže, automaticky se restartuje. Můžete nakonfigurovat akce opakování a chybových akcí.

Během konfigurace webové úlohy:

  • Pokud chcete, aby úloha reagovala na trigger řízený událostmi, nakonfigurujte ji tak, aby běžela nepřetržitě. Skript nebo program jsou uložené ve složce s názvem site/wwwroot/app_data/jobs/continuous.

  • Pokud chcete, aby úloha reagovala na aktivační událost řízenou plánem, nakonfigurujte ji na Spustit 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 Spustit na vyžádání , spustí se při spuštění úlohy stejný kód jako možnost Spustit podle plánu .

Webová úloha běží v sandboxu webové aplikace. Má přístup k proměnným prostředí a může s webovou aplikací sdílet informace, jako jsou připojovací řetězce. Webová úloha má přístup k jedinečnému identifikátoru počítače, který spouští webovou úlohu. Pojmenovaná AzureWebJobsStorage připojovací řetězec poskytuje přístup k frontám, objektům blob a tabulkám služby Storage pro data aplikací. Poskytuje také přístup ke službě Service Bus pro zasílání zpráv a komunikaci. Název připojovací řetězec AzureWebJobsDashboard poskytuje přístup k souborům protokolu akcí webové úlohy.

Webové úlohy mají následující charakteristiky:

  • Zabezpečení: Přihlašovací údaje pro nasazení webové aplikace poskytují ochranu webových úloh.

  • Podporované typy souborů: Definujte webové úlohy pomocí skriptů příkazů (.cmd), dávkových souborů (.bat), skriptů PowerShellu (.ps1), skriptů prostředí Bash (.sh), skriptů PHP (.php), skriptů Pythonu (.py), kódu JavaScriptu (.js) a spustitelných programů (.exe a .jar).

  • Nasazení: Skripty a spustitelné soubory můžete nasadit pomocí Azure Portal, sady Visual Studio nebo sady WebJobs SDK nebo je můžete zkopírovat přímo do následujících umístění:

    • Pro aktivované nasazení: site/wwwroot/app_data/jobs/triggered/<název úlohy>

    • Pro průběžné nasazování: site/wwwroot/app_data/jobs/continuous/<název úlohy>

  • Soubory protokolu: Console.Out se považuje nebo označí jako INFO. Console.Error se považuje za ERROR. Pomocí portálu můžete získat přístup k informacím o monitorování a diagnostice. Stáhněte si soubory protokolu přímo z webu. Soubory protokolu se ukládají do následujících umístění:

    • Pro aktivované nasazení: Vfs/data/jobs/triggered/<název úlohy>

    • Pro průběžné nasazování: Vfs/data/jobs/continuous/<název úlohy>

  • Konfigurace: Nakonfigurujte webové úlohy pomocí portálu, rozhraní REST API a PowerShellu. K zadání informací o konfiguraci webové úlohy použijte konfigurační soubor s názvem settings.job, který je ve stejném kořenovém adresáři jako skript webové úlohy. Příklad:

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

důležité informace o Web Apps a webových úlohách

  • Ve výchozím nastavení se WebJobs škálují s webovou aplikací. Pokud chcete nakonfigurovat, aby se webové úlohy spouštěly v jedné instanci, nastavte is_singleton vlastnost configuration na true. Webová úloha s jednou instancí je užitečná pro úlohy, které nechcete škálovat nebo spouštět jako souběžné instance, jako je například přeindexování nebo analýza dat.

  • Pokud chcete minimalizovat vliv webových úloh na výkon webové aplikace, vytvořte prázdnou instanci webové aplikace v novém App Service plánu pro hostování dlouhotrvajících nebo na prostředky náročných webových úloh.

Azure Functions

Azure Functions se podobá webjobs. Azure Functions je bezserverová a je nejvhodnější pro triggery řízené událostmi, které běží po krátkou dobu. Můžete také použít Azure Functions ke spouštění naplánovaných úloh prostřednictvím aktivačních událostí časovače, pokud nakonfigurujete funkci tak, aby se spouštěla v určených časech.

Azure Functions se nedoporučuje u rozsáhlých a dlouhotrvajících úloh, protože funkce může způsobit neočekávané vypršení časových limitů. V závislosti na plánu hostování ale zvažte použití funkcí pro aktivační události řízené plánem.

důležité informace o Azure Functions

Pokud očekáváte, že úloha na pozadí poběží na krátkou dobu v reakci na událost, zvažte spuštění úlohy v plánu Consumption. Modul runtime můžete nakonfigurovat na maximální dobu. Funkce, která běží déle, stojí víc. Úlohy náročné na procesor, které spotřebovávají více paměti, můžou být dražší. Pokud pro služby v rámci úlohy použijete další triggery, budou se fakturovat samostatně.

Plán Premium je vhodný, pokud máte několik úkolů, které jsou krátké, ale běží 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 další funkce, jako je integrace virtuální sítě.

Vyhrazený plán je vhodný pro úlohy na pozadí, pokud vaše úloha už běží na vyhrazeném plánu. Pokud máte nevyužité virtuální počítače, můžete vyhrazený plán 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ématu:

Virtual Machines

Úlohy na pozadí můžete implementovat tak, aby se nenasadily do Web Apps. Úlohy můžete například implementovat pomocí služeb systému Windows, nástrojů třetích stran nebo spustitelných programů. Můžete také použít programy, které jsou napsané pro běhové prostředí, které se liší od prostředí, které je hostitelem aplikace. Můžete například použít unixový nebo linuxový program, který chcete spustit z aplikace pro Windows nebo .NET. Vyberte si z několika operačních systémů pro virtuální počítač Azure a spusťte na daném virtuálním počítači svoji službu nebo spustitelný soubor.

Další informace naleznete v tématu:

Pokud chcete spustit úlohu na pozadí v samostatném virtuálním počítači, můžete:

  • Odešlete do koncového bodu požadavek, který úloha zpřístupní ke spuštění úlohy na vyžádání přímo z vaší aplikace. Požadavek přenese data, která úkol vyžaduje. Koncový bod vyvolá úlohu.

  • Pomocí plánovače nebo časovače ze zvoleného operačního systému nakonfigurujte úlohu tak, aby běžela podle plánu. Ve Windows můžete například pomocí Plánovače úloh systému Windows spouštět skripty a úlohy. Pokud máte na virtuálním počítači nainstalované SQL Server, použijte ke spouštění skriptů a úloh agenta SQL Server.

  • Pomocí Logic Apps spusťte úlohu přidáním zprávy do fronty, kterou úloha monitoruje, nebo odesláním požadavku do rozhraní API, které úloha zveřejňuje.

Další informace o tom, jak spustit úlohy na pozadí, najdete v předchozí části Aktivační události .

důležité informace o Virtual Machines

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

  • Hostujte úlohy na pozadí na samostatném virtuálním počítači Azure, abyste zajistili flexibilitu a přesnou kontrolu nad zahájením, nasazením, plánováním a přidělením prostředků. Pokud ale virtuální počítač nasadíte výhradně pro úlohy na pozadí, náklady na běh se zvýší.

  • Na portálu není k dispozici žádné zařízení pro monitorování úloh a možnost automatického restartování neúspěšných úloh. Pomocí rutin Azure Resource Manager ale můžete monitorovat stav virtuálního počítače a spravovat ho. Ve výpočetních uzlech nejsou k dispozici žádná zařízení pro řízení procesů a vláken. Pokud používáte virtuální počítač, obvykle musíte implementovat mechanismus, který shromažďuje data z instrumentace v úloze a také z operačního systému ve virtuálním počítači. K tomuto účelu můžete použít sadu System Center Management Pack pro Azure .

  • Zvažte vytvoření monitorovacích sond, které se zveřejňují prostřednictvím koncových bodů HTTP. Pro tyto sondy můžete nakonfigurovat kód pro provádění kontrol stavu a shromažďování provozních informací a statistik. Pomocí sond můžete také sloučit informace o chybě a vrátit je do aplikace pro správu.

Další informace naleznete v tématu:

Batch

Službu Batch zvažte, pokud potřebujete spouštět velké paralelní úlohy vysokovýkonného výpočetního prostředí (HPC) na desítkách, stovkách nebo tisících virtuálních počítačů.

Pomocí služby Batch můžete připravit virtuální počítače, přiřadit jim úkoly, spouštět úlohy, monitorovat průběh a automaticky škálovat virtuální počítače v reakci na úlohu. Batch také poskytuje plánování úloh a podporuje virtuální počítače s Linuxem a Windows.

Důležité informace o službě Batch

Služba Batch je vhodná pro vnitřně paralelní úlohy. Pomocí služby Batch můžete provádět paralelní výpočty s krokem redukce na konci nebo spouštět aplikace rozhraní MPI (Message Passing Interface) pro paralelní úlohy, které vyžadují předávání zpráv mezi uzly.

Úloha Služby Batch běží na fondu uzlů nebo virtuálních počítačích. Fond můžete přidělit jenom v případě potřeby a po dokončení úlohy ho odstranit. Tento přístup maximalizuje využití, protože uzly nejsou nečinné, ale úloha musí počkat, až uzly přidělíte. Případně můžete vytvořit fond předem. Tento přístup minimalizuje dobu potřebnou ke spuštění úlohy, ale může mít za následek nečinné uzly.

Další informace naleznete v tématu:

Azure Kubernetes Service

Pomocí AKS můžete spravovat hostované prostředí Kubernetes, abyste mohli snadno nasazovat a spravovat kontejnerizované aplikace.

Kontejnery jsou 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ů.

  • Pomocí orchestrátoru kontejneru můžete provádět interní vyrovnávání zatížení, konfigurovat interní síť a provádět další úlohy konfigurace.

  • Kontejnery můžete podle potřeby spouštět a zastavovat.

  • S Azure Container Registry můžete registrovat kontejnery uvnitř hranic Azure a poskytovat tak výhody zabezpečení, ochrany osobních údajů a bezkontaktní komunikace.

Důležité informace o AKS

AKS vyžaduje znalost použití orchestrátoru kontejnerů.

Další informace naleznete v tématu:

Aplikace kontejneru

Pomocí Container Apps můžete vytvářet bezserverové mikroslužby založené na kontejnerech. Aplikace kontejneru:

  • Je optimalizovaný pro spouštění kontejnerů pro obecné účely, zejména pro aplikace, které pokrývají mnoho mikroslužeb nasazených v kontejnerech.

  • Využívá Kubernetes a opensourcové technologie, jako jsou Dapr, Automatické škálování řízené událostmi Kubernetes (KEDA) a Envoy.

  • Podporuje aplikace a mikroslužby ve stylu Kubernetes s funkcemi, jako je zjišťování služeb a rozdělení provozu.

  • Umožňuje aplikační architektury řízené událostmi tím, že podporuje škálování založené na provozu a načítání ze zdrojů událostí, jako jsou fronty, včetně škálování na nulu.

  • Podporuje dlouhotrvající procesy a může spouštět úlohy na pozadí.

Důležité informace o aplikacích kontejneru

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ě, použijte AKS. Pokud chcete vytvářet aplikace ve stylu Kubernetes a nevyžadujete přímý přístup k nativním rozhraním API Kubernetes a správě clusterů, použijte k plně spravovanému prostředí Container Apps. Container Apps je nejvhodnější pro vytváření kontejnerových mikroslužeb.

Další informace naleznete v tématu:

Kontrolní seznam spolehlivosti

Projděte si kompletní sadu doporučení.

Kontrolní seznam spolehlivosti