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

  • Článek

Platí pro toto doporučení kontrolního seznamu pro spolehlivost architektury Azure Well-Architected Framework:

RE:07 Posílení odolnosti a obnovitelnosti úloh implementací samozáchů a samoopravených opatření. S využitím vzorů spolehlivosti založených na infrastruktuře a vzorů návrhu na základě softwaru můžete do řešení problémů se selháními komponent a přechodnými chybami začlenit možnosti. Zabudujte do systému funkce pro detekci selhání komponent řešení a automaticky iniciujte nápravnou akci, zatímco úloha bude fungovat v plné nebo omezené funkčnosti.

Související příručky | : Přechodné chyby– samozáchozí

Tato příručka popisuje doporučení pro vývoj úloh na pozadí. Úlohy na pozadí se spouštějí 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é na 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 vygenerovat 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. Zákazník jako další příklad umístí objednávku, která zahájí pracovní postup na pozadí, který objednávku zpracuje. Zákazník bude dál procházet webovou aplikaci během spuštění úlohy 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, který úkol má být určen jako úloha na pozadí, zvažte, jestli se úloha spustí bez zásahu uživatele a jestli má uživatelské rozhraní čekat na dokončení úkolu. Úlohy, které vyžadují, aby uživatel nebo uživatelské rozhraní čekali na jejich spuštění, obvykle nejsou vhodné úlohy na pozadí.

Vyhodnocení potřeby ú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 spuš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 je plnění objednávek nebo zřizování služeb a systémů.

  • 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.

Výběr správných aktivačních událostí

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

Triggery řízené událostmi

Akce aktivuje vyvolání řízené událostmi, 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ý objednávku zadal. Úloha na pozadí monitoruje tuto frontu a detekuje 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 založená na zprávách.

  • Uživatelské rozhraní nebo jiná úloha uloží nebo aktualizuje hodnotu, která je v úložišti. Úloha na pozadí monitoruje úložiště a detekuje 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. V rámci 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 volání řízené plánem, které spustí úlohu na pozadí. Mezi příklady triggerů ří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, 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ý vyvolá úlohu na pozadí po časovém zpoždění nebo v určitém čase.

