Tento prohlížeč se už nepodporuje.
Upgradujte na Microsoft Edge, abyste mohli využívat nejnovější funkce, aktualizace zabezpečení a technickou podporu.
Tento článek představuje klíčový vzor pro klíčové architektury v Azure. Tento vzor použijte při zahájení procesu návrhu a pak vyberte komponenty, které jsou nejvhodnější pro vaše obchodní požadavky. Tento článek doporučuje přístup k návrhu severní hvězdy a obsahuje další příklady s běžnými technologickými komponentami.
Doporučujeme vyhodnotit klíčových oblastí návrhu, definovat kritické toky uživatelů a systémů, které používají základní komponenty, a vyvinout matici prostředků Azure a jejich konfiguraci a přitom mít na paměti následující charakteristiky.
| Charakteristický | Úvahy |
|---|---|
| Životnost | Jaká je očekávaná životnost prostředku vzhledem k jiným prostředkům v řešení? Měl by prostředek přežívat nebo sdílet životnost s celým systémem nebo oblastí, nebo by měl být dočasný? |
| Stát | Jaký dopad bude mít trvalý stav v této vrstvě na spolehlivost nebo možnosti správy? |
| Dosáhnout | Je nutné, aby byl prostředek globálně distribuován? Může prostředek komunikovat s jinými prostředky, které se nacházejí globálně nebo v této oblasti? |
| Závislosti | Jaké jsou závislosti na jiných prostředcích? |
| Omezení škálování | Jaká je očekávaná propustnost pro tento prostředek? Jaký rozsah je poskytnut zdrojem, aby vyhověl této poptávce? |
| Dostupnost / zotavení po havárii | Jaký je dopad na dostupnost z havárie v této vrstvě? Způsobila by systémový výpadek nebo pouze problém s lokalizovanou kapacitou nebo dostupností? |
Důležitý
Tento článek je součástí řady Well-Architected důležitých úloh Azure. Pokud tuto řadu neznáte, doporučujeme začít s co je kritická úloha?
Některé prostředky jsou globálně sdíleny prostředky nasazenými v rámci každé oblasti. Mezi běžné příklady patří prostředky, které se používají k distribuci provozu napříč několika oblastmi, uložení trvalého stavu pro celou aplikaci a monitorování prostředků.
| Charakteristický | Úvahy |
|---|---|
| Životnost | U těchto prostředků se očekává, že budou dlouhodobé (trvalé). Jejich životnost se rovná životnosti systému nebo je delší. Prostředky se často spravují pomocí aktualizací dat na místě a řídicí roviny za předpokladu, že podporují operace aktualizace bez výpadku. |
| Stát | Vzhledem k tomu, že tyto prostředky existují alespoň po celou dobu životnosti systému, je tato vrstva často zodpovědná za ukládání globálního geograficky replikovaného stavu. |
| Dosažení | Prostředky by se měly globálně distribuovat a replikovat do oblastí, které tyto prostředky hostují. Doporučuje se, aby tyto zdroje komunikovaly s oblastmi nebo jinými zdroji s nízkou latencí a požadovanou konzistencí. |
| Závislosti | Prostředky by se měly vyhnout závislostem na regionálních prostředcích, protože jejich nedostupnost může být příčinou globálního selhání. Certifikáty nebo tajné kódy uložené v jednom trezoru můžou mít například globální dopad, pokud dojde k selhání oblasti, ve které se trezor nachází. |
| Omezení škálování | Tyto prostředky jsou často jediné instance v systému a měly by být schopny škálovat tak, aby zvládly propustnost systému jako celek. |
| Dostupnost / zotavení po havárii | Regionální a razítkové prostředky můžou používat globální prostředky. Je zásadní, aby globální prostředky byly nakonfigurovány s vysokou dostupností a obnovou po havárii pro zachování zdraví celého systému. |
Razítko obsahuje aplikaci a prostředky, které se podílejí na dokončení obchodních transakcí. Razítko obvykle odpovídá nasazení do oblasti Azure. I když oblast může mít více než jedno razítko.
| Charakteristický | Úvahy |
|---|---|
| Životnost | Očekává se, že prostředky budou mít krátkou životnost (efemérní) se záměrem, že se mohou přidávat a odebírat dynamicky, zatímco regionální prostředky mimo danou zónu zůstanou zachovány. Dočasný charakter je potřeba k zajištění větší odolnosti, škálování a blízkosti uživatelů. |
| Stát | Vzhledem k tomu, že známky jsou dočasné a budou zničeny s každým nasazením, známka by měla být co nejvíce bezstavová. |
| Dosáhnout | Může komunikovat s regionálními a globálními prostředky. Je však třeba se vyhnout komunikaci s jinými oblastmi nebo jinými razítky. |
| Závislosti | Prostředky razítka musí být nezávislé. Očekává se, že budou mít regionální a globální závislosti, ale neměly by se spoléhat na komponenty v jiných razítkech ve stejných nebo jiných oblastech. |
| Omezení škálování | Propustnost se určuje testováním. Propustnost celkového razítka je omezená na nejméně výkonný prostředek. Propustnost razítka musí odhadnout vysokou úroveň poptávky způsobenou převedením na jinou instanci kvůli selhání. |
| Dostupnost / zotavení po havárii | Vzhledem k dočasné povaze razítek se obnova po havárii provádí znovu nasazením razítka. Pokud jsou prostředky ve špatném stavu, lze razítko jako celek zničit a znovu nasadit. |
Systém může mít prostředky nasazené v oblasti, které ale přetrvají i po tom, co už prostředky pracovního prostoru končí. Například pozorovatelné prostředky, které monitorují prostředky na regionální úrovni, včetně razítek.
| Charakteristický | Úvaha |
|---|---|
| Životnost | Prostředky mají stejnou dobu životnosti jako oblast a přežijí prostředky razítek. |
| Stát | Stav uložený v oblasti nemůže existovat déle, než je období životnosti oblasti. Pokud je potřeba sdílet stav napříč oblastmi, zvažte použití globálního úložiště dat. |
| Dosáhnout | Prostředky nemusí být globálně distribuované. Přímé komunikaci s jinými oblastmi by se mělo vyhnout za každou cenu. |
| Závislosti | Prostředky můžou mít závislosti na globálních prostředcích, ale ne na prostředcích typu "stamp", protože tyto mají být krátkodobé. |
| Omezení škálování | Určete limit škálování regionálních prostředků kombinací všech razítek v rámci oblasti. |
Tyto základní příklady slouží jako doporučená architektura severní hvězdy pro klíčové aplikace. Směrný plán důrazně doporučuje kontejnerizaci a použití orchestrátoru kontejnerů pro aplikační platformu. Výchozí bod používá službu Azure Kubernetes Service (AKS).
Projděte si Well-Architected klíčové úlohy: Kontejnerizace.
Pokud právě začínáte na kritické cestě, použijte tuto architekturu jako referenci. Úloha se přistupuje přes veřejný koncový bod a nevyžaduje připojení privátní sítě k jiným prostředkům společnosti.
Tato architektura vychází ze základní architektury. Návrh je rozšířen tak, aby poskytoval přísné řízení sítě, aby se zabránilo neoprávněnému veřejnému přístupu z internetu k prostředkům úloh.
Tato architektura je vhodná, pokud nasazujete úlohu v podnikovém nastavení, kde se vyžaduje integrace v rámci širší organizace. Tato úloha využívá centralizované sdílené služby, potřebuje místní připojení a integruje se s dalšími úlohami v rámci podniku. Je nasazena v předplatném přistávací zóny Azure, které dědí ze skupiny Corp pro správu.
Tato architektura rozšiřuje základní odkaz tím, že zvažuje služby App Services jako primární technologii hostování aplikací, což poskytuje snadno použitelné prostředí pro nasazení kontejnerů.
Doporučujeme použít poskytnuté pokyny k návrhu k navigaci v klíčových rozhodnutích o návrhu, abyste dosáhli optimálního řešení. Informace najdete v tématu Co jsou klíčové oblasti návrhu?
Projděte si osvědčené postupy pro navrhování klíčových scénářů aplikací.