Ajánlott eljárások háttérfeladatokhoz

Számos alkalmazástípushoz szükség van olyan háttérfeladatokra, amelyek a felhasználói felülettől függetlenül futnak. Ilyenek például a kötegelt feladatok, az intenzív feldolgozási feladatok és a hosszan futó folyamatok, például a munkafolyamatok. A háttérfeladatok felhasználói beavatkozás nélkül futnak. Az alkalmazás elindítja a feladatot, és folytatja a felhasználóktól érkező interaktív kérések feldolgozását. Ez a megközelítés minimalizálja az alkalmazás felhasználói felületének terhelését, ami javítja a rendelkezésre állást, és csökkenti az interaktív válaszidőket.

Ha például egy alkalmazásnak miniatűröket kell létrehoznia a felhasználók által feltöltött képekből, futtathatja ezt a munkát háttérfeladatként, és a miniatűrt a tárolóba mentheti, ha elkészült. A felhasználónak nem kell várnia. Hasonlóképpen, a megrendelést leadó felhasználó elindíthat egy háttér-munkafolyamatot, amely feldolgozza a rendelést, míg a felhasználói felület lehetővé teszi a felhasználó számára a webalkalmazás tallózását. Amikor a háttérfeladat befejeződik, frissíti a tárolt rendelési adatokat, és e-mailt küld a felhasználónak a megrendelés megerősítéséhez.

Amikor megfontolja, hogy egy feladatot háttérmunkaként implementáljon-e, a fő kritérium az, hogy a tevékenység felhasználói beavatkozás nélkül futhat-e, és a felhasználói felület bevárná-e a befejezését. Előfordulhat, hogy azok a feladatok, amelyeknél a felhasználónak vagy a felhasználói felületnek várnia kell, amíg befejeződnek, nem megfelelőek háttérfeladatként.

Jótanács

Ez a cikk architekturális útmutatást nyújt az Azure-beli háttérfeladat-rendszerek tervezéséhez. Ez magában foglalja az üzemeltetési lehetőségeket, a tervezési alapelveket, a megbízhatóságot, a biztonságot, a megfigyelhetőséget és a skálázást. Ha egy háttérfeladatokat használó meglévő számítási feladat megbízhatósági felülvizsgálatát hajtja végre, tekintse meg az Azure Well-Architected-keretrendszerben a háttérfeladatok fejlesztésére vonatkozó javaslatokat , amely a megbízhatósági követelmények koncentrált ellenőrzőlistát biztosít.

A háttérmunkák típusai

A háttérfeladatok általában a következő típusú feladatok egy vagy több típusát tartalmazzák:

  • Processzorigényes feladatok, például matematikai számítások vagy szerkezeti modellek elemzése.

  • Bemeneti és kimeneti (I/O)-igényes feladatok, például tárolótranzakciók sorozata vagy fájlindexelés.

  • Kötegelt feladatok, például éjszakai adatfrissítések vagy ütemezett feldolgozás.

  • Hosszú ideig futó munkafolyamatok, például megrendelések teljesítése vagy szolgáltatások és rendszerek kiépítése.

  • Bizalmas adatfeldolgozás, amelyben a feladatot egy biztonságosabb helyre küldi feldolgozásra. Előfordulhat például, hogy nem szeretne bizalmas adatokat feldolgozni egy webalkalmazáson belül. Ehelyett a Gatekeeper-mintához hasonló mintát használhat az adatok egy elkülönített háttérfolyamatba való átviteléhez, amely hozzáfér a védett tárterülethez.

Kiváltó okok

A háttérfeladatokat többféleképpen is kezdeményezheti. Ezek a következő kategóriák egyikébe tartoznak:

Eseményvezérelt eseményindítók

Az eseményvezérelt meghívás eseményindítóval indítja el a háttérfeladatot. Példák az eseményvezérelt eseményindítókra:

  • A felhasználói felület vagy egy másik feladat üzenetsorba helyezi az üzenetet. Az üzenet adatokat tartalmaz egy végrehajtott műveletről, például a megrendelést küldő felhasználóról. A háttérfeladat az üzenetsoron figyeli az új üzeneteket. Felolvas egy üzenetet, és az adatokat használja a háttérfeladat bemeneteként. Ezt a mintát aszinkron üzenetalapú kommunikációnak nevezzük. Ha a kérelmek száma hirtelen megugrik, használja a Queue-Based Load Leveling mintát, hogy az üzenetsor pufferelje a terhelést, és a háttérfeladatok feldolgozása szabályozott sebességgel történjen.

  • A felhasználói felület vagy egy másik feladat egy értéket ment vagy frissít a tárterületen. A háttérfeladat figyeli a tárterületet, és észleli a változásokat. Beolvassa az adatokat, és a háttérfeladat bemeneteként használja.

  • A felhasználói felület vagy egy másik feladat kérést küld egy végpontra, például egy HTTPS egységes erőforrás-azonosítóra (URI), vagy egy webszolgáltatásként közzétett API-ra. Átadja a háttérfeladat végrehajtásához szükséges adatokat a kérés részeként. A végpont vagy a webszolgáltatás meghívja a háttérfeladatot, amely az adatokat használja bemenetként.

Az eseményvezérelt híváshoz alkalmas feladatok tipikus példái közé tartozik a képfeldolgozás, a munkafolyamatok, az információk távoli szolgáltatásokba való küldése, az e-mailek küldése és az új felhasználók kiépítése több-bérlős alkalmazásokban.

Ütemezésvezérelt eseményindítók

Az ütemezésalapú hívás időzítővel indítja el a háttérfeladatot. Példák az ütemezésvezérelt eseményindítókra:

  • Az alkalmazáson belül vagy az alkalmazás operációs rendszerének részeként helyileg futó időzítő rendszeresen meghív egy háttérfeladatot.

  • Egy másik alkalmazásban , például az Azure Logic Appsben futó időzítő rendszeresen küld kérést egy API-nak vagy webszolgáltatásnak. Az API vagy a webszolgáltatás meghívja a háttérfeladatot.

  • Egy külön folyamat vagy alkalmazás elindít egy időzítőt, amely egy adott idő elteltével vagy egy adott időpontban egyszer elindítja a háttérfeladatot.

