Háttérfeladatok

  • Cikk

Számos különböző típusú alkalmazásban van szükség olyan háttérfeladatokra, amelyek a felhasználói felülettől függetlenül futnak. Ilyenek lehetnek a kötegelt feladatok, az intenzív feldolgozási feladatok és a hosszú futású folyamatok, például a munkafolyamatok. A háttérfeladatok felhasználói beavatkozás nélkül hajthatók végre – az alkalmazás a feladat elindítását követően folytathatja a felhasználók interaktív kéréseinek feldolgozását. Ez segít csökkenteni az alkalmazás felhasználói felületének terhelését, ami javíthatja a rendelkezésre állást és csökkentheti az interaktív válaszidőket.

Például ha egy alkalmazás bélyegképeket hoz létre a felhasználók által feltöltött képekhez, azt megteheti háttérfeladatként is, a bélyegképeket azok elkészültekor a tárolóba mentve – anélkül, hogy a felhasználónak meg kellene várnia a folyamat befejeztét. Például egy megrendelés feladása esetén a felhasználó ugyanígy inicializálja a megrendelést feldolgozó háttér-munkafolyamatot, majd a felhasználói felületen folytathatja a webes alkalmazás böngészését. Ha a háttérben futó feladat befejeződött, az frissítheti a tárolt rendelési adatokat, és e-mailben visszaigazolhatja a megrendelést a felhasználónak.

Amikor azt mérlegeli, hogy egy adott feladat háttérfeladatként legyen-e végrehajtva, a fő szempont, hogy a feladat képes-e felhasználói beavatkozás nélkül futni, illetve anélkül, hogy a felhasználói felület megvárná a feladat befejezését. Az olyan feladatok, amelyekhez szükséges, hogy a felhasználó vagy a felület várakozzon, nem alkalmasak háttérben való futtatásra.

Háttérfeladatok típusai

A háttérfeladatok rendszerint a következő típusú feladatok közül egyet vagy többet tartalmaznak:

  • Számításigényes feladatok, például matematikai számítások vagy szerkezeti modellek elemzése.
  • Adatátvitel-igényes feladatok, például tárolási tranzakciók sorozatának végrehajtása vagy fájlok indexelése.
  • Kötegelt feladatok, például éjszakai adatfrissítések vagy ütemezett feldolgozás.
  • Hosszan futó munkafolyamatok, például megrendelések teljesítése vagy szolgáltatások és rendszerek üzembe helyezése.
  • Bizalmas adatok feldolgozása, ahol a feladat egy biztonságosabb helyre lesz továbbítva feldolgozásra. Például előfordulhat, hogy a bizalmas adatokat nem szeretné egy adott webalkalmazáson belül feldolgozni. Ehelyett használhat egy mintát, például a Gatekeeper-mintát az adatok egy elkülönített háttérfolyamatba való átviteléhez, amely hozzáféréssel rendelkezik a védett tárterülethez.

Triggerek

A háttérben futó feladatok számos különböző módon indíthatók el. Az alábbi kategóriák valamelyikébe tartoznak:

  • Eseményvezérelt eseményindítók. A feladat egy eseményre, általában a felhasználó által végrehajtott műveletre vagy a munkafolyamat egy lépésére válaszképpen indul.
  • Ütemezésvezérelt eseményindítók. A feladatot egy időzítésen alapuló ütemezés indítja el. Ez lehet egy ismétlődő ütemezés szerint vagy egy egyszeri hívás, amely egy későbbi időpontra lett megadva.

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

Az eseményvezérelt hívás egy eseményindító segítségével indítja el a háttérfeladatot. Példa az eseményvezérelt eseményindítókra:

  • A felhasználói felület vagy egy másik feladat egy üzenetet küld az üzenetsorba. Az üzenet egy lezajlott művelettel kapcsolatos adatokat tartalmaz, például egy felhasználó rendelését. A háttérfeladat figyeli ezt az üzenetsort, és észleli az új üzenet megérkezését. Kiolvassa az üzenetet, és az adatait használja a háttérfeladat bemeneti adataiként. Ezt a mintát aszinkron üzenetalapú kommunikációnak nevezzük.
  • A felhasználói felület vagy egy másik feladat ment vagy frissít egy értéket a tárolóban. A háttérfeladat figyeli a tárolót, és észleli a változásokat. Kiolvassa az adatokat, és azokat használja a háttérfeladat bemeneti adataiként.
  • A felhasználói felület vagy egy másik feladat egy kérést küld egy végpontra, például egy HTTPS URI azonosítóra vagy egy webszolgáltatásként megnyitott API-ra. A háttérfeladat végrehajtásához szükséges adatokat a kérés részeként továbbítja. A végpont vagy a webszolgáltatás meghívja a háttérfeladatot, amely az adatokat használja bemenetként.

Tipikus példák az eseményvezérelten meghívható feladatokra a képfeldolgozás, a munkafolyamatok, az adatok távoli szolgáltatásoknak való küldése, az e-mailek küldése, valamint az új felhasználók létrehozása több-bérlős alkalmazásokban.

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

Az ütemezésvezérelt hívás egy időzítő segítségével indítja el a háttérfeladatot. Példa 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őtartam elteltével vagy egy adott időpontban kezdeményezi a háttérfeladat meghívását.

