Styl architektury webovéhoQueue-Worker
Základní komponenty této architektury jsou webový front-end , který obsluhuje požadavky klientů, a pracovní proces , který provádí úlohy náročné na prostředky, dlouhotrvající pracovní postupy nebo dávkové úlohy. Webový front-end komunikuje s pracovním procesem prostřednictvím fronty zpráv.
Mezi další komponenty, které jsou běžně začleněny do této architektury, patří:
- Jedna nebo více databází.
- Mezipaměť pro ukládání hodnot z databáze pro rychlé čtení.
- CDN pro obsluhu statického obsahu
- Vzdálené služby, jako je e-mail nebo služba SMS. Tyto funkce často poskytují třetí strany.
- Zprostředkovatel identity pro ověřování.
Web i pracovní proces jsou bezstavové. Stav relace lze uložit do distribuované mezipaměti. Jakákoli dlouhotrvající práce se provádí asynchronně pracovním procesem. Pracovní proces může být aktivován zprávami ve frontě nebo spuštěním podle plánu dávkového zpracování. Pracovní proces je volitelná komponenta. Pokud neexistují žádné dlouhotrvající operace, můžete pracovní proces vynechat.
Front-end se může skládat z webového rozhraní API. Na straně klienta může webové rozhraní API využívat jednostráková aplikace, která provádí volání AJAX nebo nativní klientskou aplikací.
Kdy použít tuto architekturu
Architektura webovéhoQueue-Worker se obvykle implementuje pomocí spravovaných výpočetních služeb, a to buď Azure App Service, nebo Azure Cloud Services.
Zvažte tento styl architektury pro:
- Aplikace s relativně jednoduchou doménou.
- Aplikace s některými dlouhotrvajícími pracovními postupy nebo dávkovými operacemi
- Pokud chcete používat spravované služby místo infrastruktury jako služby (IaaS).
Výhody
- Relativně jednoduchá architektura, která je snadno pochopitelná.
- Snadné nasazení a správa
- Jasné oddělení obav.
- Front-end je oddělený od pracovního procesu pomocí asynchronního zasílání zpráv.
- Front-end a pracovní proces je možné škálovat nezávisle na sobě.
Výzvy
- Bez pečlivého návrhu se front-end a pracovní proces mohou stát velkými monolitických komponent, které jsou obtížné udržovat a aktualizovat.
- Pokud front-end a pracovní proces sdílejí schémata dat nebo moduly kódu, můžou existovat skryté závislosti.
- Webový front-end může po úspěšném zachování databáze fungovat, ale před odesláním zpráv do fronty. To může vést k možným problémům s konzistencí, protože pracovní proces nebude provádět svou část logiky. Techniky, jako je model transakční doručené pošty , se dají použít ke zmírnění tohoto problému, ale vyžadují změnu směrování odchozích zpráv na první smyčku zpět prostřednictvím samostatné fronty. Jednou z knihoven, která poskytuje podporu této techniky, je transakční relace NServiceBus.
Osvědčené postupy
- Zveřejnění dobře navrženého rozhraní API pro klienta Podívejte se na osvědčené postupy návrhu rozhraní API.
- Automatické škálování pro zpracování změn v zatížení Pro osvědčené postupy automatického škálování.
- Ukládání částečně statických dat do mezipaměti Přečtěte si osvědčené postupy
ukládání do mezipaměti. - K hostování statického obsahu použijte CDN. Podívejte se na osvědčené postupy CDN.
- V případě potřeby používejte polyglotní trvalost. Viz [Použití nejlepšího úložiště dat pro úlohu][polyglot].
- Rozdělte data tak, aby se zlepšila škálovatelnost, snížila kolize a optimalizovala výkon. Podívejte se na osvědčené postupy dělení dat.
Web –Queue-Worker ve službě Azure App Service
Tato část popisuje doporučenou architekturu webovýchQueue-Worker, která používá Službu Azure App Service.
Stáhněte si soubor aplikace Visio s touto architekturou.
Pracovní postup
Front-end se implementuje jako webová aplikace Azure App Service a pracovní proces se implementuje jako aplikace Azure Functions . Webová aplikace i aplikace funkcí jsou přidružené k plánu služby App Service, který poskytuje instance virtuálních počítačů.
Pro frontu zpráv můžete použít fronty Azure Service Bus nebo Azure Storage . (Diagram znázorňuje frontu Azure Storage.)
Azure Cache for Redis ukládá stav relace a další data, která potřebují přístup s nízkou latencí.
Azure CDN slouží k ukládání statického obsahu do mezipaměti, jako jsou obrázky, šablony stylů CSS nebo HTML.
Pro úložiště zvolte technologie úložiště, které nejlépe vyhovují potřebám aplikace. Můžete použít více technologií úložiště (polyglotní trvalost). Pro ilustraci této myšlenky diagram znázorňuje Azure SQL Database a Azure Cosmos DB.
Další informace najdete v referenční architektuře webové aplikace služby App Service a o tom, jak vytvářet obchodní aplikace řízené zprávami pomocí NServiceBus a Služby Azure Service Bus.
Ostatní úvahy
Ne každá transakce musí projít frontou a pracovním procesem do úložiště. Webový front-end může provádět jednoduché operace čtení a zápisu přímo. Pracovní procesy jsou navržené pro úlohy náročné na zdroje nebo dlouhotrvající pracovní postupy. V některých případech nemusíte vůbec potřebovat pracovníka.
Pomocí integrované funkce automatického škálování služby App Service horizontálně navyšte kapacitu počtu instancí virtuálních počítačů. Pokud se zatížení aplikace řídí předvídatelnými vzory, použijte automatické škálování na základě plánu. Pokud je zatížení nepředvídatelné, použijte pravidla automatického škálování založená na metrikách.
Zvažte vložení webové aplikace a aplikace funkcí do samostatných plánů služby App Service. Tímto způsobem se dají škálovat nezávisle.
Pro produkční a testování používejte samostatné plány služby App Service. Pokud použijete stejný plán pro produkční a testovací prostředí, znamená to, že vaše testy běží na produkčních virtuálních počítačích.
Ke správě nasazení použijte sloty nasazení. Tato metoda umožňuje nasadit aktualizovanou verzi do přípravného slotu a pak přepnout na novou verzi. Umožňuje také prohodit zpět předchozí verzi, pokud došlo k potížím s aktualizací.