Tento článek popisuje, jak nasadit klíčové webové aplikace pomocí služby Aplikace Azure Service. Architektura používá jako výchozí bod spolehlivý vzor webové aplikace. Tuto architekturu použijte, pokud máte starší úlohu a chcete přijmout služby paaS (platforma jako služba).
Spolehlivý vzor webové aplikace pro .NET poskytuje pokyny k aktualizaci nebo opětovnému vytvoření webových aplikací, které přesunete do cloudu, minimalizaci požadovaných změn kódu a cílení na cíl na úrovni služby (SLO) 99,9 %. Klíčové úlohy mají vysoké požadavky na spolehlivost a dostupnost. Pokud chcete dosáhnout cíle SLO 99,95 %, 99,99 % nebo vyšší, musíte použít doplňkové klíčové vzory návrhu a provozní rigorii. Tento článek popisuje klíčové technické oblasti a způsob implementace a zavedení klíčových postupů návrhu.
Poznámka:
Pokyny v tomto článku vycházejí z metodologie návrhu a osvědčených postupů v sérii klíčových úloh dobře navržená architektura.
Následující části popisují, jak:
- Projděte si stávající úlohu, abyste porozuměli svým komponentám, tokům uživatelů a systémů a požadavkům na dostupnost a škálovatelnost.
- Vyvíjejte a implementujte architekturu jednotek škálování, která optimalizuje komplexní škálovatelnost prostřednictvím oddělení a standardizuje proces přidávání a odebírání kapacity.
- Implementujte bezstavové, dočasné jednotky škálování nebo razítka nasazení, abyste umožnili nasazení škálovatelnosti a nulového výpadku.
- Určete, jestli můžete úlohu rozdělit na komponenty, abyste se připravili na škálovatelnost. Jednotlivé komponenty jsou vyžadovány pro škálovatelnost a oddělení toků.
- Připravte se na globální distribuci nasazením úlohy ve více než jedné oblasti Azure, abyste zlepšili blízkost zákazníka a připravili se na potenciální regionální výpadky.
- Oddělte komponenty a implementujte architekturu řízenou událostmi.
Architektura
Následující diagram používá předchozí aspekty spolehlivého vzoru webové aplikace.
Stáhněte si soubor aplikace Visio s touto architekturou.
Červené pole představuje jednotku škálování se službami, které se škáluje společně. Pokud je chcete efektivně škálovat společně, optimalizujte velikost, skladovou položku a dostupné IP adresy jednotlivých služeb. Například maximální počet požadavků, které Aplikace Azure Konfigurace obsluhuje, odpovídá počtu požadavků za sekundu, které poskytuje jednotka škálování. Když v oblasti přidáte další kapacitu, musíte také přidat další jednotlivé jednotky škálování.
Tyto jednotlivé jednotky škálování nemají žádné vzájemné závislosti a komunikují pouze se sdílenými službami mimo jednotlivé jednotky škálování. Nezávislé jednotky škálování můžete testovat předem. Aby nedošlo k ovlivnění jiných oblastí nasazení, zaveďte nezávislé jednotky škálování a zaveďte možnost nahradit služby v nové verzi.
Pro klíčové úlohy jsou nezávislé jednotky škálování dočasné, což optimalizuje procesy zavádění a poskytuje škálovatelnost v rámci oblastí a napříč oblastmi. Vyhněte se ukládání stavu v nezávislých jednotkách škálování. Zvažte použití azure Cache for Redis pro úložiště v jednotce škálování a uložte pouze kritický stav nebo data uložená v databázi. Pokud dojde k výpadku jednotky škálování nebo se přepnete na jinou jednotku škálování, může se zpomalit nebo vyžadovat nové přihlášení, ale Azure Cache for Redis stále běží.
Aplikační Přehledy je vyloučena z jednotky škálování. Vylučte služby, které ukládají nebo monitorují data. Rozdělte je do vlastní skupiny prostředků s vlastním životním cyklem.
Když nahradíte jednotku škálování nebo nasadíte novou, uchovávejte historická data a používejte jednu instanci pro každou oblast.
Další informace najdete v tématu Návrh aplikací důležitých úloh v Azure.
Komponenty
Tato architektura používá následující komponenty.
- App Service je platforma pro hostování aplikací.
- Požadavky azure Cache for Redis Caches.
- App Configuration ukládá nastavení konfigurace.
- Azure SQL je back-endová databáze.
- Aplikační Přehledy získává telemetrii z aplikace.
Alternativy
V modelu spolehlivé webové aplikace můžete:
- Místo služby App Service používejte Službu Azure Kubernetes Service (AKS). Tato možnost funguje dobře u složitých úloh, které mají velký počet mikroslužeb. AKS poskytuje větší kontrolu nad základní infrastrukturou a umožňuje složitá vícevrstvé nastavení.
- Kontejnerizujte úlohu. App Service podporuje kontejnerizaci, ale v tomto příkladu není úloha kontejnerizovaná. Využijte kontejnery ke zvýšení spolehlivosti a přenositelnosti.
Další informace najdete v tématu Aspekty aplikační platformy pro klíčové úlohy v Azure.
Volba aplikační platformy
Úroveň dostupnosti závisí na vaší volbě a konfiguraci aplikační platformy. Zvažte následující klíčové pokyny:
- Pokud je to možné, používejte zóny dostupnosti.
- Vyberte správnou službu platformy pro vaši úlohu.
- Kontejnerizujte úlohu.
Skupiny dostupnosti rozprostírají nasazení napříč několika doménami selhání a aktualizačními doménami v rámci datacentra. Zóny dostupnosti šíří nasazení mezi jednotlivá datová centra v rámci oblasti Azure. Zóny dostupnosti jsou často upřednostňovány, ale strategie, kterou používáte, závisí na vaší úloze. Například úlohy citlivé na latenci nebo chatování můžou těžit z určení priority skupin dostupnosti. Pokud úlohu rozložíte mezi zóny dostupnosti, může zvýšit latenci a náklady na provoz napříč zónami. Pokud používáte zóny dostupnosti, ujistěte se, že je podporují všechny služby v jednotce škálování. Všechny služby v modelu spolehlivé webové aplikace podporují zóny dostupnosti.
Volba datové platformy
Zvolená databázová platforma ovlivňuje celkovou architekturu úloh, zejména podporu konfigurace aktivní-aktivní nebo aktivní-pasivní. Model spolehlivé webové aplikace používá Azure SQL, který nativně nepodporuje nasazení aktivní-aktivní s operacemi zápisu ve více než jedné instanci. Úroveň databáze je tedy omezena na strategii aktivní-pasivní. Strategie aktivní-aktivní na úrovni aplikace je možná, pokud existují repliky jen pro čtení a zapisujete pouze do jedné oblasti.
Stáhněte si soubor aplikace Visio s touto architekturou.
V komplexních architekturách, jako jsou architektury mikroslužeb, které mají databázi pro každou službu, je běžné více databází. Několik databází umožňuje přijetí více primární databáze pro zápis, jako je Azure Cosmos DB, což zlepšuje vysokou dostupnost a nízkou latenci. Latence mezi oblastmi může způsobit omezení. Je důležité zvážit nefunkční požadavky a faktory, jako je konzistence, funkčnost, náklady a složitost. Povolte jednotlivým službám používat samostatná úložiště dat a specializované datové technologie, aby splňovaly jejich jedinečné požadavky. Další informace najdete v tématu Důležité informace o datových platformách pro důležité úlohy v Azure.
Definování modelu stavu
Ve složitých vícevrstvějších úlohách, které se šíří napříč několika datovými centry a geografickými oblastmi, je nutné definovat model stavu. Definujte toky uživatelů a systémů, určete a porozumíte závislostem mezi službami, seznamte se s tím, jaký vliv mohou mít výpadky nebo snížení výkonu u jedné ze služeb, a monitorujte a vizualizovat prostředí zákazníka, abyste umožnili správné monitorování a zlepšili ruční a automatizované akce.
Předchozí diagram znázorňuje, jak může výpadek nebo snížení výkonu jedné komponenty, například Konfigurace aplikace, způsobit potenciální snížení výkonu pro zákazníka.
Když rozdělíte komponenty do jednotek škálování, můžete zastavit odesílání provozu do ovlivněné části aplikace, jako je ovlivněná jednotka škálování nebo úplná oblast.
Další informace najdete v tématu Modelování stavu a pozorovatelnost důležitých úloh v Azure.
Zabezpečení a sítě
Pro úlohy, které migrují z místního podnikového nasazení, existují přísné požadavky na síť a zabezpečení. Ne všechny zavedené místní procesy se převedou do cloudového prostředí. Tyto požadavky vyhodnoťte, pokud jsou použitelné v cloudových prostředích.
Identita je často primární hraniční hranici zabezpečení pro vzory nativní pro cloud. Podnikoví zákazníci můžou potřebovat podstatně větší bezpečnostní opatření. K řešení požadavků na zabezpečení sítě může většina služeb Azure PaaS použít Azure Private Link k implementaci sítě jako hraniční sítě. Private Link může zajistit, aby služby byly přístupné jenom z virtuální sítě. Všechny služby jsou přístupné jenom prostřednictvím privátních koncových bodů. Následující diagram ukazuje, jak jediným veřejným internetovým koncovým bodem je Azure Front Door.
Stáhněte si soubor aplikace Visio s touto architekturou.
Aby spolehlivý model webové aplikace nastavil síť jako hraniční síť, musí používat:
- Private Link pro všechny služby, které ho podporují.
- Azure Front Door Premium jako jediný veřejný koncový bod směřující k internetu
- Jumpboxes pro přístup ke službám přes Azure Bastion.
- Agenti sestavení v místním prostředí, kteří mají přístup ke službám.
Dalším běžným požadavkem sítě pro klíčové aplikace je omezení odchozího provozu, aby se zabránilo exfiltraci dat. Omezení odchozího provozu směrováním brány Azure Firewall přes správné zařízení brány firewall a jeho filtrováním pomocí zařízení. Základní architektura Azure pro klíčové základní hodnoty s ovládacími prvky sítě používá bránu firewall a službu Private Link.
Nasazení a testování
Výpadek způsobený chybnými verzemi nebo lidskou chybou může být problém pro úlohu, která musí být vždy dostupná. Tady je několik klíčových oblastí, které je potřeba vzít v úvahu:
- Nasazení s nulovými výpadky
- Dočasné modré/zelené nasazení
- Analýza životního cyklu jednotlivých komponent a jejich seskupení
- Průběžné ověřování
Nasazení s nulovými výpadky jsou klíčem pro klíčové úlohy. Úloha, která musí být vždy spuštěná, nemůže mít časové období údržby pro zavedení novějších verzí. Pro řešení tohoto omezení se kritická architektura Azure řídí modelem nasazení s nulovými výpadky. Změny se zahrnou jako nové jednotky škálování nebo razítka, které se testují až do konce, než se do nich postupně směruje provoz. Po směrování veškerého provozu na nové razítko se staré razítko zakáže a odebere.
Další informace najdete v tématu Nasazení a testování důležitých úloh v Azure.
Další kroky
- Učení cesta: Sestavování důležitých úloh v Azure
- Projekt výzvy: Návrh klíčové webové aplikace
- Modul Learn: Návrh modelu stavu pro klíčové úlohy