Az ütemezésvezérelten meghívható feladatokra tipikus példák a kötegelt feldolgozási rutinok (például a kapcsolódó termékek listájának frissítése a felhasználók legutóbbi tevékenységei alapján), a rutinszerű adatfeldolgozási feladatok (például az indexek frissítése vagy a halmozott eredmények létrehozása), az adatok elemzése a napi jelentésekhez, a megőrzött adatok törlése, valamint az adatkonzisztencia ellenőrzése.

Ha egy olyan ütemezésvezérelt feladatot használ, amelynek egyetlen példányként kell futnia, figyeljen a következőkre:

  • Ha átméretezi a feladatütemezőt futtató számítási példányt (például a Windows ütemezett feladatait használó virtuális gépet), a feladatütemező több példányban fog futni. Ezek a feladatnak egyszerre több példányát is elindíthatják. Erről további információt ebben a blogbejegyzésben talál az idempotencia témakörében.
  • Ha a feladatok hosszabb ideig futnak, mint az ütemezett események között eltelt időtartam, a feladatütemező elindíthatja a feladat egy újabb példányát, miközben az előző még mindig fut.

Eredmények visszaadása

A háttérfeladatok aszinkron módon futnak a felhasználói felülethez vagy a háttérfeladatot meghívó folyamathoz képest – egy külön folyamatban, sőt akár külön helyen is. Ideális esetben a háttérfeladatok "tűz és felejtés" műveletek, és végrehajtásuk előrehaladása nincs hatással a felhasználói felületre vagy a hívási folyamatra. Ez azt jelenti, hogy a meghívó folyamat nem vár a feladatok befejezésére. Emiatt nem is képes automatikusan észlelni, ha a feladat befejeződik.

Amennyiben szükséges, hogy a háttérfeladat kommunikálja a meghívó feladatnak a végrehajtás folyamatát vagy befejeztét, erre ki kell alakítani valamilyen mechanizmust. Néhány példa:

  • Állapotjelző érték beírása egy, a felhasználói felület vagy a meghívó feladat által elérhető tárolóba, így az szükség esetén figyelheti és ellenőrizheti ezt az értéket. A háttérfaladat által a meghívónak visszaadandó egyéb adatok is elhelyezhetők ugyanebben a tárhelyben.
  • Egy, a felhasználói felület vagy a meghívó által figyelt válaszüzenetsor létrehozása. A háttérfeladat az állapotot vagy a befejezést jelző üzeneteket küldhet az üzenetsorra. A háttérfaladat által a meghívónak visszaadandó adatok is elhelyezhetők ezekben az üzenetekben. Az Azure Service Bus alkalmazása esetén használhatja a ReplyTo és a CorrelationId tulajdonságot ennek a képességnek az implementálásához.
  • Elérhetővé tehet egy API-t vagy végpontot a háttérfeladatból, amelyet a felhasználói felület vagy a meghívó el tud érni az állapotadatok beszerzéséhez. A háttérfaladat által a meghívónak visszaadandó adatok is részét képezhetik ennek a válasznak.
  • A háttérfeladat visszahívást kezdeményezhet a felhasználói felület vagy a hívó felé egy API-n keresztül, és előre meghatározott pontokon vagy a befejezéskor jelezheti az állapotát. Ez történhet helyben létrehozott eseményeken vagy egy közzétételi-előfizetési mechanizmuson keresztül. A háttérfaladat által a meghívónak visszaadandó adatok is részét képezhetik ennek a kérésnek vagy az esemény hasznos adatainak.

Üzemeltetési környezet

A háttérfeladatokat futtathatja számos különböző Azure platformszolgáltatás használatával:

  • Azure Web Apps és WebJobs. A WebJobs használatával egy webalkalmazás kontextusában egyéni feladatokat hajthat végre számos különböző típusú szkript vagy végrehajtható program alapján.
  • Azure Functions-függvények. Olyan háttérfeladatokhoz is használhat függvényeket, amelyek hosszú ideig nem futnak. Egy másik használati eset az, ha a számítási feladat már az App Service-csomagban van üzemeltetve, és kihasználatlan.
  • Azure Virtual Machines. Ha Windows-szolgáltatással rendelkezik, vagy a Windows Feladatütemezőt szeretné használni, általános érdemes a háttérfeladatokat egy dedikált virtuális gépen futtatnia.
  • Azure Batch. A Batch platformszolgáltatás számításigényes munkák futtatását ütemezi virtuális gépek felügyelt gyűjteményében. Automatikusan képes méretezni a számítási erőforrásokat.
  • Azure Kubernetes Service (AKS). Az Azure Kubernetes Service felügyelt üzemeltetési környezetet biztosít a Kubernetes számára az Azure-ban.
  • Azure Container Apps. Az Azure Container Apps lehetővé teszi, hogy tárolók alapján kiszolgáló nélküli mikroszolgáltatásokat hozzon létre.

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

Azure Web Apps és WebJobs

Az Azure WebJobs használatával egyéni feladatokat hajthat végre háttérfeladatként egy Azure Web App-webalkalmazásban. A WebJobs-feladatok a webalkalmazás kontextusában futnak, folyamatosan működő folyamatokként. A WebJobs az Azure Logic Apps eseményindító eseményére vagy külső tényezőkre, például a tárolóblobok és üzenetsorok változásaira reagálva is fut. A feladatok igény szerint indíthatók és állíthatók le, és szabályosan állnak le. Ha egy folyamatosan futó WebJobs-feladat leáll, automatikusan újraindul. Az újrapróbálkozási és hibaműveletek konfigurálhatók.