Az ütemezésalapú híváshoz alkalmas feladatok tipikus példái közé tartoznak a kötegfeldolgozási rutinok (például a kapcsolódó termékek listájának frissítése a felhasználók számára a legutóbbi viselkedésük alapján), a rutinszerű adatfeldolgozási feladatok (például az indexek frissítése vagy a halmozott eredmények generálása), a napi jelentések adatelemzése, az adatmegőrzés törlése és az adatkonzisztencia-ellenőrzések.

Ha olyan ütemezésalapú feladatot használ, amelyet egyetlen példányként kell futtatnia, vegye figyelembe a következő szempontokat:

  • Ha skálázza az ütemezőt futtató számítási példányt, például egy Windows ütemezett feladatokat használó virtuális gépet (VM), akkor több ütemezőpéldányt is létrehoz. Ezek a példányok több feladatot is elindíthatnak. Úgy tervezzen ütemezett tevékenységeket, hogy idempotensek legyenek , hogy ugyanazon feladat többszöri futtatása ne eredményezzen ismétlődő eredményeket vagy következetlenségeket.

  • Ha a tevékenységek hosszabb ideig futnak, mint az ütemező eseményei közötti időszak, az ütemező elindíthatja a feladat egy másik példányát, miközben az előző példány fut.

Eredmények visszaadása

A háttérfeladatok aszinkron módon futnak egy külön folyamatban, vagy akár egy külön helyen, a felhasználói felülettől vagy az őket meghívó folyamattól. Ideális esetben a háttérfeladatok tűz- és felejtési műveletek, és feldolgozásuk előrehaladása nincs hatással a felhasználói felületre vagy a hívási folyamatra. A hívási folyamat nem várja meg a feladat befejezését, és nem tudja automatikusan észlelni a feladat befejeződését.

Ha egy háttérfeladatnak kommunikálnia kell a hívási tevékenységgel az előrehaladás vagy a befejezés jelzéséhez, implementálnia kell a feladathoz egy mechanizmust. A lehetőségek közé az alábbiak tartoznak:

  • Állapotvégpontot ad vissza a hívónak. A hívó egy URL-címet (vagy erőforrás-azonosítót) kap, amikor elküldi a feladatot, és lekérdezi az adott végpontot az állapothoz. Az aszinkron Request-Reply minta ezt a megközelítést írja le. Megfelel a HTTP-alapú API-knak, amelyekben a hívó elindít egy hosszú ideig futó műveletet, és ellenőriznie kell a befejezést.

  • Válaszsor használata. A háttérfeladat üzeneteket küld egy üzenetsorba, amelyet a hívó figyel. Az üzenetek állapotot és befejezést jeleznek. Ha az Azure Service Bus-t használja, a ReplyTo és CorrelationId tulajdonságok segítségével korrelálhatja a kérésekre adott válaszokat.

  • Értesítések leküldése eseményeken keresztül. A háttérfeladat egy eseményt tesz közzé, amikor befejeződik, vagy a fő mérföldköveknél. A hívó feliratkozik ezekre az eseményekre. Ez a megközelítés megfelel az Azure Event Gridnek a natív felhőbeli esemény-útválasztáshoz, vagy egy közzétételi és előfizetési mechanizmushoz, például a Service Bus-témakörökhöz.

  • Hívjon vissza a hívóhoz egy webhookon keresztül. A hívó egy visszahívási URL-címet biztosít a feladat elküldésekor. A háttérfeladat http-kérést küld az URL-címre a feldolgozás befejezésekor vagy hibák esetén. Ez a módszer akkor hasznos, ha a hívó egy külső rendszer.

  • Írja a státuszt a megosztott tárolóba. A háttérfeladat egy megosztott adattárba, például egy adatbázisba vagy blobba írja az előrehaladást vagy az eredményeket, amelyet a hívó figyel. Ez a megközelítés egyszerű, de a hívónak figyelnie kell a változásokra.

Az idempotencia tervezése

A háttérfeladatok különösen hajlamosak többször futni ugyanahhoz a logikai munkaelemhez. Az üzenetsorok legalább egyszer kézbesítik az üzeneteket, az időzítésük átlapolódhat, ha egy feladat az időzítőintervallumnál hosszabb ideig fut, és az infrastruktúra újraindítása újrafuttathatja a részben befejezett munkát. Tervezzen meg minden háttérfeladatot úgy, hogy ugyanaz a bemenet ugyanazt az eredményt hozza létre, amikor a feladat többször fut. További információ: Idempotens fogyasztói minta.

Üzemeltetési környezet

A háttérfeladatokat az Azure platformszolgáltatásainak széles skáláját használva végezheti el:

  • Azure Functions: Egy kiszolgáló nélküli számítási szolgáltatás, amely automatikus skálázással támogatja az eseményvezérelt és az ütemezésalapú eseményindítókat. A Durable Functions használata hosszú ideig futó vagy állapotalapú munkafolyamatokhoz.

  • Azure Container Apps: Kiszolgáló nélküli tárolóplatform, amely támogatja a hosszú ideig futó szolgáltatásokat és a különálló feladatokat is. A feladatok befejeződnek, és manuálisan, ütemezés szerint vagy események alapján aktiválhatja őket. A Container Apps a KEDA-t használja az eseményvezérelt automatikus skálázáshoz, beleértve a nullára való skálázást is.

  • Azure Kubernetes Service (AKS): Felügyelt Kubernetes-környezet, amely teljes körű felügyeletet biztosít a tároló vezénylése felett. A Kubernetes CronJobs és a Jobs használata háttérfeldolgozáshoz, ha közvetlen hozzáférésre van szüksége a Kubernetes API-hoz és a vezérlősíkhoz.

  • Azure Batch: Egy platformszolgáltatás, amely nagy számítási igényű munkát ütemez a felügyelt virtuális gépek gyűjteményén való futtatáshoz. Automatikusan skálázhatja a számítási erőforrásokat több tíz, több száz vagy több ezer csomópont között.

  • Azure-beli virtuális gépek: Infrastruktúra szolgáltatásként (IaaS) lehetőség olyan háttérfeladatokhoz, amelyek teljes körű felügyeletet igényelnek az operációs rendszer vagy a futtatókörnyezet felett, például Windows-szolgáltatások, külső végrehajtható fájlok vagy speciális futtatókörnyezetek.

  • Azure App Service WebJobs: Az App Service olyan funkciója, amely háttérszkripteket vagy programokat futtat ugyanabban a környezetben, mint egy webalkalmazás. Fontolja meg a WebJobs használatát, ha olyan háttérfeldolgozásra van szüksége, amely egy meglévő App Service-alkalmazással van együtt helyezve.

