Metodologie návrhu pro klíčové úlohy v Azure

Vytvoření klíčové aplikace na jakékoli cloudové platformě vyžaduje významné technické znalosti a technické investice, zejména proto, že je zde značná složitost spojená s:

• Principy cloudové platformy
• Volba správných služeb a složení,
• Použití správné konfigurace služby
• Zprovoznění využívaných služeb a
• Neustálé sladění s nejnovějšími osvědčenými postupy a plány služeb

Tato metodologie návrhu se snaží poskytnout snadnou cestu návrhu, která vám pomůže zorientovat se v této složitosti a získat informace o rozhodnutích při návrhu potřebných k vytvoření optimální cílové architektury.

1. Návrh pro obchodní požadavky

Ne všechny důležité úlohy mají stejné požadavky. Očekávejte, že aspekty kontroly a doporučení k návrhu, které tato metodologie návrhu poskytuje, přinesou různá rozhodnutí o návrhu a kompromisy pro různé scénáře aplikací.

Vyberte úroveň spolehlivosti.

Spolehlivost je relativní koncept, a aby každá úloha byla náležitě spolehlivá, měla by odrážet obchodní požadavky, které s ní souvisí. Například kritická úloha s cílem úrovně služby (SLO) s 99,999% dostupností vyžaduje mnohem vyšší úroveň spolehlivosti než jiná méně důležitá úloha s cílem úrovně služeb 99,9 %.

Tato metodologie návrhu používá koncept úrovní spolehlivosti vyjádřených jako SLO dostupnosti, aby informovala o požadovaných charakteristikách spolehlivosti. Následující tabulka obsahuje povolené rozpočty chyb spojené s běžnými úrovněmi spolehlivosti.

Úroveň spolehlivosti (SLO dostupnosti)	Povolený výpadek (týden)	Povolený výpadek (měsíc)	Povolený výpadek (rok)
99,9 %	10 minut, 4 sekundy	43 minut, 49 sekund	8 hodin, 45 minut, 56 sekund
99,95 %	5 minut, 2 sekundy	21 minut, 54 sekund	4 hodiny, 22 minut, 58 sekund
99,99 %	1 minuta	4 minuty 22 sekund	52 minut, 35 sekund
99,999 %	6 sekund	26 sekund	5 minut, 15 sekund
99.9999%	<1 sekunda	2 sekundy	31 sekund

Důležité

Cíl úrovně dostupnosti se v této metodologii návrhu považuje za více než jednoduchou dobu provozu, ale za konzistentní úroveň aplikační služby vzhledem ke známému stavu aplikace, který je v pořádku.

V počátečním cvičení doporučujeme čtenářům vybrat cílovou úroveň spolehlivosti a určit, jak velký výpadek je přijatelný? Úsilí o konkrétní úroveň spolehlivosti bude mít v konečném důsledku významný vliv na cestu návrhu a zahrnuje rozhodnutí o návrhu, což bude mít za následek jinou cílovou architekturu.

Tento obrázek ukazuje, jak různé úrovně spolehlivosti a základní obchodní požadavky ovlivňují cílovou architekturu pro koncepční referenční implementaci, zejména pokud jde o počet regionálních nasazení a využitých globálních technologií.

Dalšími důležitými aspekty při určování požadované spolehlivosti jsou plánovaná doba obnovení (RTO) a cíl bodu obnovení (RPO). Pokud se například snažíte dosáhnout doby obnovení aplikace kratší než minutu, pak strategie obnovení založené na zálohování nebo strategie aktivního-pasivního nasazení pravděpodobně nebudou stačit.

2 – Vyhodnocení oblastí návrhu pomocí principů návrhu

Jádrem této metodologie je kritická cesta návrhu, která se skládá z následujících částí:

• Základní principy návrhu
• Základní oblast návrhu s výrazně provázanými a závislými rozhodnutími o návrhu