WebJobs-feladatok konfigurálásakor:

  • Ha azt szeretné, hogy a feladat egy eseményvezérelt eseményindítóra válaszoljon, a Folyamatos futtatás beállítással kell konfigurálnia. A szkript vagy a program a site/wwwroot/app_data/jobs/continuous mappában lesz tárolva.
  • Ha azt szeretné, hogy a feladat egy ütemezésvezérelt eseményindítóra válaszoljon, az Ütemezett futtatás beállítással kell konfigurálnia. A szkript vagy a program a site/wwwroot/app_data/jobs/triggered mappában lesz tárolva.
  • Ha valamely feladat konfigurálásakor az Igény szerinti futtatás beállítást választja, az az indításakor ugyanazt a kódot fogja végrehajtani, mint az Ütemezett futtatás beállítás.

Az Azure WebJobs-feladatok egy webalkalmazás elkülönített környezetében futnak. Ez azt jelenti, hogy hozzáféréssel rendelkeznek a környezeti változókhoz, és megoszthatják az információkat, például a kapcsolati sztringeket a webalkalmazással. A feladat eléri az azt futtató gép egyedi azonosítóját. Az AzureWebJobsStorage nevű kapcsolati sztring hozzáférést biztosít az Azure Storage-üzenetsorokhoz, blobokhoz és táblákhoz az alkalmazásadatokhoz, valamint hozzáférést biztosít a Service Bushoz üzenetkezeléshez és kommunikációhoz. Az AzureWebJobsDashboard kapcsolati sztring a feladat műveleti naplófájljaihoz biztosít hozzáférést.

Az Azure WebJobs-feladatok a következő jellemzőkkel rendelkeznek:

  • Biztonság: A WebJobs-feladatokat a webalkalmazás üzembehelyezési hitelesítő adatai védik.
  • Támogatott fájltípusok: A WebJobs definiálásához parancsszkripteket (.cmd), batch-fájlokat (.bat), PowerShell-szkripteket (.ps1), Bash-rendszerhéj-szkripteket (.sh), PHP-szkripteket (.php), Python-szkripteket (.py), JavaScript-kódot (.js) és végrehajtható programokat (.exe.jarstb.) használhat.
  • Üzembe helyezés: Szkripteket és végrehajtható fájlokat az Azure Portalon, a Visual Studióval, az Azure WebJobs SDK-val vagy közvetlenül a következő helyekre másolva helyezhet üzembe:
    • Eseményindító által indított végrehajtás esetén: site/wwwroot/app_data/jobs/triggered/{feladat neve}
    • Folyamatos végrehajtás esetén: site/wwwroot/app_data/jobs/continuous/{feladat neve}
  • Naplózás: A Console.Out INFO-ként van kezelve (megjelölve). A Console.Error HIBA-ként van kezelve. A monitorozási és diagnosztikai adatok az Azure Portalon keresztül érhetők el. A naplófájlok közvetlenül is letölthetők a webhelyről. A rendszer a következő helyekre menti őket:
    • Eseményindító által indított végrehajtás esetén: Vfs/data/jobs/triggered/feladatNeve
    • Folyamatos végrehajtás esetén: Vfs/data/jobs/continuous/feladatNeve
  • Konfiguráció: A WebJobs-feladatok a portál, a REST API és a PowerShell használatával konfigurálhatók. A feladat szkriptjének gyökérkönyvtárába mentett, settings.job nevű konfigurációs fájllal adhatja meg a feladat konfigurációs adatait. Például:
    • { "stopping_wait_time": 60 }
    • { "is_singleton": true }

Megfontolások

  • Alapértelmezés szerint a WebJobs-feladatok a webalkalmazással együtt méreteződnek. Az is_singleton konfigurációs tulajdonság true (igaz) értékre állításával azonban konfigurálhatja úgy a feladatokat, hogy egyetlen példányon fussanak. Az egypéldányos WebJobs-feladatok az olyan tevékenységekhez hasznosak, amelyeket nem szeretne méretezni vagy egyidejűleg több példányban futtatni, például újraindexeléshez, adatelemzéshez és hasonló feladatokhoz.
  • A feladatoknak a webalkalmazás teljesítményére gyakorolt hatásának minimalizálása érdekében érdemes lehet létrehozni egy üres Azure Web App-példányt egy új App Service-csomagban, amely hosszú ideig futó vagy erőforrásigényes WebJobs-feladatokat üzemeltet.

Azure Functions

A WebJobshoz hasonló lehetőség az Azure Functions. Ez a szolgáltatás kiszolgáló nélküli, amely alkalmas a rövid ideig futó eseményvezérelt eseményindítókhoz. Egy függvény az ütemezett feladatok időzítő eseményindítókon keresztüli futtatására is használható, ha beállított időpontokban való futtatásra van konfigurálva.

Az Azure Functions nem ajánlott nagy, hosszú ideig futó feladatokhoz, mert váratlan időtúllépési problémákat okozhatnak. Az üzemeltetési tervtől függően azonban az ütemezésalapú eseményindítók esetében is figyelembe vehetők.

Megfontolások