A következő szakaszok részletesebben ismertetik ezeket a lehetőségeket, és megfontolandó szempontokat tartalmaznak a megfelelő beállítás kiválasztásához.

Functions

A Functions egy kiszolgáló nélküli számítási szolgáltatás, amely eseményvezérelt kódot futtat. A függvények azért megfelelőek a háttérfeladatokhoz, mert különböző típusú eseményindítókat támogatnak, például üzenetsor-üzeneteket, blobtároló-módosításokat, időzítőütemezéseket, HTTP-kéréseket és Event Grid-eseményeket.

A rövid időtartamú háttérfeladatok esetében a Functions automatikus skálázást (beleértve a nullára történő skálázást) és a végrehajtásonkénti fizetéses számlázást is biztosítja. Hosszú ideig futó vagy állapotalapú munkafolyamatokhoz használja a Durable Functionst, amely vezénylési képességekkel bővíti a Functionst.

A Durable Functions számos vezénylési mintát támogat, amelyek közvetlenül alkalmazhatók a háttérfeladat-koordinációra:

  • Függvényláncolás: Futtasson egy függvénysorozatot egy adott sorrendben, amely az egyes lépések kimenetét a következőre továbbítja.

  • Kifúvatás/ventilátor be- és beillő: Futtasson több függvényt párhuzamosan, majd összesítse az eredményeket.

  • Aszinkron HTTP API-k: A hosszú ideig futó műveletek koordinálása külső ügyfelekkel lekérdezési végpont vagy webhook-visszahívás használatával.

  • Emberi interakció: Szüneteltethet egy vezénylést, amíg nem kap egy külső eseményt (például egy jóváhagyást), opcionálisan időtúllépésen alapuló eszkalációval.

  • Monitor: Olyan ismétlődő folyamat implementálása, amely egy feltételt kérdez le konfigurálható időközökkel és időtúllépésekkel.

Függvényekkel kapcsolatos szempontok

  • Válasszon üzemeltetési csomagot a számítási feladatok jellemzői alapján:

    • Rugalmas kihasználtságú csomag: A legjobb az időszakos vagy kiszámíthatatlan mennyiségű háttérfeladatokhoz. Munka hiányában nullára állítható, terhelés alatt pedig növelhető, végrehajtásonkénti számlázással. Az alapértelmezett függvény időtúllépése 30 perc, és nincs meghatározott maximális érték, a terv tehát mind rövid feladatok, mind hosszabb feldolgozás kezelésére alkalmas. Támogatja a virtuális hálózat integrációját, és a „mindig készen áll” példányokat a hidegindítási késleltetés csökkentése érdekében.

    • Prémium csomag: Megfelel a folyamatosan vagy közel folyamatosan futó nagy átviteli sebességű számítási feladatoknak. Előre előkészített példányokat biztosít a hidegindítások, a virtuális hálózati integráció és a hosszabb futási idők elkerülése érdekében.

    • Dedikált (App Service-) csomag: Függvények futtatása meglévő App Service-infrastruktúrán. Ez a lehetőség akkor megfelelő, ha nem kihasznált App Service-kapacitással rendelkezik, és meg szeretné osztani a számítási költségeket.

  • A Durable Functions automatikusan fenntartja a korchesztráció állapotát az ellenőrzőpontok használatával. Ha egy függvényalkalmazás újraindul, a vezénylés az utolsó ellenőrzőpontról folytatódik. Tervezzen olyan tevékenységfüggvényeket, amelyek idempotensek , hogy az újrapróbálkozás ne eredményezzen ismétlődő mellékhatásokat. Időzítő eseményindítókkal is futtathat függvényeket ütemezés szerint külső eseményforrás nélkül.

Container Apps

A Container Apps támogatja a háttérfeldolgozást a Container Apps-feladatokon keresztül, amelyek tárolóalapú feladatokat futtatnak a befejezéshez, majd leállnak. A feladatok megfelelnek a kötegelt feldolgozásnak, az ütemezett feladatoknak és az eseményvezérelt munkának, amelyben egy rövid életű folyamat egy különálló munkaegységet kezel. A platform általános áttekintéséhez tekintse meg a Container Apps áttekintését.

A Container Apps-feladatok három triggertípust támogatnak:

  • Manuális feladatok: Ezeket a feladatokat igény szerint aktiválhatja az Azure CLI-n, az Azure Portalon vagy az Azure Resource Manager API-n keresztül. Manuális feladatokat használhat olyan egyszeri feladatokhoz, mint az adatmigrálás vagy az alkalmazás által kezdeményezett igény szerinti feldolgozás.

  • Ütemezett feladatok: A CRON-kifejezések adott időpontokban aktiválják ezeket a feladatokat. Ütemezett feladatok használata éjszakai jelentésekhez, rendszeres adattisztításhoz vagy ismétlődő adatfeldolgozáshoz.

  • Eseményvezérelt feladatok: Az üzenetsorba érkező események aktiválják ezeket a feladatokat. A Container Apps a KEDA használatával figyeli az eseményforrásokat, és konfigurált szabályok alapján skálázza a feladatfuttatásokat. Az eseményvezérelt feladatok nullára skálázhatók, ha nincsenek feldolgozandó események. További információ: Eseményvezérelt feladat üzembe helyezése.

