Web-Queue-Worker architektúra stílus

Az architektúra alapvető összetevői az ügyfélkéréseket kezelő webes kezelőfelületek , valamint egy erőforrás-igényes feladatokat, hosszan futó munkafolyamatokat vagy kötegelt feladatokat végző feldolgozó . A webes felület üzenetsor segítségével kommunikál a munkavégzővel.

A következő összetevőket gyakran beépítik ebbe az architektúrába:

• Egy vagy több adatbázis

• Gyorsítótár az adatbázisból származó értékek gyors olvasásához való tárolásához

• Tartalomkézbesítési hálózat statikus tartalom kiszolgálására

• Olyan távoli szolgáltatások, mint az e-mail vagy a rövid üzenetszolgáltatás (SMS), amelyeket általában nem Microsoft-szolgáltatók biztosítanak.

• Identitásszolgáltató hitelesítéshez

A web és a feldolgozó állapot nélküli, a munkamenet állapota pedig elosztott gyorsítótárban tárolható. A munkavállaló aszinkron módon kezeli a hosszan futó feladatot. A sorban álló üzenetek elindíthatják a munkafolyamatot, vagy egy ütemezés futtathatja azt kötegelt feldolgozás céljából. A feldolgozó nem kötelező, ha az alkalmazás nem rendelkezik hosszú ideig futó műveletekkel.

Az előtér tartalmazhat egy webes API-t. Egy egyoldalas alkalmazás AJAX-hívásokkal használhatja a webes API-t, vagy egy natív ügyfélalkalmazás közvetlenül használhatja azt.

Mikor érdemes használni ezt az architektúrát?

A webesQueue-Worker architektúrát általában felügyelt számítási szolgáltatások, például az Azure App Service vagy az Azure Kubernetes Service használatával implementálják.

Vegye figyelembe ezt az architektúrát a következő használati esetekben:

• Viszonylag egyszerű tartománnyal rendelkező alkalmazások

• Hosszú ideig futó munkafolyamatokkal vagy kötegműveletekkel rendelkező alkalmazások

• Olyan forgatókönyvek, ahol a felügyelt szolgáltatásokat részesíti előnyben az infrastruktúra szolgáltatásként (IaaS) szemben

Előnyök

• Egyszerű és könnyen követhető architektúra

• Üzembe helyezés és felügyelet minimális erőfeszítéssel

• A felelősségek egyértelmű elkülönítése

• A front end és a munkafolyamat leválasztása aszinkron üzenetküldés révén

• A frontend és a worker független skálázása

Kihívások

• Gondos tervezés nélkül az előtér és a feldolgozó nagy monolitikus összetevőkké válhat, amelyeket nehéz karbantartani és frissíteni.

• Ha az előtér és a feldolgozó adatsémákat vagy kódmodulokat oszt meg, rejtett függőségek lehetnek.

• A webes front-end akkor hibásodhat meg, amikor már megtörtént az adatok adatbázisba mentése, de még mielőtt üzeneteket küldene a sorba, ami konzisztenciaproblémákat okoz, mert a munkavégző nem hajtja végre a logika ráeső részét. A probléma enyhítéséhez használhat olyan technikákat, mint a tranzakciós kimenő mintázat, amely megköveteli, hogy a kimenő üzeneteket először egy különálló üzenetsorba irányítsák vissza. Az NServiceBus tranzakciós munkamenet könyvtára támogatja ezt a technikát.

Ajánlott eljárások

• Egy jól megtervezett API-t tehet elérhetővé az ügyfél számára. További információkért tekintse meg az API tervezési ajánlott eljárásait.

• Automatikus méretezés a terhelés változásainak kezeléséhez. További információkért tekintse meg az automatikus skálázás ajánlott eljárásait.

• Gyorsítótárazás félsztatikus adatokra. További információért lásd: Gyorsítótárazási ajánlott eljárások.

• Statikus tartalmak üzemeltetéséhez használjon tartalomkézbesítési hálózatot. További információ: Tartalomkézbesítési hálózat – ajánlott eljárások.

• Szükség esetén használjon többplatformos adatmegőrzést. További információ: Adatmodellek ismertetése.