Ha a háttérfeladat várhatóan rövid ideig fog futni egy eseményre válaszul, érdemes lehet a tevékenységet egy használati tervben futtatni. A végrehajtási idő legfeljebb a maximális időtartamig konfigurálható. Egy függvény, amely hosszabb költségekkel jár. A több memóriát használó processzorigényes feladatok is drágábbak lehetnek. Ha a tevékenység részeként további eseményindítókat használ a szolgáltatásokhoz, azok külön kerülnek számlázásra.

A Prémium csomag akkor megfelelőbb, ha sok olyan feladat van, amely rövid, de várhatóan folyamatosan fut. Ez a terv drágább, mert több memóriára és processzorra van szüksége. Ennek az az előnye, hogy olyan funkciókat használhat, mint a virtuális hálózat integrációja.

A dedikált csomag akkor alkalmas a háttérfeladatokra, ha a számítási feladat már fut rajta. Ha nem kihasznált virtuális gépekkel rendelkezik, ugyanazon a virtuális gépen futtathatja, és megoszthatja a számítási költségeket.

További információval a következő cikkek szolgálnak:

Azure Virtual Machines

Előfordulhat, hogy a háttérfeladatok olyan módon implementálhatók, amely megakadályozza az Azure Web Appsben való üzembe helyezésüket, vagy ezek a beállítások nem lesznek kényelmesek. Tipikus példák erre a Windows-szolgáltatások, valamint a külső fejlesztők által készített segédprogramok és végrehajtható programok. További példák lehetnek az alkalmazást futtató környezettől eltérő végrehajtási környezethez írt programok. Például rendelkezhet egy olyan Unix- vagy Linux-programmal, amelyet egy Windows- vagy .NET-alkalmazásból kíván végrehajtatni. Az Azure-beli virtuális gépek esetében számos különféle operációs rendszer közül választhat, és a szolgáltatásokat és a végrehajtható fájlokat az adott virtuális gépen futtathatja.

Ha segítségre van szüksége azzal kapcsolatban, hogy mikor érdemes a Virtual Machinest választania tekintse meg az Azure App Service, a Cloud Services és a Virtual Machines összehasonlítását. A virtuális gépek beállításairól további információt az Azure-beli Windows rendszerű virtuális gépek méretei című témakörben talál. A Virtual Machines használata esetén elérhető operációs rendszerekkel és előre elkészített rendszerképekkel kapcsolatos további információért lásd az Azure Virtual Machines-piacteret.

Amennyiben a háttérfeladatot egy különálló virtuális gépen szeretné inicializálni, több lehetőség közül választhat:

  • A feladatot végrehajtathatja igény szerint közvetlenül az alkalmazásból egy kérés a feladat által elérhetővé tett végpontra küldésével. Ez a kérés átadja a feladat által igényelt adatokat is. A feladatot a végpont hívja meg.
  • Konfigurálhatja úgy a feladatot, hogy a választott operációs rendszerben elérhető feladatütemező vagy időzítő használatával ütemezetten fusson. Például a Windows rendszeren használhatja a Windows Feladatütemezőt a szkriptek és feladatok végrehajtatására. Vagy, ha a virtuális gépen telepítve van az SQL Server, használhatja az SQL Server Agentet a szkriptek és feladatok végrehajtására.
  • Az Azure Logic Apps használatával kezdeményezheti a feladatot úgy, hogy egy üzenetet ad hozzá a tevékenység által figyelt üzenetsorhoz, vagy egy kérést küld egy API-nak, amelyet a feladat elérhetővé tesz.

A háttérfeladatok inicializálásával kapcsolatban lásd az eseményindítókat ismertető fenti szakaszt.

Megfontolások

Amikor azt fontolgatja, hogy a háttérfeladatokat egy Azure-beli virtuális gépen helyezze-e üzembe, vegye figyelembe a következő szempontokat:

  • A háttérfeladatok egy külön Azure-beli virtuális gépen való futtatása rugalmasságot biztosít, és pontosan szabályozhatóvá teszi az inicializálást, a végrehajtást, az ütemezést és az erőforrás-kiosztást. Azonban ha kizárólag a háttérfeladatok futtatásához helyez üzembe egy külön virtuális gépet, az megnöveli a környezet futásidejű költségeit.
  • Az Azure Portal nem biztosít eszközöket a feladatok monitorozásához és a meghiúsult feladatok automatikus újraindításához – bár az Azure Resource Manager parancsmagjai lehetővé teszik a virtuális gép alapvető állapotának monitorozását és a virtuális gép kezelését. A számítási csomópontok folyamatainak és szálainak kezeléséhez azonban nem állnak rendelkezésre eszközök. Általában a virtuális gépek használata esetén további erőfeszítésekre van szükség egy olyan mechanizmus megvalósításához, amely rendszerállapot-adatokat gyűjt a feladatból és a virtuális gép operációs rendszeréről. Erre megfelelő megoldást nyújthat a System Center Azure-hoz készült felügyeleti csomagjának használata.
  • Érdemes fontolóra venni HTTP-végpontokon keresztül elérhetővé tett monitorozási mintavételezők létrehozását. Az ilyen mintavételezők kódja állapotellenőrzéseket hajthat végre, valamint működéssel kapcsolatos adatokat és statisztikákat gyűjthet – vagy összeállíthatja a hibainformációkat, és visszaküldheti egy felügyeleti alkalmazásnak. További információkért tekintse meg az állapotvégpont monitorozási mintáját.

További információkért lásd:

Azure Batch

Vegye figyelembe az Azure Batchet , 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 azokhoz, futtatja a feladatokat, és monitorozza az állapotot. A Batch a számítási feladat igényeinek megfelelően automatikusan felskálázhatja a virtuális gépeket. A Batch emellett a feladatütemezésről is gondoskodik. Az Azure Batch a linuxos és a windowsos virtuális gépek használatát egyaránt támogatja.

Megfontolások

A Batch nagyszerűen működik a belsőleg párhuzamos számítási feladatokkal. Végső soron kevesebb lépéssel hajthat végre párhuzamos számításokat, valamint futtathat Message Passing Interface- (MPI-) alkalmazásokat olyan párhuzamos feladatoknál, amelyeknél üzeneteket kell továbbítani a csomópontok között.

Az Azure Batch-feladatok csomópontok (virtuális gépek) készletein futnak. Az egyik megközelítésben a készletek csak szükség esetén vannak lefoglalva, majd a feladat befejezése után törlődnek. Ez maximális kihasználtságot biztosít, mivel a csomópontok nincsenek üresjáratban, azonban a feladatnak meg kell várnia a csomópontok lefoglalását. Alternatív megoldásként előre is létrehozhat egy készletet. Ez a megközelítés minimálisra csökkenti a feladatok indításához szükséges időt, azonban előfordulhat, hogy egyes csomópontok tétlenül várakoznak. További információért lásd a készletek és a számítási csomópontok élettartamát.

További információkért lásd:

Azure Kubernetes Service

Az Azure Kubernetes Service (AKS) kezeli a üzemeltetett Kubernetes-környezetet, ami megkönnyíti a tárolóalapú alkalmazások üzembe helyezését és kezelését.

A tárolók hasznosak lehetnek a háttérfeladatok futtatásához. Többek között a következő előnyöket kínálja:

  • A tárolók támogatják a nagy sűrűségű üzemeltetést. Az egyes háttérfeladatokat elkülönítheti külön tárolókba, és mindegyik virtuális gépre több tárolót is elhelyezhet.
  • A tárolóvezénylő kezeli a belső terheléselosztást, konfigurálja a belső hálózatot és egyéb konfigurációs feladatokat végez.
  • A tárolók szükség szerint indíthatók és állíthatók le.
  • Az Azure Container Registry használatával a tárolókat az Azure határain belül regisztrálhatja. Ez biztonsági, adatvédelmi és közelségi előnyökkel jár.

Megfontolások

  • A tárolóvezénylők kezelésének ismeretét igényli. A DevOps-csapat képességeitől függően ez problémát jelenthet vagy nem.

További információkért lásd:

Azure Container-alkalmazások

Az Azure Container Apps lehetővé teszi, hogy tárolók alapján kiszolgáló nélküli mikroszolgáltatásokat hozzon létre. A Container Apps megkülönböztető funkciói a következők:

  • Általános célú tárolók futtatására van optimalizálva, különösen a tárolókban üzembe helyezett számos mikroszolgáltatást felölelő alkalmazásokhoz.
  • A Kubernetes és az olyan nyílt forráskódú technológiák, mint a Dapr, a KEDA és a megbízott.
  • Támogatja a Kubernetes-stílusú alkalmazásokat és mikroszolgáltatásokat olyan funkciókkal, mint a szolgáltatásfelderítés és a forgalom felosztása.
  • Lehetővé teszi az eseményvezérelt alkalmazásarchitektúrákat úgy, hogy támogatja a forgalomon alapuló skálázást, és lekérte az eseményforrásokat, például az üzenetsorokat, beleértve a skálázást nullára.
  • A hosszú ideig futó folyamatok támogatása, és háttérfeladatok futtatására is képes.

Megfontolások

Az Azure Container Apps nem biztosít közvetlen hozzáférést a mögöttes Kubernetes API-khoz. Ha hozzáférésre van szüksége a Kubernetes API-khoz és a vezérlősíkhoz, az Azure Kubernetes Service-t kell használnia. Ha azonban Kubernetes-stílusú alkalmazásokat szeretne létrehozni, és nem igényel közvetlen hozzáférést az összes natív Kubernetes API-hoz és fürtkezeléshez, a Container Apps az ajánlott eljárásokon alapuló teljes körűen felügyelt felületet nyújt. Ezen okok miatt előfordulhat, hogy sok csapat szívesebben kezd tároló mikroszolgáltatások kiépítésébe az Azure Container Apps használatával.

További információkért lásd:

A rövid útmutatók segítségével megkezdheti az első tárolóalkalmazás elkészítését.

Particionálás