A folyamatosan futó háttérfeladatok, például egy üzenetsorból folyamatosan feldolgozó szolgáltatás esetében helyezzen üzembe egy tárolóalkalmazást feladat helyett. A tárolóalkalmazások hiba esetén automatikusan újraindulnak, és támogatják a skálázási szabályokat az üzenetsor hossza vagy más metrikák alapján.

A Container Apps figyelembevételei

  • A Container Apps-feladatokhoz tárolólemezképeket kell létrehoznia és karbantartania. Ez a megközelítés többletterhelést jelent a Functionshöz képest, de teljes mértékben szabályozhatja a feladathoz szükséges futtatókörnyezetet, függőségeket és operációsrendszer-szintű eszközöket.

  • Eseményvezérelt feladatok esetén ellenőrizze, hogy egy KEDA-skálázó támogatja-e az eseményforrást. A KEDA támogatja a Service Bust, az Azure Storage-üzenetsorokat, az Apache Kafkát, a RabbitMQ-t és más forrásokat.

  • Ha közvetlen hozzáférésre van szüksége a Kubernetes API-khoz és a vezérlősíkhoz, használja inkább az AKS-t .

AKS

Az AKS-t akkor használja, ha a háttérfeladatok közvetlen hozzáférést igényelnek a Kubernetes API-hoz, az egyéni ütemezési logikához vagy a csapat által üzemeltetett szélesebb Kubernetes-alapú platformmal való integrációhoz.

A Kubernetes CronJobs használata ütemezett háttérfeladatokhoz, és Jobs az egyszeri futtatású, befejezendő munkákhoz. A KEDA-t az AKS-sel is használhatja a feladatprocesszorok eseményvezérelt automatikus skálázására.

AKS-szempontok

** AKS esetében üzemeltetési ráfordításra van szükség a fürtkezeléshez, a frissítésekhez és a biztonsági javításokhoz. Ha nincs szüksége közvetlen Kubernetes API-hozzáférésre, a Container Apps-feladatok kevesebb többletterheléssel rendelkező felügyelt alternatívát biztosítanak.

Batch

Fontolja meg a Batch-t , ha nagy, párhuzamos, nagy teljesítményű számítási (HPC) számítási feladatokat kell futtatnia több tíz, több száz vagy több ezer virtuális gépen.

A Batch szolgáltatás kiosztja a virtuális gépeket, feladatokat rendel a virtuális gépekhez, futtatja a feladatokat, és figyeli az előrehaladást. A Batch automatikusan felskálázhatja a virtuális gépeket a számítási feladatra válaszul. A Batch feladatütemezést is biztosít. A Batch linuxos és Windows rendszerű virtuális gépeket is támogat.

Tétel szempontok

A Batch jól működik belsőleg párhuzamos számítási feladatokkal. Párhuzamos számításokat is végrehajthat egy csökkentési lépéssel a végén, vagy futtathat üzenetátadási felületi (MPI-) alkalmazásokat olyan párhuzamos feladatokhoz, amelyekhez a csomópontok közötti üzenetátadásra van szükség.

A Batch-feladat csomópontok halmazán (virtuális gépeken) fut. Az egyik módszer a készlet lefoglalása, ha szükséges, majd törölje azt a feladat befejezése után. Ez a megközelítés maximalizálja a kihasználtságot, mivel a csomópontok nem tétlenek, de a feladatnak várnia kell, amíg a Batch lefoglalja a csomópontokat. Azt is megteheti, hogy előre létrehoz egy készletet. Ez a megközelítés minimálisra csökkenti a feladat indításához szükséges időt, de tétlen csomópontokat eredményezhet. További információ: Készlet és számítási csomópont élettartama. A HPC-vel kapcsolatos szélesebb körű útmutatásért tekintse meg a Batch- és HPC-megoldásokat a nagy léptékű számítási feladatokhoz.

Virtual Machines

A háttérfeladatokhoz teljes operációsrendszer-környezetre vagy adott futtatókörnyezeti függőségekre lehet szükség, amelyek megakadályozzák, hogy platform- vagy kiszolgáló nélküli szolgáltatásokat használjanak. Ilyenek például a Windows-szolgáltatások, a végrehajtható fájlok és a speciális futtatókörnyezetekhez írt programok. Választhat az Azure virtuális gépein elérhető operációs rendszerek közül, és futtathatja a szolgáltatását vagy futtatható fájlját azon a virtuális gépen.

Ha egy külön virtuális gépen szeretné elindítani a háttérfeladatot, több lehetősége is van:

  • A feladatot igény szerint futtathatja közvetlenül az alkalmazásból, ha a kérését egy olyan végponthoz küldi, amelyet a feladat elérhetővé tesz. Ez a kérés minden olyan adatot átad, amelyet a feladat igényel. A végpont meghívja a feladatot.

  • Beállíthatja, hogy a feladat ütemezés szerint fusson a választott operációs rendszerben elérhető ütemező vagy időzítő használatával. Windows rendszeren például a Windows Feladatütemezővel futtathat szkripteket és feladatokat. Ha az SQL Server telepítve van a virtuális gépen, az SQL Server-ügynök használatával szkripteket és feladatokat futtathat.

  • A Logic Apps használatával kezdeményezheti a feladatot úgy, hogy egy üzenetet ad hozzá egy üzenetsorhoz, amelyet a tevékenység figyel, vagy ha egy kérést küld egy API-nak, amelyet a feladat elérhetővé tesz.

A háttérfeladatok indításáról további információt az Eseményindítók című témakörben talál.

A virtuális gépek szempontjai

