Základními součástmi 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ý front-end komunikuje s pracovním procesem prostřednictvím fronty zpráv.
Mezi ostatní komponenty, které jsou běžně součástí této architektury, patří:
- Jedna nebo více databází
- Mezipaměť pro ukládání hodnot z databáze pro jejich rychlé načítání
- Síť 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 může být ukládán v distribuované mezipaměti. Veškeré dlouhotrvající pracovní postupy provádí asynchronně pracovní proces. Pracovní proces může být aktivován zprávou ve frontě, nebo může být spouštěn podle plánu pro dávkové zpracování. Pracovní proces je volitelná součást. Pokud nemáte žádné dlouhotrvající operace, můžete pracovní proces vynechat.
Front-end může obsahovat webové rozhraní API. Na straně klienta může webové rozhraní API využívat jednostránková aplikace, která bude provádět volání jazyka AJAX, nebo nativní klientská aplikace.
Kdy použít tuto architekturu
Architektura web-fronta-pracovní proces se obvykle implementuje pomocí spravované výpočetní služby – Azure App Service, nebo Azure Cloud Services.
Zvažte použití tohoto stylu architektury v následujících situacích:
- Aplikace s poměrně jednoduchou doménou.
- Aplikace s dlouhotrvajícími pracovními postupy nebo dávkovými operacemi.
- Když chcete dát přednost spravovaným službám před infrastrukturou jako službou (IaaS).
Zaměstnanecké výhody
- Relativně jednoduchá architektura, snadná na pochopení
- Snadné nasazení a správa
- Jasně oddělené oblasti zájmu
- Front-end oddělený od pracovního procesu pomocí asynchronního zasílání zpráv
- Možnost nezávislého škálování front-endu a pracovního procesu
Problémy
- Bez uvážlivého přístupu k návrhu se z front-endu a pracovního procesu můžou stát velké, monolitické komponenty, které se obtížně spravují a aktualizují.
- Pokud front-end a pracovní proces sdílejí schémata dat nebo moduly kódu, může takový návrh obsahovat 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
- Vytvořte pro klienta přehledné rozhraní API. Viz Osvědčené postupy pro navrhování rozhraní API.
- Zaveďte automatické škálování pro případ změn v zatížení. Přečtěte si osvědčené postupy automatického škálování.
- Semistatická data ukládejte do mezipaměti. Přečtěte si osvědčené postupy pro ukládání do mezipaměti.
- K hostování statického obsahu používejte síť CDN. Viz Doporučené postupy pro CDN.
- Kdykoli je to vhodné, použijte přístup známý jako polyglot persistence, který kombinuje výhody různých databází. Viz [Použití nejlepšího úložiště dat pro úlohu][polyglot].
- Rozdělte data s cílem vylepšit škálovatelnost, omezit kolize a optimalizovat výkon. Viz Osvědčené postupy pro dělení dat.
Architektura web-fronta-pracovní proces ve službě Azure App Service
Tato část obsahuje doporučení pro architekturu web-fronta-pracovní proces, která používá službu Azure App Service.
Stáhněte si soubor aplikace Visio s touto architekturou.
Workflow
Front-end se implementuje jako webová aplikace služby Aplikace Azure 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 ukládání zvolte takovou technologii úložiště, která nejlépe vyhovuje potřebám vaší aplikace. Můžete používat i více technologií úložišť (polyglot persistence). 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 k uložení musí projít přes frontu a pracovní proces. Webový front-end může jednoduché operace čtení a zápisu provádět přímo. Pracovní procesy jsou navržené pro úlohy náročné na prostředky nebo dlouhotrvající pracovní postupy. V některých případech nemusíte pracovní proces vůbec potřebovat.
Pomocí integrované funkce automatického škálování služby App Service můžete škálovat na více instancí virtuálních počítačů. Pokud lze zatížení aplikace předvídat, použijte automatické škálování na základě plánu. Pokud předvídat nelze, použijte pro automatické škálování pravidla založená na metrice.
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 produkci a testování používejte odlišné plány služby App Service. Pokud pro ně budete používat stejný plán, poběží testy na produkčních virtuálních počítačích.
Používejte nasazovací sloty pro správu nasazení. Tato metoda umožňuje nasadit aktualizovanou verzi do přípravného slotu a pak přepnout na novou verzi. Navíc pokud nastanou potíže s aktualizací, můžete přejít zpět na předchozí verzi.