Ha úgy dönt, hogy háttérfeladatokat vesz fel egy meglévő számítási példányba, mérlegelnie kell, hogy ez hogyan befolyásolja a számítási példány minőségi attribútumait és magát a háttérfeladatot. Három tényező segít eldönteni, hogy érdemes-e a feladatokat a meglévő számítási példányokkal közösen elhelyezni, vagy inkább ki kell szervezni azokat külön számítási példányokba:

  • Rendelkezésre állás: A háttérfeladatok esetében nem feltétlenül szükséges ugyanolyan rendelkezésre állás, mint az alkalmazás egyéb részei, különösen a felhasználói felület és a felhasználói beavatkozás során közvetlenül érintett egyéb részek esetében. Mivel a műveletek várakoztathatók, a háttérfeladatok jobban elviselhetik a késéseket, a csatlakozási hibákból eredő újrapróbálkozásokat és a rendelkezésre állást befolyásoló egyéb tényezőket. Azonban elegendő kapacitással kell rendelkezni a kérések felgyülemlésének megakadályozásához, ami blokkolhatja az üzenetsorokat, és egészében érintheti az alkalmazás működését.

  • Méretezhetőség: A háttérfeladatok nagy valószínűséggel különböző méretezhetőségi követelményekkel rendelkeznek, mint a felhasználói felület és az alkalmazás interaktív részei. Előfordulhat, hogy a felhasználói felület skálázása szükséges lehet az igények csúcspontjának eléréséhez, míg a kiugró háttérfeladatokat kevesebb számítási példány is elvégezheti a kevésbé elfoglalt időszakokban.

  • Rugalmasság: A kizárólag háttérfeladatokat futtató számítási példányok meghibásodása nem feltétlenül vezet a teljes alkalmazás meghibásodásához, amennyiben ezeknek a feladatoknak a kérései várakoztathatók vagy elhalaszthatók, amíg a feladat újra elérhetővé nem válik. Ha a számítási példány és/vagy a feladatok egy megfelelő időintervallumon belül újraindíthatók, az alkalmazás felhasználóira ez nem lesz kihatással.

  • Biztonság: A háttérfeladatok valószínűleg különböző biztonsági követelményekkel vagy korlátozásokkal rendelkeznek, mint a felhasználói felület vagy az alkalmazás egyéb részei. Különálló számítási példány használata esetén eltérő biztonsági környezetet határozhat meg ezekhez a feladatokhoz. A Gatekeeper és a hasonló minták használatával a háttérbeli számítási példányokat a maximális biztonság és izoláció érdekében elkülönítheti a felhasználói felülettől.

  • Teljesítmény: A háttérfeladatok számítási példányainak típusát kiválaszthatja kifejezetten a feladatok teljesítménykövetelményeihez illeszkedően. Ez azt jelenti, hogy az olyan háttérfeladatokhoz, amelyek nem igényelnek a felhasználói felülethez hasonló feldolgozási kapacitást, egy kevésbé költséges számítási alternatíva is elégséges lehet, vagy épp ellenkezőleg, egy nagyobb példány lehet szükséges, ha további kapacitásokat és erőforrásokat igényelnek.

  • Kezelhetőség: A háttérfeladatok esetleg más fejlesztési és üzembehelyezési léptékkel rendelkeznek, mint a fő alkalmazáskód vagy a felhasználói felület. Ezeket külön számítási példányon beüzemelve egyszerűsíthető a frissítés és a verziókövetés.

  • Költségek: Ha a háttérfeladatokhoz külön számítási példányokat ad hozzá, azzal növekednek az üzemeltetési költségek. Alaposan gondolja át a további kapacitások és a további költségek közötti egyensúlyt.

További információkért tekintse meg a vezetőválasztási mintát és a versengő fogyasztók mintáját.

Ütközések

Ha valamely háttérfeladatnak több példánya létezik, lehetséges, hogy azok versenyezni fognak az erőforrások és szolgáltatások, például az adatbázisok és a tárolók eléréséréért. Az ilyen egyidejű elérés erőforrásversenyhez vezethet, ami pedig ütközéseket okozhat a szolgáltatások rendelkezésre állásában és a tárolóadatok integritásában. Az erőforrásversenyt pesszimista zárolási módszer alkalmazásával tudja feloldani. Ez megakadályozza, hogy a feladat versengő példányai egyidejűleg érhessék el a szolgáltatásokat, vagy károsíthassák az adatokat.

Az ütközések feloldásának egy másik módszere a háttérfeladatok egypéldányosként való definiálása, azaz hogy minden esetben csak egy példányban futtathatók. Azonban ez megszünteti a többpéldányos konfiguráció kínálta megbízhatósági és teljesítménybeli előnyöket. Ez különösen igaz, ha a felhasználói felület elegendő munkát képes biztosítani, így több háttérfeladatot is lefoglal.

Kritikus fontosságú, hogy gondoskodjon róla, hogy a háttérfeladat képes legyen automatikusan újraindulni, és rendelkezzen elegendő kapacitással az igénycsúcsok kielégítéséhez. Ezt úgy érheti el, ha elegendő erőforrással foglalja le a számítási példányokat, vagy ha kialakít egy olyan várakoztatási mechanizmust, amely képes a kéréseket az igény csökkenését követő későbbi végrehajtásra eltárolni, illetve ha ezt a két technikát együtt alkalmazza.

Koordináció

A háttérfeladatok összetettek lehetnek, és több különálló feladatot is igényelhetnek az eredmény létrehozásához vagy az összes követelmény teljesítéséhez. Ezekben a forgatókönyvekben gyakran szokás a feladatokat több kisebb diszkrét lépésre vagy több alfeladatra felosztani, amelyeket több fogyasztó hajthat végre. A többlépéses feladat-végrehajtás hatékonyabb és rugalmasabb tud lenni, mivel az egyes lépések több feladatban is újrafelhasználhatók. Emellett könnyen bővíthető, csökkenthető vagy módosítható a lépések sora.

