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 na sever star a obsahuje další příklady běžných technologických komponent.
Doporučujeme vyhodnotit klíčové oblasti návrhu, definovat kritické uživatelské a systémové toky, které používají základní komponenty, a vyvinout matici prostředků Azure a jejich konfigurace, přičemž mějte na paměti následující charakteristiky.
| Charakteristika | Požadavky |
|---|---|
| Doba platnosti | 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ý? |
| Stav | Jaký vliv bude mít trvalý stav v této vrstvě na spolehlivost nebo možnosti správy? |
| Reach | Vyžaduje se globální distribuce prostředku? Může prostředek komunikovat s jinými prostředky umístěnými 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 velké škálování poskytuje prostředek, aby vyhovoval této poptávce? |
| Dostupnost nebo zotavení po havárii | Jaký má havárie v této vrstvě dopad na dostupnost? Způsobilo by to systémový výpadek, nebo pouze problém s lokalizovanou kapacitou nebo dostupností? |
Důležité
Tento článek je součástí řady klíčových úloh Azure Well-Architected . Pokud tuto řadu neznáte, doporučujeme začít s tím, co je kritická úloha?
Některé prostředky jsou globálně sdíleny prostředky nasazenými v jednotlivých oblastech. Mezi běžné příklady patří prostředky, které se používají k distribuci provozu do několika oblastí, k ukládání trvalého stavu celé aplikace a k monitorování prostředků.
| Charakteristika | Požadavky |
|---|---|
| Doba platnosti | Očekává se, že tyto prostředky budou mít dlouhou životnost (ne efemerní). Jejich životnost je delší než životnost systému. Prostředky se často spravují pomocí místních aktualizací dat a řídicí roviny za předpokladu, že podporují operace aktualizace s nulovými výpadky. |
| Stav | 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. |
| Reach | Prostředky by se měly globálně distribuovat a replikovat do oblastí, které tyto prostředky hostují. Doporučuje se, aby tyto prostředky komunikují s regionálními nebo jinými prostředky s nízkou latencí a požadovanou konzistencí. |
| Závislosti | Prostředky by se měly vyhnout závislostem na místních prostředcích, protože jejich nedostupnost může být příčinou globálního selhání. Například certifikáty nebo tajné kódy uložené v jednom trezoru můžou mít globální dopad, pokud dojde k selhání oblasti, ve které se trezor nachází. |
| Omezení škálování | Tyto prostředky jsou často singleton instance v systému a měly by být schopné škálovat tak, aby zvládly propustnost systému jako celku. |
| Dostupnost nebo zotavení po havárii | Místní prostředky a prostředky razítek můžou používat globální prostředky. Je důležité, aby globální prostředky byly nakonfigurované s vysokou dostupností a zotavením po havárii pro stav 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.
| Charakteristika | Požadavky |
|---|---|
| Doba platnosti | Očekává se, že prostředky budou mít krátkou životnost (dočasný) se záměrem, že se můžou přidávat a odebírat dynamicky, zatímco místní prostředky mimo razítko budou dál zachované. Dočasný charakter je potřebný k zajištění větší odolnosti, škálování a blízkosti uživatelů. |
| Stav | Vzhledem k tomu, že kolky jsou dočasné a při každém nasazení budou zničeny, razítko by mělo být co nejvíce bezstavové. |
| Reach | Může komunikovat s regionálními a globálními prostředky. Měli byste se ale vyhnout komunikaci s jinými oblastmi nebo jinými kolky. |
| 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 spoléhat na komponenty v jiných razítek ve stejné nebo jiné oblasti. |
| Omezení škálování | Propustnost se vytváří testováním. Propustnost celkového razítka je omezená na nejméně výkonný prostředek. Propustnost kolku musí odhadnout vysokou úroveň poptávky způsobené převzetím služeb při selhání na jiné razítko. |
| Dostupnost nebo zotavení po havárii | Kvůli dočasné povaze razítek se zotavení po havárii provádí opětovným nasazením razítka. Pokud jsou prostředky ve špatném stavu, je možné razítko jako celek zničit a znovu nasadit. |
Systém může mít prostředky, které jsou nasazené v oblasti, ale přežívají prostředky razítka. Například pozorovatelné prostředky, které monitorují prostředky na regionální úrovni, včetně razítek.
| Charakteristika | Aspekty |
|---|---|
| Doba platnosti | Prostředky se dělí o životnost oblasti a zaživa vysílají prostředky razítka. |
| Stav | Stav uložený v oblasti nemůže být po dobu životnosti dané oblasti. Pokud je potřeba stav sdílet napříč oblastmi, zvažte použití globálního úložiště dat. |
| Reach | Prostředky nemusí být globálně distribuované. Za každou cenu byste se měli vyhnout přímé komunikaci s jinými oblastmi. |
| Závislosti | Prostředky můžou mít závislosti na globálních prostředcích, ale ne na prostředcích s razítkem, protože razítka mají být krátkodobá. |
| Omezení škálování | Zkombinováním všech razítek v rámci oblasti určete limit škálování místních prostředků. |
Tyto základní příklady slouží jako doporučená architektura severní star pro klíčové aplikace. Směrný plán důrazně doporučuje kontejnerizaci a použití orchestrátoru kontejnerů pro aplikační platformu. Směrný plán používá Azure Kubernetes Service (AKS).
Projděte si téma Dobře navržená kritická úloha: Kontejnerizace.
Pokud právě začínáte svou kritickou cestu, použijte tuto architekturu jako referenci. K úloze 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 je založená na základní architektuře. Návrh je rozšířený tak, aby poskytoval přísné síťové kontroly, které brání neoprávněnému veřejnému přístupu z internetu k prostředkům úloh.
Tato architektura je vhodná, pokud úlohu nasazujete v podnikovém prostředí, kde se vyžaduje integrace v rámci širší organizace. Úloha používá centralizované sdílené služby, potřebuje připojení k místnímu prostředí a integruje se s dalšími úlohami v rámci podniku. Je nasazený v předplatném cílové zóny Azure, které dědí ze skupiny pro správu corp.
Tato architektura rozšiřuje základní odkazy tím, že jako primární technologii hostování aplikací zvažuje App Services a poskytuje snadno použitelné prostředí pro kontejnerová nasazení.
K procházení klíčových rozhodnutí o návrhu a dosažení optimálního řešení doporučujeme použít poskytnuté pokyny k návrhu. Informace najdete v tématu Jaké jsou klíčové oblasti návrhu?
Projděte si osvědčené postupy pro navrhování důležitých scénářů aplikací.
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro