Tato architektura poskytuje pokyny k návrhu klíčové úlohy v Azure. Využívá funkce nativní pro cloud k maximalizaci spolehlivosti a provozní efektivity. Používá metodologii návrhu pro dobře navržená klíčové úlohy na internetovou aplikaci, ke které 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.
Důležité
Pokyny jsou podporovány ukázkovou implementací na produkční úrovni, která představuje důležitý vývoj aplikací v Azure. Tuto implementaci můžete použít jako základ pro další vývoj řešení v prvním kroku k produkčnímu prostředí.
Úroveň spolehlivosti
Spolehlivost je relativní koncept a aby úloha byla přiměřeně spolehlivá, měla by odrážet obchodní požadavky, které ji obklopují, včetně cílů úrovně služeb (SLO) a smluv o úrovni služeb (SLA), aby bylo možné zaznamenat procento času, po který by měla být aplikace k dispozici.
Tato architektura cílí na SLO 99,99 %, což odpovídá povolenému ročnímu výpadku 52 minut a 35 sekund. Všechna rozhodnutí o návrhu jsou proto určena k dosažení tohoto cíle cíle cíle.
Tip
Pokud chcete definovat realistickou SLO, je důležité pochopit smlouvu SLA všech komponent Azure v rámci architektury. Tato jednotlivá čísla by se měla agregovat, aby se určila kombinovaná smlouva SLA , která by měla odpovídat cílům úloh.
Projděte si klíčové úlohy s dobře navrženou architekturou: Návrh pro obchodní požadavky.
Klíčové strategie návrhu
Mnoho faktorů může ovlivnit spolehlivost aplikace, například schopnost zotavit se z selhání, regionální dostupnosti, účinnosti nasazení a zabezpečení. Tato architektura používá sadu nadlimitních strategií návrhu určených k řešení těchto faktorů a zajištění dosažení cílové úrovně spolehlivosti.
Redundance ve vrstvách
Nasazení do více oblastí v modelu aktivní-aktivní. Aplikace se distribuuje ve dvou nebo více oblastech Azure, které zpracovávají aktivní uživatelský provoz.
Využijte Zóny dostupnosti (AZ) pro všechny považované služby za účelem maximalizace dostupnosti v rámci jedné oblasti Azure a distribuci komponent mezi fyzicky oddělená datová centra uvnitř oblasti.
Vyberte prostředky, které podporují globální distribuci.
Projděte si klíčové úlohy s dobře navrženou architekturou: globální distribuce.
Razítka nasazení
Nasaďte místní razítko jako jednotku škálování, kde je možné nezávisle zřídit logickou sadu prostředků, aby se zachovaly změny v poptávce. Každé razítko také používá několik vnořených jednotek škálování, jako jsou rozhraní API front-endu a procesory na pozadí, které se můžou nezávisle škálovat a vysunou.
Projděte si klíčové úlohy s dobře navrženou architekturou: Architektura jednotek škálování.
Spolehlivá a opakovatelná nasazení
Použijte princip infrastruktury jako kódu (IaC) pomocí technologií, jako je Terraform, k zajištění správy verzí a standardizovaného provozního přístupu pro komponenty infrastruktury.
Implementujte nulové výpadky s modrými nebo zelenými kanály nasazení. Kanály sestavení a verze musí být plně automatizované, aby bylo možné nasazovat razítka jako jednu provozní jednotku pomocí modrých/zelených nasazení s použitým průběžným ověřováním.
Použijte konzistenci prostředí napříč všemi považovanými prostředími se stejným kódem kanálu nasazení v produkčním a předprodukčním prostředí. Tím se eliminují rizika spojená s nasazením a procesovými variacemi napříč prostředími.
Zajištění průběžného ověřování integrací automatizovaného testování v rámci procesů DevOps, včetně synchronizovaného zátěžového a chaosového testování, aby se plně ověřil stav kódu aplikace i základní infrastruktury.
Projděte si klíčové úlohy s dobře navrženou architekturou: Nasazení a testování.
Provozní přehledy
Mají federované pracovní prostory pro data pozorovatelnosti. Data monitorování globálních prostředků a regionálních prostředků se ukládají nezávisle na sobě. Centralizované úložiště pozorovatelnosti se nedoporučuje, abyste se vyhnuli jedinému bodu selhání. Dotazování mezi pracovními prostory slouží k dosažení sjednocené datové jímky a jediného podokna skla pro operace.
Vytvořte vrstvený model stavu, který mapuje stav aplikace na model semaforu pro kontextovou vizualizaci. Skóre stavu se počítají pro každou jednotlivou komponentu a pak se agregují na úrovni toku uživatele a v kombinaci s klíčovými nefunkčními požadavky, jako jsou výkon, jako koeficienty kvantifikaci stavu aplikace.
Projděte si klíčové úlohy s dobře navrženou architekturou: Modelování stavu.
Architektura
*Stáhněte si soubor Visia této architektury.
Komponenty této architektury mohou být tímto způsobem široce kategorizovány. Dokumentaci k produktům o službách Azure najdete v tématu Související prostředky.
Globální prostředky
Globální zdroje jsou dlouho žijící a sdílejí životnost systému. Mají schopnost být globálně dostupná v kontextu modelu nasazení s více oblastmi.
Tady jsou základní aspekty komponent. Podrobné informace o rozhodnutích najdete v tématu Globální zdroje informací.
Globální nástroj pro vyrovnávání zatížení
Globální nástroj pro vyrovnávání zatížení je kritický pro spolehlivé směrování provozu do regionálních nasazení s určitou úrovní záruky na základě dostupnosti back-endových služeb v oblasti. Tato komponenta by také měla mít možnost kontrolovat provoz příchozího přenosu dat, například přes firewall webových aplikací.
Azure Front Door se používá jako globální vstupní bod pro veškerý příchozí provoz HTTP(S) klientů s možnostmi firewallu webových aplikací (WAF) použitými pro zabezpečený příchozí provoz vrstvy 7. Pomocí protokolu TCP Anycast optimalizuje směrování pomocí páteřní sítě Microsoftu a umožňuje transparentní převzetí služeb při selhání v případě sníženého regionálního stavu. Směrování závisí na vlastníchsondch Azure Front Door také poskytuje integrovanou síť pro doručování obsahu (CDN) pro ukládání statických prostředků do mezipaměti pro komponentu webu.
Další možností je Traffic Manager, což je nástroj pro vyrovnávání zatížení vrstvy 4 založený na DNS. Selhání ale není pro všechny klienty transparentní, protože musí dojít k šíření DNS.
Projděte si klíčové úlohy, které jsou dobře navrženy: globální směrování provozu.
Databáze
Veškerý stav související s úlohou je uložený v externí databázi Azure Cosmos DB for NoSQL. Tato možnost byla zvolena, protože má sadu funkcí potřebnou pro ladění výkonu a spolehlivosti, a to jak na straně klienta, tak na straně serveru. Důrazně doporučujeme, aby účet s povoleným více hlavním zápisem.
Poznámka
I když konfigurace zápisu do více oblastí představuje zlatý standard pro spolehlivost, existuje významný kompromis při nákladech, které by se měly správně zvážit.
Účet se replikuje do každého místního razítka a má také povolenou zónovou redundanci. Automatické škálování je také povolené na úrovni kontejneru, aby kontejnery podle potřeby automaticky škálovaly zřízenou propustnost.
Další informace najdete v tématu Datová platforma pro klíčové úlohy.
Projděte si klíčové úlohy s dobře navrženou architekturou: Globálně distribuované úložiště dat s více zápisy.
Registr kontejneru
Azure Container Registry se používá k ukládání všech imagí kontejneru. Má možnosti geografické replikace, které umožňují prostředkům fungovat jako jeden registr, který obsluhuje více oblastí s více hlavními regionálními registry.
Jako bezpečnostní opatření povolte přístup jenom k požadovaným entitě a ověřte tento přístup. Například v implementaci je přístup správce zakázaný. Výpočetní cluster tedy může vyžádat image pouze s přiřazeními rolí Microsoft Entra.
Projděte si klíčové úlohy s dobře navrženou architekturou: Container Registry.
Regionální zdroje
Místní prostředky se zřídí jako součást razítka nasazení do jedné oblasti Azure. Tyto prostředky nesdílely nic s prostředky v jiné oblasti. Je možné je nezávisle odebrat nebo replikovat do dalších oblastí. Sdílejí ale mezi sebou globální prostředky .
V této architektuře nasadí sjednocený kanál nasazení razítko s těmito prostředky.
Tady jsou základní aspekty komponent. Podrobné informace o rozhodnutích najdete v tématu Zdroje informací o místním razítku.
Front-end
Tato architektura používá jednostránkovou aplikaci (SPA), která odesílá požadavky do back-endových služeb. Výhodou je, že výpočetní prostředky potřebné pro webové prostředí se místo serverů přesměrují na klienta. Spa je hostovaná jako statický web v účtu úložiště Azure.
Další možností je Služba Azure Static Web Apps, která zavádí další aspekty, jako je zveřejnění certifikátů, připojení globálního nástroje pro vyrovnávání zatížení a další faktory.
Statický obsah se obvykle ukládá do mezipaměti v úložišti blízko klienta pomocí sítě pro doručování obsahu (CDN), aby bylo možné data rychle obsluhovat bez přímé komunikace s back-endovými servery. Jedná se o nákladově efektivní způsob, jak zvýšit spolehlivost a snížit latenci sítě. V této architektuře se integrované funkce CDN služby Azure Front Door používají k ukládání statického obsahu webu do mezipaměti v hraniční síti.
Výpočtový cluster
Back-endové výpočetní prostředí spouští aplikaci složenou ze tří mikroslužeb a je bezstavová. Kontejnerizace je tedy vhodná strategie pro hostování aplikace. Služba Azure Kubernetes Service (AKS) byla zvolena, protože splňuje většinu obchodních požadavků a Kubernetes je široce přijímaná napříč mnoha odvětvími. AKS podporuje pokročilou škálovatelnost a topologie nasazení. Úroveň SLA pro dostupnost AKS se důrazně doporučuje pro hostování důležitých aplikací, protože poskytuje záruky dostupnosti pro řídicí rovinu Kubernetes.
Azure nabízí další výpočetní služby, jako jsou Azure Functions a Aplikace Azure Services. Tyto možnosti přesměrují další odpovědnosti za správu do Azure za cenu flexibility a hustoty.
Poznámka
Vyhněte se ukládání stavu do výpočetního clusteru, mějte na paměti dočasný charakter kolků. Co nejvíce zachovejte stav v externí databázi, abyste udrželi jednoduché operace škálování a obnovení. Například v AKS se pody často mění. Připojení stavu k podům zvýší zátěž konzistence dat.
Projděte si dobře navrženou kritickou úlohu: Orchestrace kontejnerů a Kubernetes.
Regionální zprostředkovatel zpráv
K optimalizaci výkonu a zachování rychlosti odezvy během špičky návrh používá asynchronní zasílání zpráv ke zpracování náročných systémových toků. Vzhledem k tomu, že požadavek se rychle potvrdí zpět do rozhraní API front-endu, požadavek se také zařadí do fronty ve zprostředkovateli zpráv. Tyto zprávy následně využívá back-endová služba, která například zpracovává operaci zápisu do databáze.
Celé razítko je bezstavové s výjimkou určitých bodů, například tohoto zprostředkovatele zpráv. Data se ve zprostředkovateli zařadí do fronty po krátkou dobu. Zprostředkovatel zpráv musí zaručit alespoň jedno doručení. To znamená, že zprávy budou ve frontě, pokud se zprostředkovatel po obnovení služby stane nedostupným. Je ale zodpovědností spotřebitele určit, jestli tyto zprávy stále potřebují zpracovat. Fronta se vyprázdní po zpracování a uložení zprávy do globální databáze.
V tomto návrhu se používá Azure Event Hubs . Pro vytváření kontrolních bodů se zřizuje další účet Azure Storage. Služba Event Hubs je doporučenou volbou pro případy použití, které vyžadují vysokou propustnost, jako je streamování událostí.
Pro případy použití, které vyžadují další záruky zpráv, se doporučuje Azure Service Bus. Umožňuje dvoufázové potvrzení s kurzorem na straně klienta a také funkce, jako je předdefinovaná fronta nedoručených zpráv a možnosti odstranění duplicitních dat.
Další informace najdete v tématu Služby zasílání zpráv pro klíčové úlohy.
Projděte si dobře navrženou kritickou úlohu: Volně svázaná architektura řízená událostmi.
Místní úložiště tajných kódů
Každé razítko má vlastní službu Azure Key Vault , která ukládá tajné kódy a konfiguraci. Existují běžné tajné kódy, jako jsou připojovací řetězec globální databáze, ale existují také informace jedinečné pro jedno razítko, jako je například služba Event Hubs připojovací řetězec. Nezávislé prostředky se také vyhýbají jedinému bodu selhání.
Projděte si klíčové úlohy, které jsou dobře navrženy: Ochrana integrity dat.
Kanál nasazení
Kanály sestavení a verze pro kritickou aplikaci musí být plně automatizované. Proto by neměla být provedena žádná akce ručně. Tento návrh ukazuje plně automatizované kanály, které nasazují ověřené razítko konzistentně pokaždé. Dalším alternativním přístupem je nasazení kumulativních aktualizací do existujícího kolku.
Úložiště zdrojového kódu
GitHub se používá ke správě zdrojového kódu a poskytuje vysoce dostupnou platformu založenou na Gitu pro spolupráci s kódem aplikace a kódem infrastruktury.
Kanály kontinuální integrace/průběžného doručování (CI/CD)
Automatizované kanály se vyžadují pro sestavování, testování a nasazování úloh v předprodukčních a produkčních prostředích. Služba Azure Pipelines je zvolena vzhledem k bohaté sadě nástrojů, která může cílit na Azure a další cloudové platformy.
Další možností je GitHub Actions pro kanály CI/CD. Přidanou výhodou je, že zdrojový kód a kanál lze sloučit. Služba Azure Pipelines se ale zvolila kvůli bohatším funkcím CD.
Projděte si klíčové úlohy, které jsou dobře navrženy: procesy DevOps.
Agenti sestavení
Agenti sestavení hostovaní Microsoftem používají tuto implementaci ke snížení složitosti a režijních nákladů na správu. Agenty v místním prostředí je možné použít ve scénářích, které vyžadují posílení stavu zabezpečení.
Poznámka
Použití agentů v místním prostředí je demonstrováno v klíčovém prostředí – Připojení referenční implementaci.
Zdroje pozorovatelnosti
Provozní data z aplikací a infrastruktury musí být k dispozici, aby umožňovala efektivní provoz a maximalizovala spolehlivost. Tento odkaz poskytuje směrný plán pro dosažení holistické pozorovatelnosti aplikace.
Sjednocená datová jímka
- Azure Log Analytics se používá jako sjednocená jímka k ukládání protokolů a metrik pro všechny komponenty aplikací a infrastruktury.
- Aplikace Azure Přehledy se používá jako nástroj pro správu výkonu aplikací (APM), který shromažďuje všechna data monitorování aplikací a ukládá je přímo v Log Analytics.
Data monitorování globálních prostředků a regionálních prostředků by se měla ukládat nezávisle na sobě. Jedno centralizované úložiště pozorovatelnosti se nedoporučuje, aby nedocházelo k jedinému bodu selhání. Dotazování mezi pracovními prostory slouží k dosažení jednoho podokna skla.
V této architektuře musí být monitorování prostředků v rámci oblasti nezávislé na samotném razítku, protože pokud kolek odbouráte, stále chcete zachovat pozorovatelnost. Každé místní razítko má vlastní vyhrazené aplikační Přehledy a pracovní prostor služby Log Analytics. Prostředky se zřizují pro každou oblast, ale prožívají razítka.
Podobně se data ze sdílených služeb, jako jsou Azure Front Door, Azure Cosmos DB a Container Registry, ukládají ve vyhrazené instanci pracovního prostoru služby Log Analytics.
Archivace a analýzy dat
Provozní data, která nejsou nutná pro aktivní operace, se exportují z Log Analytics do účtů úložiště Azure pro účely uchovávání dat a k poskytnutí analytického zdroje pro AIOps, který je možné použít k optimalizaci modelu stavu aplikace a provozních postupů.
Projděte si klíčové úlohy s dobře navrženou architekturou: Prediktivní akce a operace umělé inteligence.
Toky požadavků a procesorů
Tento obrázek znázorňuje tok procesoru požadavku a pozadí referenční implementace.
Popis tohoto toku je v následujících částech.
Tok požadavků na web
Požadavek na webové uživatelské rozhraní se odešle do globálního nástroje pro vyrovnávání zatížení. Pro tuto architekturu je globální nástroj pro vyrovnávání zatížení Azure Front Door.
Pravidla WAF se vyhodnocují. Pravidla WAF pozitivně ovlivňují spolehlivost systému tím, že chrání před různými útoky, jako jsou skriptování mezi weby (XSS) a injektáž SQL. Azure Front Door vrátí žadateli chybu, pokud dojde k porušení pravidla WAF a zpracování se zastaví. Pokud nejsou porušena žádná pravidla WAF, Azure Front Door pokračuje ve zpracování.
Azure Front Door používá pravidla směrování k určení back-endového fondu k předání požadavku. Jak se požadavky shodují s pravidlem směrování. V této referenční implementaci pravidla směrování umožňují službě Azure Front Door směrovat požadavky uživatelského rozhraní a rozhraní API front-endu na různé back-endové prostředky. V tomto případě vzor /* odpovídá pravidlu směrování uživatelského rozhraní. Toto pravidlo směruje požadavek do back-endového fondu, který obsahuje účty úložiště se statickými weby, které hostují jednostránkové aplikace (SPA). Azure Front Door používá prioritu a tloušťku přiřazenou back-endům ve fondu k výběru back-endu pro směrování požadavku. Metody směrování provozu k původu Azure Front Door používá sondy stavu k zajištění, že požadavky nejsou směrovány na back-endy, které nejsou v pořádku. Spa se obsluhuje z vybraného účtu úložiště se statickým webem.
Poznámka
Termíny back-endové fondy a back-endy ve službě Azure Front Door Classic se označují jako skupiny původu a zdroje v úrovních Azure Front Door Standard nebo Premium.
Spa provede volání rozhraní API na hostitele front-endu služby Azure Front Door. Vzor adresy URL požadavku rozhraní API je /api/*.
Tok požadavků rozhraní API front-endu
Pravidla WAF se vyhodnocují jako v kroku 2.
Azure Front Door odpovídá požadavku na pravidlo směrování rozhraní API podle vzoru /api/*. Pravidlo směrování rozhraní API směruje požadavek do back-endového fondu, který obsahuje veřejné IP adresy pro kontrolery příchozího přenosu dat NGINX, které vědí, jak směrovat požadavky na správnou službu ve službě Azure Kubernetes Service (AKS). Stejně jako předtím služba Azure Front Door používá prioritu a tloušťku přiřazenou back-endům k výběru správného back-endu kontroleru příchozího přenosu dat NGINX.
V případě požadavků GET rozhraní API front-endu provádí operace čtení v databázi. Pro tuto referenční implementaci je databáze globální instancí služby Azure Cosmos DB. Azure Cosmos DB má několik funkcí, díky kterým je vhodná pro klíčové úlohy, včetně možnosti snadné konfigurace oblastí s více zápisy, což umožňuje automatické převzetí služeb při selhání pro čtení a zápisy do sekundárních oblastí. Rozhraní API používá klientskou sadu SDK nakonfigurovanou s logikou opakování ke komunikaci se službou Azure Cosmos DB. Sada SDK určuje optimální pořadí dostupných oblastí Azure Cosmos DB pro komunikaci na základě parametru ApplicationRegion.
V případě požadavků POST nebo PUT rozhraní API front-endu provádí zápisy do zprostředkovatele zpráv. V referenční implementaci je zprostředkovatel zpráv Azure Event Hubs. Alternativně můžete zvolit Service Bus. Obslužná rutina později přečte zprávy zprostředkovatele zpráv a provede všechny požadované zápisy do služby Azure Cosmos DB. Rozhraní API používá klientskou sadu SDK k provádění zápisů. Klient je možné nakonfigurovat pro opakování.
Tok procesoru na pozadí
Procesory na pozadí zpracovávají zprávy zprostředkovatele zpráv. Procesory na pozadí používají klientskou sadu SDK k provádění čtení. Klient je možné nakonfigurovat pro opakování.
Procesory na pozadí provádějí příslušné operace zápisu v globální instanci Služby Azure Cosmos DB. Procesory na pozadí používají klientskou sadu SDK nakonfigurovanou s opakováním připojení ke službě Azure Cosmos DB. Seznam upřednostňovaných oblastí klienta je možné nakonfigurovat s více oblastmi. V takovém případě se v případě selhání zápisu provede opakování v další upřednostňované oblasti.
Oblasti návrhu
Doporučujeme prozkoumat tyto oblasti návrhu pro doporučení a osvědčené postupy při definování klíčové architektury.
| Oblast návrhu | Popis |
|---|---|
| Návrh aplikace | Vzory návrhu, které umožňují škálování a zpracování chyb. |
| Aplikační platforma | Volby infrastruktury a zmírnění potenciálních případů selhání. |
| Datová platforma | Volby v technologiích úložiště dat informované vyhodnocením požadovaných objemů, rychlosti, rozmanitosti a charakteristiky správnosti. |
| Sítě a možnosti připojení | Aspekty sítě pro směrování příchozího provozu na kolky |
| Modelování stavu | Aspekty pozorovatelnosti prostřednictvím analýzy dopadu na zákazníky korelují monitorování za účelem určení celkového stavu aplikace. |
| Nasazení a testování | Strategie pro kanály CI/CD a aspekty automatizace s využitím zahrnutých testovacích scénářů, jako jsou synchronizované zátěžové testování a injektáž selhání (chaos). |
| Zabezpečení | Zmírnění vektorů útoku prostřednictvím modelu Microsoft nulová důvěra (Zero Trust) |
| Provozní postupy | Procesy související s nasazením, správou klíčů, opravami a aktualizacemi |
** Označuje aspekty oblasti návrhu, které jsou specifické pro tuto architekturu.
Související prostředky
Dokumentaci k produktům pro služby Azure používané v této architektuře najdete v těchto článcích.
- Azure Front Door
- Azure Cosmos DB
- Azure Container Registry
- Azure Log Analytics
- Azure Key Vault
- Azure Service Bus
- Azure Kubernetes Service
- Azure Application Insights
- Azure Event Hubs
- Azure Blob Storage
Nasazení této architektury
Nasaďte referenční implementaci, abyste získali úplné znalosti o považovaných prostředcích, včetně toho, jak jsou zprovozněné v klíčovém kontextu. Obsahuje průvodce nasazením určený k ilustraci přístupu orientovaného na řešení pro vývoj důležitých aplikací v Azure.
Další kroky
Pokud chcete rozšířit základní architekturu o síťové ovládací prvky příchozího a výchozího provozu, podívejte se na tuto architekturu.