Styl architektury Web-Queue-Worker

Základní komponenty této architektury jsou webový front-end , který zpracovává 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é rozhraní komunikuje s pracovníkem prostřednictvím fronty zpráv.

Do této architektury se běžně začleňují následující komponenty:

• Jedna nebo více databází

• Mezipaměť pro ukládání hodnot z databáze pro rychlé čtení

• Síť pro doručování obsahu pro obsluhu statického obsahu

• Vzdálené služby, jako je e-mail nebo Služba krátkých zpráv (SMS), které obvykle poskytují poskytovatelé služeb jiných společností než Microsoft

• Zprostředkovatel identity pro ověřování

Web i pracovní proces jsou bezstavové a stav relace lze uložit do distribuované mezipaměti. Pracovník zpracovává dlouhotrvající práci asynchronně. Zprávy ve frontě mohou spustit pracovní proces nebo ho může spustit plán pro dávkové zpracování. Pracovník je volitelný, pokud aplikace nemá žádné dlouhotrvající operace.

Front-end může obsahovat webové rozhraní API. Jednostránková aplikace může webové rozhraní API využívat prostřednictvím AJAX volání, nebo ji může přímo využívat nativní aplikace klienta.

Kdy použít tuto architekturu

Architektura Web-Queue-Worker se obvykle implementuje pomocí spravovaných výpočetních služeb, jako je Azure App Service nebo Azure Kubernetes Service.

Zvažte tuto architekturu pro následující případy použití:

• Aplikace, které mají relativně jednoduchou doménu

• Aplikace, které mají dlouhotrvající pracovní postupy nebo dávkové operace

• Scénáře, kdy dáváte přednost spravovaným službám před infrastrukturou jako službou (IaaS)

Výhody

• Architektura, která je jednoduchá a snadno použitelná

• Nasazení a správa s minimálním úsilím

• Jasné oddělení odpovědností

• Oddělení front-endu a pracovního procesu prostřednictvím asynchronního zasílání zpráv

• Nezávislé škálování front-endu a pracovníka

Výzvy

• Bez pečlivého návrhu se front-end a pracovní proces mohou stát velkými monolitickými komponentami, které se obtížně udržují a aktualizují.

• 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 selhat po uložení do databáze, ale před odesláním zpráv do fronty. To způsobuje problémy s konzistencí, protože pracovník nesplní svoji úlohu v logice. Pokud chcete tento problém zmírnit, můžete použít techniky, jako je vzorec pro transakční odchozí poštu, který vyžaduje směrování odchozích zpráv, aby se nejprve vrátily smyčkou přes samostatnou frontu. Tuto techniku podporuje knihovna transakčních relací NServiceBus .

Osvědčené postupy

• Zveřejnění dobře navrženého rozhraní API pro klienta Další informace najdete v tématu Osvědčené postupy návrhu rozhraní API.

• Automaticky škálujte pro zvládání změn v zatížení. Další informace najdete v tématu Osvědčené postupy automatického škálování.

• Ukládání polostatických dat do mezipaměti Další informace najdete v tématu Osvědčené postupy ukládání do mezipaměti.

• K hostování statického obsahu použijte síť pro doručování obsahu. Další informace najdete v tématu Osvědčené postupy sítě pro doručování obsahu.

• V případě potřeby používejte polyglotní trvalost. Další informace najdete v tématu Vysvětlení datových modelů.

• Rozdělte data tak, aby se zlepšila škálovatelnost, snížila kolize a optimalizovala výkon. Další informace najdete v tématu Osvědčené postupy dělení dat.

Web-Queue-Worker ve službě App Service

Tato část popisuje doporučenou architekturu webového Queue-Workeru, která používá službu App Service.

Diagram architektury znázorňující uživatele, kteří přistupují k webovým aplikacím prostřednictvím Azure CDN pro doručování statického obsahu Toky provozu směřují do webových aplikací App Service, které zpracovávají uživatelské požadavky a odesílají zprávy do front Azure Service Bus nebo Azure Storage. Pracovní procesy Azure Functions zpracovávají zprávy z front za účelem zpracování úloh náročných na prostředky. Systém zahrnuje Azure Managed Redis pro přístup k datům o stavu relace a nízkou latenci, Azure Blob Storage pro ukládání souborů a dokumentů a polyglotní úložiště dat se službou Azure SQL Database a Azure Cosmos DB. Webové aplikace i funkce běží v plánech služby App Service pro výpočetní infrastrukturu.

Stáhněte si soubor aplikace Visio s touto architekturou.

Workflow

• Front end je implementován jako webová aplikace App Service a worker je implementován jako aplikace Azure Functions. Webová aplikace i aplikace Functions 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 . Předchozí diagram používá frontu úložiště.

• Azure Managed Redis ukládá stav relace a další data, která vyžadují přístup s nízkou latencí.

• Azure Content Delivery Network 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, které nejlépe vyhovují potřebám vaší aplikace. Tento přístup, označovaný jako polyglotní trvalost, používá více technologií úložiště ve stejném systému ke splnění různých požadavků. Pro ilustraci této myšlenky diagram ukazuje Azure SQL Database i Azure Cosmos DB.

Další informace najdete v tématu Standardní vysoce dostupná zónově redundantní webová aplikace a vytváření podnikových aplikací řízených zprávami pomocí NServiceBus a 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íci jsou navrženi 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í výpočetní platformy horizontálně navyšte kapacitu počtu instancí. Pokud zatížení aplikace dodržuje předvídatelné vzory, použijte automatické škálování založené na plánu. Pokud je zatížení nepředvídatelné, použijte automatické škálování založené na metrikách.

• Zvažte umístění webové aplikace a aplikace Functions do samostatných plánů služby App Service, aby se mohly škálovat nezávisle.

• Pro produkční a testování používejte samostatné plány služby App Service.

• 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. Pokud během aktualizace dojde k potížím, můžete se také vrátit k předchozí verzi.

Související prostředek

• model vyrovnávání zatíženíQueue-Based