Dopad rozhodnutí učiněných v každé oblasti návrhu se projeví v ostatních oblastech návrhu a rozhodnutích o návrhu. Projděte si uvedené aspekty a doporučení, abyste lépe porozuměli důsledkům souvisejících rozhodnutí, která mohou vést k kompromisům v souvisejících oblastech návrhu.

Pokud například chcete definovat cílovou architekturu, je důležité určit, jak nejlépe monitorovat stav aplikace napříč klíčovými komponentami. Důrazně doporučujeme, abyste si prostudovali oblast návrhu modelování stavu s využitím nastíněných doporučení, která vám pomůžou při rozhodování.

3. Nasazení první důležité aplikace

Projděte si tyto referenční architektury, které popisují rozhodnutí o návrhu na základě této metodologie.

• Základní architektura internetové aplikace

• Základní architektura internetové aplikace s ovládacími prvky sítě

Tip

Architektura je ověřená kritickou online implementací, která ilustruje doporučení návrhu.

Artefakty produkční úrovně Každý technický artefakt je připravený k použití v produkčních prostředích se všemi komplexními provozními aspekty.

Kořeny v reálných zkušenostech Všechna technická rozhodnutí se řídí zkušenostmi zákazníků Azure a poznatky z nasazení těchto řešení.

Sladění plánů plánu Azure Klíčové referenční architektury mají vlastní plán, který je v souladu s plány produktů Azure.

4. Integrace úloh v cílových zónách Azure

Předplatná cílové zóny Azure poskytují sdílenou infrastrukturu pro podniková nasazení, která vyžadují centralizované zásady správného řízení.

Je důležité vyhodnotit, který případ použití připojení vyžaduje vaše kritická aplikace. Cílové zóny Azure podporují dva hlavní archetypy oddělené do různých oborů skupin pro správu: Online nebo Corp. jak je znázorněno na tomto obrázku.

Online předplatné

Klíčové úlohy fungují jako nezávislé řešení bez přímého připojení k podnikové síti ke zbytku architektury cílové zóny Azure. Aplikace bude dále chráněna prostřednictvím zásad správného řízení řízeného zásadami a automaticky se integruje s centralizovaným protokolováním platformy prostřednictvím zásad.

Základní architektura a kritická online implementace jsou v souladu s přístupem online.

Předplatné společnosti

Při nasazení v předplatném společnosti Corp. je klíčová úloha závislá na cílové zóně Azure, která poskytuje prostředky připojení. Tento přístup umožňuje integraci s dalšími aplikacemi a sdílenými službami. Budete muset navrhnout některé základní prostředky, které budou existovat předem jako součást platformy sdílených služeb. Například razítko regionálního nasazení by už nemělo zahrnovat dočasný Virtual Network nebo Azure Privátní DNS Zone, protože budou existovat v předplatném Corp. .

Pokud chcete začít s tímto případem použití, doporučujeme základní architekturu v referenční architektuře cílové zóny Azure .

Tip

Předchozí architektura je ověřená implementací kritického připojení .

5. Nasazení aplikačního prostředí sandboxu

Souběžně s aktivitami návrhu se důrazně doporučuje vytvořit prostředí aplikace sandboxu pomocí Mission-Critical referenčních implementací.

To poskytuje praktické příležitosti k ověření rozhodnutí o návrhu replikací cílové architektury, což umožňuje rychle vyhodnotit nejistotu návrhu. Při správném použití se reprezentativním pokrytím požadavků je možné odhalit a následně vyřešit většinu problematických problémů, které by mohly bránit pokroku.

6. Průběžný vývoj s využitím plánů Azure

Architektury aplikací vytvořené pomocí této metodologie návrhu se musí i nadále vyvíjet v souladu s plány platformy Azure, aby podporovaly optimalizovanou udržitelnost.

Další krok

Projděte si principy návrhu pro klíčové scénáře aplikací.

Principy návrhu