• Particionálási adatok a méretezhetőség javítása, a versengés csökkentése és a teljesítmény optimalizálása érdekében. További információkért tekintse meg az adatparticionálás ajánlott eljárásait.

Web-Queue-Worker az App Service-ben

Ez a szakasz az App Service-t használó ajánlott Web-Queue-Worker architektúrát ismerteti.

Architektúradiagram, amely a webalkalmazásokat az Azure CDN-en keresztül statikus tartalomkézbesítéshez hozzáférő felhasználókat mutatja be. A felhasználói kéréseket kezelő és üzeneteket az Azure Service Busba vagy az Azure Storage-üzenetsorokba küldő App Service-webalkalmazásokba irányuló forgalom. Az Azure Functions-feldolgozók az üzenetsorokból érkező üzeneteket dolgozzák fel az erőforrás-igényes feladatok kezeléséhez. A rendszer tartalmazza az Azure Managed Redist a munkamenet-állapothoz és az alacsony késésű adathozzáféréshez, az Azure Blob Storage-t a fájl- és dokumentumtároláshoz, valamint az Azure SQL Database-hez és az Azure Cosmos DB-hez készült többplatformos adattárolást. A webalkalmazások és a Függvények is App Service-csomagokon futnak a számítási infrastruktúrához.

Töltse le az architektúra Visio-fájlját.

Workflow

• Az előoldal App Service webalkalmazásként van megvalósítva, a feldolgozó pedig Azure Functions alkalmazásként van megvalósítva. A webalkalmazás és a Functions alkalmazás is egy App Service-csomaghoz van társítva, amely a virtuálisgép-példányokat biztosítja.

• Az üzenetsorhoz használhat azure Service Bus - vagy Azure Storage-üzenetsorokat . Az előző diagram egy Storage-üzenetsort használ.

• Az Azure Managed Redis tárolja a munkamenet állapotát és más, alacsony késésű hozzáférést igénylő adatokat.

• Az Azure Content Delivery Network statikus tartalmak, például képek, CSS vagy HTML gyorsítótárazására szolgál.

• A tároláshoz válassza ki az alkalmazás igényeinek leginkább megfelelő technológiákat. Ez a többértelmű adatmegőrzésnek nevezett megközelítés több tárolási technológiát használ ugyanabban a rendszerben a különböző követelmények teljesítéséhez. Az ötlet szemléltetéséhez a diagram az Azure SQL Database-t és az Azure Cosmos DB-t is megjeleníti.

További információ: Alapkonfiguráció– magas rendelkezésre állású zónaredundáns webalkalmazás és üzenetvezérelt üzleti alkalmazások létrehozása az NServiceBus és a Service Bus használatával.

Egyéb szempontok

• Nem minden tranzakciónak kell az üzenetsoron és a feldolgozó egységen keresztül átmennie a tárolóhoz. A webes előtér közvetlenül képes egyszerű olvasási és írási műveletek elvégzésére. A munkavállalók erőforrás-igényes feladatokhoz vagy hosszan futó munkafolyamatokhoz vannak kialakítva. Bizonyos esetekben előfordulhat, hogy egyáltalán nincs szüksége munkavállalóra.

• A számítási platform beépített automatikus méretezési funkciójával skálázhatja a példányok számát. Ha az alkalmazás terhelése kiszámítható mintákat követ, használjon ütemezésalapú automatikus skálázást. Ha a terhelés kiszámíthatatlan, használjon metrikákon alapuló automatikus skálázást.

• Fontolja meg, hogy a webalkalmazást és a Functions-alkalmazást különálló App Service-csomagokba helyezi, hogy egymástól függetlenül skálázhatók legyenek.

• Használjon külön App Service-csomagokat produkciós és tesztelési célokra.

• Üzembehelyezési pontok használata az üzemelő példányok kezeléséhez. Ezzel a módszerrel üzembe helyezhet egy frissített verziót egy átmeneti ponton, majd lecserélheti az új verzióra. Azt is lehetővé teszi, hogy visszacserélje az előző verzióra, ha probléma merül fel a frissítés során.

Kapcsolódó erőforrás

• Queue-Based Terheléskiegyenlítő minta