Több feladat és lépés koordinálása kihívást jelenthet, létezik azonban három gyakori minta, amelyek segítségével könnyebben megvalósítható a megoldás:

  • A feladatok felbontása több újrafelhasználható lépésre. Az alkalmazásnak esetleg több, változó összetettségű feladatot kell végrehajtania a feldolgozandó adatokon. Egy egyszerű, de rugalmatlan megközelítés az ilyen alkalmazások megvalósításához, ha ezt a feldolgozást egy monolitikus modulként hajtatjuk végre. Ez a megközelítés azonban valószínűleg csökkenti a kód átdolgozásának, optimalizálásának vagy ismételt felhasználásának lehetőségét, amennyiben ugyanilyen feldolgozás máshol is szükséges lenne az alkalmazásban. További információ: Csövek és szűrők minta.

  • A feladatlépések végrehajtásának felügyelete. Egy alkalmazásnak esetleg több lépésből álló feladatokat kell végrehajtania (amelyek némelyike esetleg távoli szolgáltatásokat hív meg vagy távoli erőforrásokat ér el). Az egyes lépések egymástól függetlenek is lehetnek, de azokat a feladatot megvalósító alkalmazáslogika vezényli. További információ: Scheduler Agent Supervisor pattern.

  • A meghiúsult feladatlépések helyreállításának felügyelete. Az alkalmazásnak esetleg vissza kell vonnia egy sor – együtt végül egy konzisztens műveletet alkotó – lépésben végrehajtott munkát, ha egy vagy több lépés meghiúsul. További információkért lásd a kompenzáló tranzakció mintáját.

Rugalmassággal kapcsolatos szempontok

A háttérfeladatoknak rugalmasnak kell lenniük, hogy megbízható szolgáltatásokat tudjanak biztosítani az alkalmazásnak. A háttérfeladatok tervezése és kialakítása során vegye figyelembe a következő szempontokat:

  • A háttérfeladatoknak képesnek kell lenniük az újraindítások kecses kezelésére anélkül, hogy az adatok megsérülnek, vagy inkonzisztencia lépnek fel az alkalmazásban. A hosszan futó vagy többlépéses feladatok esetében érdemes lehet ellenőrzőpontokat alkalmazni, aminek során a feladatok állapotát menti egy állandó tárolóban vagy üzenetekként egy üzenetsorban, ha az a megfelelőbb. Például megőrizheti az állapotadatokat egy üzenetben az üzenetsorban, majd fokozatosan frissítheti ezt az állapotadatot a tevékenység előrehaladtával, így hiba esetén a feladatot a legutolsó sikeres ellenőrzőponttól kell csak végrehajtani, és nem a legelejétől. Azure Service Bus-üzenetsorok használata esetén üzenet-munkamenetek használatával ugyanezt a forgatókönyvet valósíthatja meg. A munkamenetek segítségével mentheti és visszaállíthatja az alkalmazás feldolgozási állapotát, a SetState és a GetState metódus alkalmazásával. 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.

  • Ha üzenetsorokat használ a háttérfeladatokkal folytatott kommunikációhoz, az üzenetsorok használhatók pufferként, amelyek tárolják a feladatoknak küldött kéréseket, amíg az alkalmazás a szokottnál magasabb terheléssel működik. Így a feladatok kevésbé forgalmas időszakokban utolérhetik a felhasználói felületet. Azt is jelenti, hogy az újraindítások nem fogják blokkolni a felhasználói felületet. További információkért tekintse meg a várólista-alapú terheléselosztási mintát. 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 feladatok előtt fussanak.

  • Az üzenetek vagy a folyamatüzenetek által inicializált háttérfeladatokat úgy kell kialakítani, hogy kezeljék az inkonzisztenciákat, például a soron kívül érkező üzeneteket, a sorozatosan hibát okozó üzeneteket (más néven ártalmas üzeneteket) és a többször kézbesített üzeneteket. A következőket ajánljuk figyelmébe:

    • A meghatározott sorrendben feldolgozandó üzenetek, például amelyek meglévő adatértékek alapján módosítják az adatokat (például egy érték hozzáadása egy meglévő értékhez) esetleg nem a küldés eredeti sorrendjében érkeznek meg. Vagy az is előfordulhat, hogy az egyes példányok különböző terhelése okán a háttérfeladat különböző példányai különböző sorrendben kezelik azokat. A meghatározott sorrendben feldolgozandó üzeneteknek ezért érdemes tartalmazniuk egy sorszámot, kulcsot vagy valamilyen egyéb jelölőt, amelynek segítségével a háttérfeladatok gondoskodhatnak róla, hogy a feldolgozás a megfelelő sorrendben történjen. Az Azure Service Bus használata esetén üzenet-munkamenetek használatával garantálhatja a megfelelő kézbesítési sorrendet. Általában azonban, ha ez lehetséges, hatékonyabb újratervezni a folyamatot úgy, hogy ne számítson az üzenetek sorrendje.

    • A háttérfeladatok általában betekintenek az üzenetekbe az üzenetsorban, ami ideiglenesen elrejti azokat a többi üzenetfogyasztó elől. Ezután a háttérfeladat törli az üzeneteket azok sikeres feldolgozását követően. Ha a háttérfeladat meghiúsul, miközben egy üzenetet dolgoz fel, az üzenet újból megjelenik az üzenetsorban a betekintés időtúllépésének lejártával. A feladat egy másik példánya fogja feldolgozni, vagy ugyanez a példány a következő feldolgozási ciklusban. Ha az üzenet következetesen hibát okoz a fogyasztóban, az blokkolja a feladatot, az üzenetsort és végül magát az alkalmazást is, amikor az üzenetsor megtelik. Ezért kritikus fontosságú az ártalmas üzenetek észlelése és eltávolítása az üzenetsorból. Az Azure Service Bus használata esetén a hibát okozó üzenetek automatikusan vagy manuálisan áthelyezhetők egy társított üzenetsorba.

    • Az üzenetsorok egy legalább egyszeri kézbesítési mechanizmust garantálnak, de akár többször is kézbesíthetik ugyanazt az üzenetet. Ezenkívül ha a háttérfeladat meghiúsul az üzenet feldolgozása után, de még mielőtt törölhetné azt az üzenetsorból, az üzenet ismét elérhető lesz feldolgozásra. A háttérfeladatoknak idempotensnek kell lenniük, ami azt jelenti, hogy ugyanazon üzenet többszöri feldolgozása nem okoz hibát vagy következetlenséget az alkalmazás adataiban. Egyes műveletek természetükből fakadóan idempotensek, például ilyen egy tárolt érték átállítása egy megadott új értékre. Más műveletek azonban inkonzisztenciát okozhatnak, például ha egy értéket adunk hozzá egy meglévő tárolt értékhez annak ellenőrzése nélkül, hogy az változott-e az üzenet eredeti küldésének időpontjához képest. Az Azure Service Bus-üzenetsorok konfigurálhatók úgy, hogy automatikusan eltávolítsák a duplikált üzeneteket. Az üzenetkézbesítéssel kapcsolatos kihívásokról további információt az idempotens üzenetfeldolgozással kapcsolatos útmutatóban talál.

    • Egyes üzenetkezelő rendszerek, például az Azure Queue Storage és az Azure Service Bus üzenetsorai támogatnak egy üzenetsor-törlési tulajdonságot, amely azt jelzi, hogy hányszor olvasták be az üzeneteket az üzenetsorból. Ez hasznos lehet az ismétlődő és ártalmas üzenetek kezeléséhez. További információért lásd az aszinkron üzenetkezelés ismertetését és az idempotens mintákat.