Vegye figyelembe a következő szempontokat, amikor háttérfeladatokat helyez üzembe egy Azure-beli virtuális gépen:

  • A háttérfeladatok különálló Azure-beli virtuális gépeken való üzemeltetése rugalmasságot és pontos vezérlést biztosít a kezdeményezés, a feldolgozás, az ütemezés és az erőforrás-kiosztás felett. Ez a módszer azonban növeli a futásidejű költségeket, ha egy virtuális gépet csak háttérfeladatok futtatásához kell üzembe helyezni. Annak kiértékeléséhez, hogy a virtuális gép a megfelelő számítási modell-e, tekintse meg az Azure számítási szolgáltatás kiválasztása című témakört.

  • Az Azure Portal nem rendelkezik beépített eszközzel az egyes feladatok monitorozására, és nem rendelkezik automatikus újraindítási képességgel a sikertelen tevékenységekhez. A virtuális gép alapállapotát az Azure PowerShell-parancsmagok használatával monitorozhatja és kezelheti, de saját mechanizmusokat kell implementálnia a feladatból és az operációs rendszerből származó rendszerállapot-adatok gyűjtéséhez. Az Azure Monitor Agent használatával naplókat és metrikákat gyűjthet a virtuális gépről.

  • HTTP-végpontokon keresztül közzétett monitorozási mintavételek létrehozása. Ezeknek a mintavételeknek a kódjának állapot-ellenőrzéseket kell végeznie, működési információkat és statisztikákat kell gyűjtenie, vagy össze kellválogatnia a hibaadatokat, és vissza kell adnia egy felügyeleti alkalmazásnak. További információkért tekintse meg az állapotvégpont monitorozási mintáját.

App Service WebJobs

Az Azure WebJobs az App Service egyik funkciója, amely háttérszkripteket vagy programokat futtat ugyanabban a példányban, mint egy webalkalmazás. A WebJobs a webalkalmazás tesztkörnyezetében fut, ami azt jelenti, hogy hozzáférhetnek az alkalmazással megosztott környezeti változókhoz, kapcsolati sztringekhez és egyéb konfigurációkhoz. Az Azure WebJobs SDK-val egyszerűsítheti a gyakori háttérfeldolgozási feladatokhoz írt kódot.

Fontolja meg a WebJobs használatát, ha egy meglévő App Service-webalkalmazással rendelkezik, és olyan háttérfeldolgozásra van szüksége, amely ugyanazt az életciklust, konfigurációt és üzembe helyezést használja, mint a webalkalmazás. Nem javasoljuk, hogy a WebJobs általános célú háttérfeladat-platformként szolgáljon az új számítási feladatokhoz. Új eseményvezérelt vagy ütemezett háttérfeldolgozáshoz értékelje ki a Functions vagy a Container Apps feladatokat.

A WebJobs folyamatos vagy aktivált folyamatként is futtatható:

  • Folyamatos futtatás: A WebJob azonnal elindul, és hosszú ideig futó folyamatként fut. A szkript vagy a program a következő helyen van tárolva site/wwwroot/app_data/jobs/continuous: .

  • Futtatás ütemezés szerint vagy igény szerint: A CRON-kifejezésen vagy manuális műveleten keresztüli ütemezés aktiválja a WebJob-feladatot. A szkript vagy a program a következő helyen van tárolva site/wwwroot/app_data/jobs/triggered: .

Az App Service WebJobs szempontjai

  • Alapértelmezés szerint a WebJobs méretezhető a webalkalmazással. Beállíthatja egy feladatot, hogy egyedi példányként fusson, ha a is_singleton konfigurációs tulajdonságot true értékre állítja. Az egypéldányos WebJobs megfelel azoknak a feladatoknak, amelyeket nem szeretne egyszerre több példányként futtatni, például az újraindexelést vagy az adatelemzést.

  • A webalkalmazások teljesítményére gyakorolt hatás csökkentése érdekében érdemes lehet egy üres Azure-webalkalmazás-példányt létrehozni egy külön App Service-csomagban, amely hosszú ideig futó vagy erőforrásigényes WebJobs-feladatokat üzemeltet.

  • A WebJobs számítási erőforrásokat oszt meg a hoszt webalkalmazással. Az erőforrás-igényes háttérfeldolgozás csökkentheti a webalkalmazás válaszképességét.

Particionálás

Ha úgy dönt, hogy háttérfeladatokat vesz fel egy meglévő számítási példányba, fontolja meg, hogy ez a megközelítés hogyan befolyásolja a számítási példány minőségi attribútumait és magát a háttérfeladatot. Ezek a tényezők segítenek eldönteni, hogy a feladatokat a meglévő számítási példánnyal együtt helyezi-e el, vagy különíti-e el őket egy dedikált számítási példányra:

  • Elérhetőség: A háttérfeladatok gyakran jobban tolerálják a rövid kimaradásokat, mint a felhasználói felület, mert a függőben lévő munka várólistára állítható. Ha azonban az üzenetsor feltorlódik, mert a háttérfeldolgozás túl hosszú ideig nem érhető el, az alkalmazást érinti.

  • Helyreállítás: Ha egy olyan számítási példány meghibásodik, amely csak háttérfeladatokat üzemeltet, az alkalmazás továbbra is kiszolgálhatja a felhasználókat, amíg a függőben lévő munkát várólistára tesszük. Amikor a példány helyreáll, feldolgozza a hátralékot.

  • Biztonsági: A háttérfeladatokhoz a felhasználói felületnél eltérő erőforrásokhoz, hitelesítő adatokhoz vagy hálózati szegmensekhez kell hozzáférni. Ha külön számítási példányban futtatja őket, szigorúbb biztonsági határt alkalmazhat, például korlátozhatja a hálózati hozzáférést egy olyan adattárhoz, amelyet a felhasználói felület soha nem érhet el közvetlenül. A Gatekeeperhez hasonló mintázatokkal elkülönítheti a háttérszámítást a felhasználó által használt összetevőktől.

  • Kezelhetőség: A háttérfeladatok gyakran más kiadási ütemben változnak, mint a felhasználói felületen. A tevékenységek elkülönítése elkerüli a teljes alkalmazás újbóli üzembe helyezését, ha csak a feladatlogika változik.

  • Skálázhatóság: A háttérfeladatok általában a felhasználói felületétől eltérő jelekre skálázhatók. A háttérrendszerek skálázása az üzenetsor mélysége vagy a kötegméret alapján történik, míg a felhasználói felület az egyidejű felhasználók vagy a kérések aránya alapján skálázható. Az elkülönítésük lehetővé teszi, hogy minden tevékenység egymástól függetlenül skálázható legyen.