Mezi další příklady úloh, které jsou vhodné pro volání řízené podle plánu, patří rutiny dávkového zpracování (například aktualizace souvisejících seznamů 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í dat a kontroly konzistence dat.

Pokud používáte úlohu řízenou podle plánu, která se musí spouštět 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 několik instancí plánovače. Více instancí plánovače může spustit více instancí úlohy. Další informace naleznete v tématu Co znamená idempotentní v softwarových systémech?

  • Pokud úkoly běží déle, než je doba mezi událostmi plánovače, může plánovač spustit jinou instanci úlohy při spuštění předchozí úlohy.

Vrácení dat do úlohy

Úlohy na pozadí běží 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 běhu nemá vliv na uživatelské rozhraní ani na volající proces, což znamená, že volající proces nečeká na dokončení úloh. Uživatelské rozhraní a volající proces nemůžou zjistit, kdy úloha skončí.

Pokud ke komunikaci s volajícím úkolem potřebujete úkol na pozadí, abyste označili průběh nebo dokončení, musíte implementovat mechanismus. Mezi příklady patří:

  • Napiš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 kontrolovat. Další data, která úloha na pozadí vrátí volajícímu, mohou být umístěna ve stejném úložišti.

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

  • 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 zahrnovat data, která úloha na pozadí vrátí volajícímu.

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

Úlohy na pozadí oddílů

Pokud do existující výpočetní instance zahrnete úlohy na pozadí, zvažte, jak tyto změny ovlivňují atributy kvality výpočetní instance a úlohy na pozadí. Zvažte tyto faktory, abyste se rozhodli, jestli chcete úkoly umístit s existující výpočetní instancí, nebo je oddě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 proti 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 zálohovaným požadavkům, které můžou blokovat fronty a ovlivnit celou aplikaci.

  • Škálovatelnost: Úlohy na pozadí mají pravděpodobně různé požadavky na škálovatelnost v porovná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. Vynikající úlohy na pozadí se můžou spouštět během méně zaneprázdněných časů a s menším počtem výpočetních instancí.

  • Odolnost: Pokud výpočetní instance, která hostuje pouze úlohy na pozadí, selže, nemusí mít závažnou vliv na celou aplikaci. Žádosti o tyto úlohy je možné zařadit do fronty nebo odložit, dokud nebude úkol k dispozici. Pokud se výpočetní instance nebo úlohy můžou 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 různé požadavky na zabezpečení nebo omezení v porovnání s uživatelským rozhraním nebo jinými částmi aplikace. K určení jiného prostředí zabezpečení pro úlohy použijte samostatnou výpočetní instanci. K maximalizaci zabezpečení a oddělení můžete také použít vzory, jako je Gatekeeper, k izolaci výpočetních instancí na pozadí z uživatelského rozhraní.

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

  • Možnosti správy: Úlohy na pozadí můžou mít jiný rytmus vývoje a nasazení v porovná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 dalšími náklady.

Další informace naleznete v tématu Model volby vedoucího procesu a model Konkurující spotřebitelé.

Zabránění konfliktu prostředků

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. Vyřešte kolize prostředků pomocí pesimistického uzamčení. Tento přístup brání souběžnému přístupu ke službě nebo poškození dat konkurenčním instancím úlohy.

Dalším přístupem k řešení konfliktů je definování úloh na pozadí jako jediného typu, aby se spustila pouze jedna instance. Tento přístup ale eliminuje výhody spolehlivosti a výkonu, které poskytuje konfigurace s více instancemi. Tato nevýhoda je obzvláště pravdivá, pokud uživatelské rozhraní poskytuje dostatek práce, aby bylo více než jedna úloha na pozadí zaneprázdněna.

Ujistěte se, že úloha na pozadí se 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 dostatečnými prostředky, implementujte mechanismus zařaďte do fronty, který ukládá požadavky, které se mají spustit při poklesu poptávky, nebo použijte kombinaci těchto technik.

Orchestrace více úloh

Úlohy na pozadí můžou být složité a ke spuštění můžou vyžadovat více úloh. V těchto scénářích je běžné rozdělit úlohu na menší diskrétní kroky nebo dílčí úkoly, které může spustit více příjemců. Úlohy s více kroky jsou efektivnější a flexibilnější, protože jednotlivé kroky jsou často opakovaně použitelné ve více úlohách. Je také snadné přidat, odebrat nebo upravit pořadí kroků.

Může to být výzva ke koordinaci více úkolů a kroků, ale existují tři běžné vzory, které vaše řešení provedou:

  • Rozdělte úkol 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ý, ale nepružný přístup k implementaci takové aplikace spočívá v provedení tohoto zpracování jako monolitického modulu. 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 modelu Kanály a filtry.

  • Spravujte 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 nezávislé na sobě, ale orchestrují se logikou aplikace, která implementuje úlohu. Další informace najdete v tématu Model plánovače agenta supervisor.

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

Zajištění odolnosti úloh

Vytvořte odolné úlohy na pozadí pro poskytování spolehlivých služeb pro aplikaci. Při plánování a návrhu úloh na pozadí zvažte 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 ukládat informace o stavu ve zprávě, která je ve frontě, a přírůstkově aktualizovat tyto informace o stavu průběhem úkolu. Úkol lze zpracovat z posledního známého kontrolního bodu místo restartování od začátku.

    Pro fronty služby Service Bus použijte relace zpráv pro tento účel. Při relacích 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ů naleznete v tématu Model Scheduler Agent 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. Úlohy můžou dohnat uživatelské rozhraní během méně zaneprázdněných období a restartování neblokují uživatelské rozhraní. Další informace naleznete v tématu Model 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 se tyto úlohy spustí jako první.

Zprávy

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

  • Někdy potřebujete zprávy zpracovávat 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. Zprávy nedorazí 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í, a to 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í, uveďte pořadové číslo, klíč nebo jiný indikátor, který můžou úlohy na pozadí použít ke zpracování zpráv ve správném pořadí. Pro Service Bus použijte relace zpráv k zajištění správného pořadí doručení. Návrh procesu je efektivnější, aby pořadí zpráv nebylo důležité. Další informace najdete v tématu sekvencování zpráv a časové razítko.

  • Úloha na pozadí obvykle zobrazí náhled zpráv ve frontě, která je dočasně skryje před ostatními příjemci zpráv. Po úspěšném zpracování úlohy zprávu odstraní. Pokud úloha na pozadí selže, když zpracuje zprávu, tato zpráva se znovu zobrazí ve frontě po vypršení časového limitu náhledu. Jiná instance úlohy zpracuje zprávu nebo další cyklus zpracování původní instance zpracuje zprávu.

    Pokud zpráva konzistentně způsobí chybu příjemce, zablokuje úlohu, frontu a nakonec samotnou aplikaci, když se fronta zaplní. Je důležité detekovat a odebírat z fronty otrávené zprávy. Pokud používáte Service Bus, automaticky nebo ručně přesuňte otrávené zprávy do přidružené fronty mrtvý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, jakmile zpracuje zprávu, ale před odstraněním z fronty ji znovu zpracuje, bude zpráva 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 dat 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 při původním odeslání zprávy. Nakonfigurujte fronty služby Service Bus tak, aby automaticky odebraly duplicitní zprávy. Další informace naleznete v tématu Idempotentní zpracování zpráv.

  • Některé systémy zasílání zpráv, jako jsou fronty Azure Storage a fronty Service Bus, podporují vlastnost počtu vyřazení z fronty, která označuje, kolikrát se zpráva z fronty přečte. Tato data jsou užitečná pro zpracování opakovaných zpráv a jedových zpráv. Další informace najdete v tématu Vzory asynchronního zasílání zpráv a idempotence.

Zajištění škálovatelnosti úloh

Úlohy na pozadí musí nabízet dostatečný výkon, aby se zajistilo, že při zatížení systému nezablokují operaci aplikace nebo zpoždění. Výkon se obvykle zvyšuje při škálování výpočetních instancí, které hostují úlohy 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:

  • Služba Azure Virtual Machines a funkce Web Apps služby Aplikace Azure může hostovat nasazení. Podporují automatické škálování, horizontální navýšení kapacity i horizontální navýšení kapacity. Automatické škálování je určeno poptávkou a zatížením nebo předdefinovaným plánem. Automatické škálování vám pomůže zajistit, aby aplikace byla dostatečně výkonná a minimalizovala náklady za běhu.

  • Některé úlohy na pozadí mají v porovnání s jinými částmi aplikace jinou funkci výkonu, například uživatelské rozhraní nebo komponenty, například vrstvu přístupu k datům. V tomto scénáři hostujte úlohy na pozadí v samostatné výpočetní službě, aby se uživatelské rozhraní a úlohy na pozadí mohly škálovat nezávisle na správě zatížení. Pokud má více úloh na pozadí výrazně jiné 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.

  • Abyste zabránili ztrátě výkonu při zatížení, možná budete muset škálovat fronty úložiště a další prostředky, aby kritický bod řetězu zpracování nezpůsobil kritický bod. Vezměte v úvahu další omezení, jako je 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žívaných front úložiště pro 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 instancí Web Apps. Pokud však chcete, aby webová úloha běžela pouze jako jedna instance, můžete vytvořit soubor Settings.job, který obsahuje data { "is_singleton": true }JSON . Tato metoda vynutí, aby Azure spustila pouze jednu instanci webové úlohy, i když existuje více instancí přidružené webové aplikace. Tato technika je užitečná pro naplánované úlohy, které se musí spouštět pouze jako jedna instance.

  • Úlohy na pozadí můžou způsobit problémy při synchronizaci dat a koordinaci procesů, zejména pokud úlohy na pozadí závisejí na sobě nebo na jiných zdrojích dat. Úlohy na pozadí můžou například zpracovávat problémy s konzistencí dat, podmínky časování, zablokování nebo vypršení časových limitů.

  • Úlohy na pozadí můžou ovlivnit 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 uživatelské prostředí.

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 službu fronty, 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 WebJobs: Pomocí funkce WebJobs služby App Service můžete spouštět vlastní úlohy založené na různých skriptech nebo programech, které můžete spustit ve webové aplikaci.

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

  • Virtuální počítače: Pokud máte službu Windows nebo chcete použít Plánovač úloh systému Windows, hostujte úlohy na pozadí na 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: S kontejnerovými aplikacemi 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 zvolit tu nejlepší 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ěží jako průběžný proces v kontextu vaší webové aplikace. Webová úloha se může spustit také v reakci na událost triggeru 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ě vypnout. Pokud se nepřetržitě spuštěná webová úloha nezdaří, automaticky se restartuje. Můžete nakonfigurovat akce opakování a chyb.

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 se uloží do složky s názvem site/wwwroot/app_data/jobs/continuous.

  • Pokud chcete, aby úloha reagovala na trigger řízený plánem, nakonfigurujte ji tak, aby běžela 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 Spustit podle plánu .

Webová úloha se spouští v sandboxu webové aplikace. Má přístup k proměnným prostředí a může sdílet informace, jako jsou připojovací řetězec, s webovou aplikací. Webová úloha má přístup k jedinečnému identifikátoru počítače, na kterém běží webová úloha. Pojmenovaná AzureWebJobsStorage připojovací řetězec poskytuje přístup k frontám služby Storage, objektům blob a tabulkám pro data aplikací. Poskytuje také přístup ke službě Service Bus pro zasílání zpráv a komunikaci. Pojmenovaná AzureWebJobsDashboard připojovací řetězec 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ů: Definování webových úloh 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í webu 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/<job name>

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

  • Soubory protokolu: Console.Out jsou zpracovávány nebo označeny 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. Soubory protokolu si můžete stáhnout přímo z webu. Soubory protokolu se ukládají do následujících umístění:

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

    • Pro průběžné nasazování: Vfs,data/jobs/continuous/<job name>

  • Konfigurace: Konfigurace webových úloh pomocí portálu, rozhraní REST API a PowerShellu. Pomocí konfiguračního souboru s názvem settings.job, který je ve stejném kořenovém adresáři jako skript webové úlohy, zadejte konfigurační informace pro webovou úlohu. Příklad:

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

Aspekty webových aplikací a webových úloh

  • Ve výchozím nastavení se WebJobs škálují s webovou aplikací. Chcete-li nakonfigurovat webové úlohy tak, aby běžely v jedné instanci, nastavte is_singleton vlastnost konfigurace na truehodnotu . 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í nebo analýza dat.

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

Azure Functions

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

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

Důležité informace o službě Azure Functions

Pokud očekáváte, že úloha na pozadí poběží po krátkou dobu v reakci na událost, zvažte spuštění úkolu v plánu Consumption. Modul runtime můžete nakonfigurovat na maximální dobu. Funkce, která běží pro delší náklady, více. Ú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, účtují se 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. Jako výhodu můžete použít další funkce, jako je integrace virtuální sítě.

Vyhrazený plán je vhodný pro úlohy na pozadí, pokud už vaše úloha běží na vyhrazeném plánu. Pokud máte nevyužité virtuální počítače, můžete na stejném virtuálním počítači spustit vyhrazený plán 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 napsané pro běhové prostředí, které se liší od prostředí, které je hostitelem aplikace. Můžete například použít program systému Unix nebo Linux, který chcete spustit z aplikace systému 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 službu nebo spustitelný soubor.

Další informace naleznete v tématu:

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

  • Odešlete požadavek do koncového bodu, který úloha zpřístupňuje ke spuštění úlohy na vyžádání přímo z vaší aplikace. Požadavek přenáší data, která úloha 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. Například ve Windows můžete 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, spusťte skripty a úlohy pomocí agenta SQL Serveru.

  • Pomocí Logic Apps zahajte ú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 můžete zahájit úlohy na pozadí, najdete v předchozí části Aktivační události .

Důležité informace o virtuálních počítačích

Při nasazování úloh na pozadí na 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 za účelem zajištění flexibility a přesné kontroly nad zahájením, nasazením, plánováním a přidělováním prostředků. Pokud ale nasadíte virtuální počítač výhradně pro úlohy na pozadí, náklady za běhu se zvýší.

  • Na portálu není k dispozici žádné zařízení pro monitorování úloh a žádné funkce automatizovaného restartování pro neúspěšné úlohy. Pomocí rutin Azure Resource Manageru 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. Obvykle platí, že pokud používáte virtuální počítač, musíte implementovat mechanismus, který shromažďuje data z instrumentace v úloze a také z operačního systému virtuálního počítače. K tomuto účelu můžete použít sadu System Center Management Pack pro Azure .

  • Zvažte vytvoření monitorovacích sond, které jsou vystavené prostřednictvím koncových bodů HTTP. Kód pro tyto sondy můžete nakonfigurovat tak, aby prováděl kontroly stavu a shromažďuje provozní informace a statistiky. Sondy můžete použít také ke kolaci informací o chybách a jejich vrácení do aplikace pro správu.

Další informace naleznete v tématu:

Batch

Zvažte službu 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čů.

Služba Batch slouží k přípravě virtuálních počítačů, přiřazování úkolů k virtuálním počítačům, spouštění úloh, monitorování průběhu a automatické škálování virtuálních počítačů v reakci na zatížení. Batch také poskytuje plánování úloh a podporuje virtuální počítače s Linuxem a Windows.

Aspekty služby Batch

Služba Batch je vhodná pro vnitřně paralelní úlohy. Službu Batch můžete použít k provádění paralelních výpočtů s krokem redukce na konci nebo spuštění aplikací MPI (Message Passing Interface) pro paralelní úlohy, které vyžadují předávání zpráv mezi uzly.

Úloha Batch běží ve fondu uzlů nebo virtuálních počítačů. 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ž přidělíte uzly. 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, které jsou nečinné.

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

  • Orchestrator kontejnerů slouží k internímu vyrovnávání zatížení, konfiguraci interní sítě a provádění dalších úloh konfigurace.

  • Kontejnery můžete podle potřeby spustit a zastavit.

  • Pomocí služby Azure Container Registry můžete své kontejnery zaregistrovat uvnitř hranic Azure, abyste zajistili výhody zabezpečení, ochrany osobních údajů a blízkosti.

Důležité informace o AKS

AKS vyžaduje pochopení toho, jak používat orchestrátor kontejnerů.

Další informace naleznete v tématu:

Container Apps

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

  • 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 je 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 architekturám aplikací řízených 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 službě Container Apps

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 Container Apps pro plně spravované prostředí. Container Apps je nejvhodnější pro vytváření mikroslužeb kontejnerů.

Další informace naleznete v tématu:

Kontrolní seznam pro spolehlivost

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

Kontrolní seznam pro spolehlivost