Az ilyen architektúrák alapelemei: egy webes előtér, amely kiszolgálja az ügyfélkérelmeket, és egy feldolgozó, amely erőforrás-igényes munkákat, hosszan futó munkafolyamatokat vagy kötegelt feladatokat hajt végre. A webes előtér egy üzenetsor segítségével kommunikál a feldolgozóval.
Az ebbe az architektúrába gyakran beillesztett más összetevők:
- Egy vagy több adatbázis.
- Egy gyorsítótár az adatbázis adatainak tárolására a gyors olvasás érdekében.
- CDN a statikus tartalom kiszolgálásához
- Távoli szolgáltatások, például e-mail- vagy SMS-szolgáltatás. Ezeket a funkciókat gyakran harmadik felek biztosítják.
- Identitásszolgáltató a hitelesítéshez.
A web és a feldolgozó is állapot nélküli. A munkamenet-állapot tárolható egy megosztott gyorsítótárban. A hosszan futó munkákat a feldolgozó aszinkron módon végzi el. A feldolgozó aktiválható üzenetekkel az üzenetsoron, vagy futhat egy ütemezésben a kötegelt feldolgozáshoz. A feldolgozó egy választható összetevő. Ha nincs hosszan futó művelet, a feldolgozó elhagyható.
Az előtér állhat egy webes API-ból. Ügyféloldalon a webes API-t használhatja egy AJAX-hívásokat indító egyoldalas alkalmazás vagy egy natív ügyfélalkalmazás.
Mikor érdemes ezt az architektúrát használni?
A webüzenetsor-feldolgozó architektúra implementálása általában felügyelt számítási szolgáltatások használatával történik, vagy az Azure App Service vagy az Azure Cloud Services segítségével.
Fontolja meg ennek az architektúrastílusnak a használatát a következőkhöz:
- Alkalmazások viszonylag egyszerű tartománnyal.
- Alkalmazások néhány hosszan futó munkafolyamattal vagy kötegelt műveletekkel.
- Ha felügyelt szolgáltatásokat szeretne használni szolgáltatott infrastruktúra (IaaS) helyett.
Előnyök
- Viszonylag egyszerű és könnyen érthető architektúra.
- Könnyen telepíthető és felügyelhető.
- A kockázatok egyértelmű elkülönítése.
- Az előteret a rendszer aszinkron üzenetküldés segítségével választja le a feldolgozóról.
- Az előtér és a feldolgozó egymástól függetlenül skálázható.
Problémák
- Gondos tervezés nélkül az előtér és a feldolgozó hatalmas, monolitikus, végül nehezen karbantartható és frissíthető összetevővé válhat.
- Lehetnek rejtett függőségek, ha az előtér és a feldolgozó közös sémákat vagy kódmodulokat használ.
- A webes előtér meghibásodhat, miután sikeresen megőrizte az adatbázist, de mielőtt az üzeneteket kibocsátja az üzenetsorba. Ez konzisztenciával kapcsolatos problémákat okozhat, mivel a feldolgozó nem fogja végrehajtani a logika részét. Az olyan technikák, mint a tranzakciós kimenő levelek mintája , segíthetnek a probléma megoldásában, de a kimenő üzenetek útválasztását egy külön üzenetsoron keresztül kell "visszacsatolásra" módosítani. Az egyik olyan kódtár, amely támogatja ezt a technikát, az NServiceBus tranzakciós munkamenet.
Best practices
- Jól megtervezett API közzététele az ügyfelek számára. Tekintse meg az API-tervezés – Ajánlott eljárások szakaszt.
- Automatikus skálázás a terhelés változásának kezelésére. Lásd az automatikus skálázással kapcsolatos ajánlott eljárásokat.
- Gyorsítótárazza a félig statikus adatokat. Lásd a gyorsítótárazás ajánlott eljárásait.
- CDN használata a statikus tartalom üzemeltetéséhez. Tekintse meg az Ajánlott tanácsok az Azure CDN-nel kapcsolatban szakaszt.
- Többnyelvű adatmegőrzés használata, ha szükséges. Lásd: [A feladat legjobb adattárának használata][polyglot].
- Adatok particionálása a méretezhetőség növeléséhez, a versengés kiküszöböléséhez és a teljesítmény optimalizálásához. Tekintse meg az Ajánlott adatparticionálási eljárások szakaszt.
A webüzenetsor-feldolgozó az Azure App Service-en
Ez a szakasz ismertet egy ajánlott, az Azure App Service-t használó webüzenetsor-feldolgozót.
Töltse le az architektúra Visio-fájlját.
Munkafolyamat
Az előtér egy Azure-alkalmazás Service-webalkalmazásként van implementálva, a feldolgozó pedig Azure Functions-alkalmazásként van implementálva. A webalkalmazás és a függvényalkalmazás is a virtuálisgép-példányokat biztosító App Service-csomaghoz van társítva.
Az üzenetsorhoz használhat azure Service Bus - vagy Azure Storage-üzenetsorokat . (Az ábrán egy Azure Storage-üzenetsor látható.)
Az Azure Cache for Redis tárolja a munkamenet állapotát és más, alacsony késésű hozzáférést igénylő adatokat.
Az Azure CDN 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 legmegfelelőbb tárolási technológiákat. Használhat több tárolási technológiát (többnyelvű adatmegőrzés). Az ötlet szemléltetéséhez a diagram az Azure SQL Database-t és az Azure Cosmos DB-t mutatja be.
További információ: App Service webalkalmazás-referenciaarchitektúra , valamint üzenetvezérelt üzleti alkalmazások létrehozása az NServiceBus és az Azure Service Bus használatával.
Other considerations
Nem minden tranzakciónak kell áthaladnia az üzenetsoron és a feldolgozón a tároló felé. A webes előtér közvetlenül hajthat végre egyszerű olvasási/írási műveleteket. A feldolgozók erőforrás-igényes feladatokhoz vagy hosszan futó munkafolyamatokhoz lettek kialakítva. Bizonyos esetekben előfordulhat, hogy nincs is szükség feldolgozóra.
Az App Service beépített automatikus skálázási szolgáltatásával horizontálisan felskálázhatja a virtuálisgép-példányok számát. Ha az alkalmazás terhelése előre megjósolható mintákat követ, használjon ütemezésalapú automatikus skálázást. Ha a terhelés nem jósolható meg előre, használjon mérőszám-alapú automatikus méretezési szabályokat.
Érdemes lehet a webalkalmazást és a függvényalkalmazást külön App Service-csomagokba helyezni. Így egymástól függetlenül skálázhatók.
Az éles üzemhez és a teszteléshez használjon külön App Service-csomagot. Ha ugyanis ugyanazt a csomagot használja az éles üzemhez és a teszteléshez, akkor a tesztek élesben működő virtuális gépeken futnak.
Az üzembe helyezések kezeléséhez használjon üzembehelyezési pontokat. Ezzel a módszerrel üzembe helyezhet egy frissített verziót egy átmeneti ponton, majd lecserélheti az új verzióra. Így arra is lehetősége van, hogy visszaváltson a korábbi verzióra, ha probléma adódna a frissítéssel.