A háttérfeladatok dedikált számítási feladatokra való elkülönítése üzemeltetési költséget ad hozzá. Hasonlítsa össze ezt a költséget a független skálázás, üzembe helyezés és hibaelkülönítés működési előnyeihez.

Konfliktusok

Ha egy háttérfeladat több példányával rendelkezik, azok versenyezhetnek az erőforrásokhoz és szolgáltatásokhoz, például az adatbázisokhoz és a tárolókhoz való hozzáférésért. Ez az egyidejű hozzáférés erőforrás-versengést eredményezhet, ami befolyásolhatja a szolgáltatás rendelkezésre állását és az adatok integritását. Az erőforrás-versengést pesszimista zárolási megközelítéssel oldhatja meg. Ez a módszer megakadályozza, hogy egy feladat versengő példányai egyidejűleg hozzáférjenek egy szolgáltatáshoz, vagy megsérülhessenek az adatok.

Egy másik megközelítés úgy oldja fel az ütközéseket, hogy a háttérfeladatokat egyetlen példányként definiálja, így csak egy példány fut. Ez a megközelítés azonban kiküszöböli a többpéldányos konfiguráció megbízhatósági és teljesítménybeli előnyeit. Ez a hatás különösen akkor igaz, ha a felhasználói felület elegendő munkát tud biztosítani egynél több háttérfeladat foglaltságához.

Győződjön meg arról, hogy a háttérfeladat automatikusan újraindulhat, és elegendő kapacitással rendelkezik az igénycsúcsok kezeléséhez. Ennek az eredménynek az eléréséhez foglaljon le egy számítási példányt elegendő erőforrással, implementáljon egy várólistás mechanizmust, amely tárolja a későbbi feldolgozásra vonatkozó kérelmeket, amikor csökken az igény, vagy kombinálja mindkét technikát.

Koordináció

A háttérfeladatok összetettek lehetnek, és több különálló tevékenységet igényelnek az eredmény létrehozásához vagy az összes követelmény teljesítéséhez. Ezekben a forgatókönyvekben a csapatok gyakran kisebb, különálló lépésekre vagy altevékenységekre osztják a feladatot, amelyeket több felhasználó is futtathat. A többfeladatos feladatok gyakran növelik a hatékonyságot és a rugalmasságot, mivel több feladat is újra felhasználhatja az egyes lépéseket. A lépéseket hozzáadhatja, eltávolíthatja vagy átrendezheti.

A feladatok koordinálása kihívást jelenthet, de három gyakori minta irányíthatja a megvalósítást:

  • A tevékenységek több újrafelhasználható lépésre oszthatók. A háttérfeladatok több fázison keresztül dolgoznak fel adatokat, például érvényesítik, átalakítják és tárolják az adatokat. Ezt a folyamatot különálló szűrőkre oszthatja, amelyeket üzenetsorok kötnek össze. Minden lépés egymástól függetlenül fut, és skálázható vagy használható különböző feladatokban. További információ: Csövek és szűrők minta.

  • A feladat lépéseinek futtatási módjának kezelése. Egy több lépésből álló háttérfeladat, amely távoli szolgáltatásokat hív meg vagy távoli erőforrásokhoz fér hozzá, vezénylési logikára van szükség a lépések sorrendbe helyezéséhez, az időtúllépések kezeléséhez és az előrehaladás nyomon követéséhez. További információ: Scheduler Agent Supervisor pattern.

  • A sikertelen feladatlépések helyreállításának kezelése. Ha egy későbbi lépés meghiúsul, előfordulhat, hogy egy több lépésre kiterjedő háttérfeladatnak (amely együttesen definiál egy végül konzisztens műveletet) vissza kell vonnia a befejezett munkát. További információkért lásd a kompenzáló tranzakció mintáját.

Megbízhatósági szempontok