A méretezéssel és a teljesítménnyel kapcsolatos szempontok

A háttérfeladatoknak elegendő teljesítményt kell biztosítania, hogy ne blokkolhassák az alkalmazást vagy okozhassanak inkonzisztenciát, ha a rendszer terhelése miatt késéssel működnek. Általában a teljesítmény a háttérfeladatot futtató számítási példányok skálázásával javítható. A háttérfeladatok tervezése és kialakítása során vegye figyelembe a következő szempontokat a skálázás és a teljesítmény kapcsán:

  • Azure-támogatás automatikus skálázást (horizontális felskálázást és horizontális felskálázást is) az aktuális igény és terhelés alapján, vagy előre meghatározott ütemezés szerint a webalkalmazások és a virtuális gépek üzemeltetett üzemelő példányai esetében. Ennek a szolgáltatásnak a használatával biztosítható, hogy az alkalmazás egésze elegendő teljesítménybeli kapacitással rendelkezzen, ugyanakkor a futtatási költségek minimalizálhatók legyenek.

  • Ha a háttérfeladatok eltérő teljesítménnyel rendelkeznek az alkalmazás többi részétől (például a felhasználói felülettől vagy az összetevőktől, például az adatelérési rétegtől), a háttérfeladatok külön számítási szolgáltatásban való együttes üzemeltetése lehetővé teszi, hogy a felhasználói felület és a háttérfeladatok egymástól függetlenül méretezhessék a terhelést. Ha több háttérfeladat jelentősen eltérő teljesítménnyel rendelkezik egymástól, érdemes lehet egymástól függetlenül elosztani és skálázni az egyes típusokat. Vegye figyelembe azonban, hogy ez növelheti a futásidejű költségeket.

  • Előfordulhat, hogy a számítási erőforrások egyszerűen skálázása nem elegendő a terhelés alatti teljesítményvesztés megelőzéséhez. Emellett a tároló-üzenetsorokat és egyéb erőforrásokat is méretezni kellhet, hogy a teljes feldolgozási lánc egyetlen pontja se válhasson szűk keresztmetszetté. Vegye figyelembe továbbá az egyéb korlátokat is, például a tároló, valamint az alkalmazás és a háttérfeladatok által használt egyéb szolgáltatások maximális teljesítményét is.

  • A háttérfeladatokat méretezhetően kell kialakítani. Például képesnek kell lenniük dinamikusan észlelni a használatban lévő üzenetsorok számát, hogy a megfelelő üzenetsort figyelhessék, és maguk is a megfelelő üzenetsorba küldjék az üzeneteket.

  • Alapértelmezés szerint a WebJobs-feladatok együtt méreteződnek a társított Azure Web Apps-példánnyal. Azonban ha azt szeretné, hogy a WebJobs-feladat csak egy példányban fusson, létrehozhat egy Settings.job fájlt, amely tartalmazza az {"is_singleton": true} JSON-adatot. Ez kényszeríti az Azure-t, hogy a WebJobs-feladatot csak egy példányban futtassa, még ha a kapcsolódó webalkalmazásnak több példánya van is. Ez hasznos módszer lehet az olyan ütemezett feladatokhoz, amelyeket csak egy példányban lehet futtatni.

Következő lépések