A háttérfeladatok rugalmasnak és helyreállíthatónak kell lenniük, hogy megbízható szolgáltatásokat nyújtsanak az alkalmazás számára. Háttérfeladatok tervezésekor vegye figyelembe a következő szempontokat:

  • A háttérfeladatoknak az adatok sérülése vagy inkonzisztencia nélkül kell kezelnie az újraindításokat. Hosszú ideig futó vagy többhelyes feladatok esetén érdemes lehet ellenőrzőpontot használni a feladat állapotának állandó tárolóba vagy üzenetsor-üzenetekbe való mentésével, ha szükséges. Például megőrizheti az állapotinformációkat egy üzenetsorban, és fokozatosan frissítheti ezt az állapotot a tevékenység előrehaladásával, hogy a tevékenység az első újraindítás helyett az utolsó ismert ellenőrzőpontról folytatódjon. A Service Bus üzenetsorok használatakor üzenet-szekciók segítségével mentheti és lekérheti az alkalmazásfeldolgozási állapotot. A megbízható többlépéses folyamatok és munkafolyamatok tervezésével kapcsolatos további információkért tekintse meg a Scheduler Agent Supervisor mintáját.

  • Tervezzen háttérfeladatokat a zökkenőmentes leállításhoz, amikor az üzemeltetési platform jelzi a leállítást. Az üzembe helyezés, a méretcsökkentési események és a platformkarbantartás bármikor leállíthat egy futó példányt. Ha egy háttérfeladat leállítási jelet kap futás közben (például SIGTERM a tárolókban), le kell állítania az új munka fogadását, be kell fejeznie vagy ellenőriznie kell az aktuális munkaelemet, és tiszta módon kell kilépnie. Az üzenetsor-alapú feladatoknál a kíméletes leállítás azt jelenti, hogy az aktuális üzenetet a folyamat kilépése előtt fejezi be, hogy az üzenetet ne kézbesítsék szükségtelenül újra. Ha a tevékenység nem fejeződhet be időben, ellenőriznie kell a folyamat előrehaladását, vagy hagyja, hogy az üzenet láthatósági időtúllépése lejárjon, hogy egy másik példány feldolgozza a munkát.

    Állítsa be a platform leállítási türelmi időszakát olyan hosszúra, hogy a tipikus munkaelem befejeződhessen. A Kubernetesben terminationGracePeriodSeconds állítsa be a pod specifikáción. A Functions Flex Fogyasztási és Prémium csomagokban a platform automatikusan akár 60 percet is biztosít a folyamatban lévő munka befejezéséhez a skálázás befelé során.

  • Ha üzenetsorokat használ a háttérfeladatokkal való kommunikációhoz, az üzenetsorok pufferként funkcionálhatnak a kérések tárolásához, miközben az alkalmazás a szokásosnál nagyobb terhelés alatt van. Ez a kialakítás lehetővé teszi, hogy a feladatok kevésbé elfoglalt időszakokban utolérjék a felhasználói felületet. Azt is jelenti, hogy az újraindítások nem blokkolják a felhasználói felületet. További információ: Queue-Based Terhelés simítási mintája. Ha egyes tevékenységek fontosabbak, mint mások, fontolja meg a prioritási várólista-minta implementálását, hogy ezek a tevékenységek a kevésbé fontos tevékenységek előtt fussanak.

  • A háttérfeladatok, amelyeket az üzenetek kezdeményeznek, vagy amelyek feldolgozzák az üzeneteket, kezelni kell az inkonzisztenciákat, például a sorrendből érkező üzeneteket, az ismétlődően hibát okozó üzeneteket (más néven méregüzeneteket), valamint az egynél többször kézbesített üzeneteket. Fontolja meg a következő tényezőket:

    • Előfordulhat, hogy a rendezett feldolgozást igénylő üzenetek, például az aktuális adatértéktől függő frissítések nem érkeznek meg az elküldött sorrendben. Másik lehetőségként a háttérfeladatok különböző példányai is eltérő sorrendben kezelhetik őket, mivel az egyes példányok terhelése eltérő. Az adott sorrendben feldolgozandó üzeneteknek tartalmazniuk kell egy sorszámot, kulcsot vagy egy másik mutatót, amelyet a háttérfeladatok a megfelelő feldolgozási sorrend biztosítása érdekében használhatnak. A Service Bus használata esetén üzenet-munkamenetekkel garantálhatja a kézbesítés sorrendjét. A folyamat tervezése azonban gyakran hatékonyabb, ha lehetséges, így az üzenetsorrend nem számít.

    • A háttérfeladatok általában az üzenetsor üzeneteibe néznek, amelyek ideiglenesen elrejtik őket más üzenetfogyasztók elől. Miután a feladat sikeresen feldolgozta az üzenetet, törli azt. Ha egy háttérfeladat meghiúsul egy üzenet feldolgozásakor, az üzenet a betekintő időtúllépés lejárta után újra megjelenik az üzenetsoron. Ezután a feladat egy másik példányát vagy ennek a példánynak a következő feldolgozási ciklusát dolgozza fel. Ha az üzenet következetesen hibát okoz a fogyasztóban, letiltja a feladatot, az üzenetsort és végül az alkalmazást, amikor az üzenetsor megtelik. Mérgező üzenetek észlelése és eltávolítása az üzenetsorból. A Service Bus használata esetén automatikusan áthelyezheti a hibát okozó üzeneteket, vagy manuálisan is áthelyezheti őket egy társított kézbesítetlen levelek üzenetsorába.

    • Az üzenetsorok legalább egy kézbesítési mechanizmust garantálnak, ami azt jelenti, hogy egy üzenet többször is kézbesíthető. Ha egy háttérfeladat meghiúsul egy üzenet feldolgozása után, de mielőtt törölné azt az üzenetsorból, az üzenet ismét feldolgozásra válik. Minden üzenetvezérelt háttérfeladatnak idempotensnek kell lennie. További információ: Tervezés idempotencia esetén.

  • Különbséget kell tenni az átmeneti hibák és a feladatfeldolgozó állandó hibái között. Ha egy háttérfeladat nem tud feldolgozni egy üzenetet, az üzenetsor automatikusan újra kézbesíti azt. Ha a hiba átmeneti, például egy alrendszeri időtúllépés vagy forráskorlátozásra adott válasz esetén, a redelivery a kívánt módon működik. Ha a hiba végleges, például egy rosszul formázott csomag vagy hiányzó hivatkozott adat miatt, az üzenet minden kísérletnél meghiúsul. Állítsa be a feladatfeldolgozót, hogy észlelje az állandó hibákat, és az újrapróbálkozási kísérletek helyett közvetlenül egy kézbesítetlen üzenetsorba irányítja az üzeneteket. Az üzenetsor maximális kézbesítési száma határozza meg, hogy az üzenetsor hányszor próbálkozik újra egy üzenettel, mielőtt automatikusan áthelyezi a holttároló sorba. Az átmeneti feltételek feldolgozási logikában való kezeléséről további információt az Átmeneti hibakezelés című témakörben talál.

Biztonsági szempontok

A háttérfeladatok gyakran szélesebb körű hozzáféréssel futnak az adattárakhoz, API-khoz és belső szolgáltatásokhoz, mint a felhasználó által használt alkalmazás. A háttérfeladatok biztonságának tervezésekor vegye figyelembe a következő szempontokat:

  • Minimális jogosultsági szintű hozzáférés biztosítása a feladatprocesszorokhoz. Az üzenetsorból beolvasott és adatbázisba írt háttérfeladatoknak csak engedéllyel kell rendelkezniük a két művelet végrehajtásához. Ne használjon újra olyan széles körű alkalmazásidentitást, amely a felhasználói felületet vagy a rendszergazdai API-kat is kiszolgálja. Ha egy feladatfeldolgozó biztonsága sérül, a hatás hatóköre a megadott engedélyekre korlátozódik.

  • Ne helyezzen bizalmas adatokat az üzenet terhelése közé. A hibakeresés során a sorban lévő üzenetek naplózhatók, halott levélbe helyezhetők vagy megvizsgálhatók. Ahelyett, hogy bizalmas adatokat, például személyes adatokat vagy hitelesítő adatokat helyezne el közvetlenül egy üzenetben, tárolja az adatokat egy védett adattárban, és adjon meg egy hivatkozásazonosítót abban az üzenetben, amelyet a feladat az adatok lekérésére használ.

Megfigyelhetőségi szempontok

A háttérfeladatok felhasználó jelenléte nélkül futnak, ezért a hibák csendben maradnak, hacsak nem figyeli őket aktívan. Ha a háttérfeladatok megfigyelhetőségét tervezi, vegye figyelembe a következő szempontokat:

  • Kövessük nyomon a feladat befejezését is, ne csak a feladat megkezdését. Naplózza, ha egy háttérfeladat elindul, befejeződik és sikertelen lesz. Adja meg a feladat típusát, egy korrelációs azonosítót, amely a feladatot az eseményindító eseményhez vagy üzenethez csatolja, valamint az eltelt időtartamot. A befejezés nyomon követése nélkül egy csendben lefagyó vagy összeomló feladat úgy tűnik, mintha normálisan futna.

  • Riasztás az elmulasztott ütemezésekről. Ütemezésalapú tevékenységek esetén figyelje meg, hogy minden várható futtatás megtörténik-e. Ha egy ütemezett feladat nem indul el, nincs hiba, mert semmi sem futott. Hasonlítsa össze a tényleges futási időket a várt ütemezéssel és riasztással, ha hiányzik egy futtatás.

  • Üzenetsorok figyelése. A halott betűs üzenetek olyan háttérmunkát képviselnek, amely nem fejeződött be. Állítson be riasztásokat a kézbesítetlen levelek üzenetsorának mélységéről és az üzenetek koráról, hogy a műveleti csapat kivizsgálhassa a hibákat, kijavíthassa a mögöttes problémát, és újra elküldhesse az üzeneteket. Figyelés nélkül a sikertelen munka halmozódik fel csendben.

  • Az üzenetsor várakozási idejének mérése, nem csak a feldolgozási idő. Az üzleti hatást az határozza meg, hogy mennyi ideig tart egy üzenet az előkészítéstől a befejezésig. Például, ha egy feladat 2 másodperc alatt feldolgozásra kerül, de 30 percig várakozik a sorban, 30 perces késést okoz. Kövesse nyomon a feladatok sorba állításától a befejezésig tartó késleltetést, valamint a feladatonkénti feldolgozási időtartamot.

  • Korreláció a feladat lépései között. A többlépcsős háttérfeladatok több szolgáltatásra, üzenetsorra és számítási példányra kiterjedhetnek. Minden lépésben propagálja a korrelációs azonosítót, hogy egyetlen munkaelem teljes életciklusát nyomon tudja követni a naplókban és az elosztott nyomkövetésekben.

Méretezési és teljesítménybeli szempontok

A háttérfeladatoknak lépést kell tartaniuk a munka érkezési sebességével. Ha a tevékenységek lemaradnak, az üzenetsorok növekednek, a késés nő, és az alárendelt folyamatok elakadnak. Ha a háttérfeladatok méretezését tervezi, vegye figyelembe a következő szempontokat:

  • A skálázást az üzenetsorok mélységére helyezd, ne csak a CPU-ra. Az üzenetvezérelt háttérfeladatok esetében a leghasznosabb skálázási jel az, hogy mennyi munka vár a sorban, nem pedig az aktuális példányok leterheltsége. A függvények, a Container Apps és az AKS ( KEDA-n keresztül) mind támogatják a skálázást az üzenetsor hossza, a témakör-előfizetések száma vagy más eseményforrás-metrikák alapján. Ez a megközelítés kapacitást ad hozzá, amikor a munka felhalmozódik, és csökkenti a kapacitást, amikor a sorok kiürülnek.

  • Időszakos számítási feladatokhoz használjon skálázást nullára. Ha a háttérfeladatok csak meghatározott időpontokban futnak, például az éjszakai kötegelt feladatok vagy az üresjárati időszakokkal rendelkező eseményvezérelt feldolgozás, használjon olyan üzemeltetési modellt, amely nullára skáláz, ha nincs munka. A függvények és a tárolóalkalmazások feladatai nullára skálázhatók, így nem kell fizetnie a kihasználatlan számítási kapacitásért.

  • A háttérfeladatok skálázása az alkalmazástól függetlenül. Háttérfeladatokat üzemeltet egy külön számítási szolgáltatásban, hogy a felhasználói felület és a háttérfeldolgozás különböző jeleken skálázható legyen. Ha több háttérfeladattípussal rendelkezik, amelyek eltérő átviteli sebességgel rendelkeznek, érdemes elkülöníteni őket, hogy minden típus egymástól függetlenül skálázható legyen.

  • A teljes feldolgozási folyamat skálázása, nem csak a számítás. A további feladatpéldányok nem segítenek, ha az üzenetsor, az adatbázis vagy az alárendelt API szűk keresztmetszetté válik. Azonosítsa a folyamat átviteli sebességkorlátait, beleértve az üzenetkezelési átviteli egységeket, az adatbázis-kérelemegységeket és az API sebességkorlátait. Skálázza ezeket az erőforrásokat a számítógépes kapacitásokkal együtt.

  • Szükség esetén kényszerítse ki az egypéldányos végrehajtást. Egyes ütemezett háttérfeladatok nem futtathatók párhuzamosan, például az adatbázis-karbantartás vagy a nem idempotens jelentéskészítés. A függvény időzítő eseményindítói elosztott zárolással biztosítják, hogy csak egy példány fusson. Tárolók esetén használja a Kubernetes CronJob concurrencyPolicy: Forbid beállítást vagy a Container Apps feladatszintű egyidejűségi beállításait.

Következő lépések

  • Utolsó frissítés időpontja: