Aspekty návrhu hybridních aplikací
Microsoft Azure je jediný konzistentní hybridní cloud. Umožňuje opakovaně používat investice do vývoje a umožňuje aplikacím, které mohou zahrnovat globální Azure, suverénní cloudy Azure a Azure Stack, což je rozšíření Azure ve vašem datacentru. Aplikace, které zahrnují cloudy, se také označují jako hybridní aplikace.
Průvodce architekturou aplikací Azure popisuje strukturovaný přístup k návrhu aplikací, které jsou škálovatelné, odolné a vysoce dostupné. Aspekty popsané v průvodci architekturou aplikací Azure stejně platí pro aplikace navržené pro jeden cloud a pro aplikace, které zahrnují cloudy.
Tento článek rozšiřuje
Hybridní scénáře se výrazně liší od prostředků, které jsou k dispozici pro vývoj, a zahrnují aspekty, jako jsou zeměpisné údaje, zabezpečení, přístup k internetu a další aspekty. I když tato příručka nemůže uvést konkrétní aspekty, může vám poskytnout několik klíčových pokynů a osvědčených postupů, které byste měli dodržovat. Úspěšné navrhování, konfigurace, nasazování a údržba hybridní architektury aplikací zahrnuje mnoho aspektů návrhu, které pro vás nemusí být ze své podstaty známé.
Cílem tohoto dokumentu je agregovat možné otázky, ke kterým může dojít při implementaci hybridních aplikací, a zvážit (tyto pilíře) a osvědčené postupy pro práci s nimi. Když tyto otázky vyřešíte během fáze návrhu, vyhnete se problémům, které by mohly způsobit v produkčním prostředí.
V podstatě tyto otázky musíte zvážit před vytvořením hybridní aplikace. Abyste mohli začít, musíte udělat následující věci:
- Identifikujte a vyhodnoťte komponenty aplikace.
- Vyhodnoťte komponenty aplikace proti pilířům.
Vyhodnocení komponent aplikace
Každá komponenta aplikace má svou vlastní specifickou roli v rámci větší aplikace a měla by se zkontrolovat se všemi aspekty návrhu. Požadavky a funkce jednotlivých komponent by se měly namapovat na tyto aspekty, aby bylo možné určit architekturu aplikace.
Dekompisujte aplikaci do jejích komponent tím, že prozkoumáte architekturu vaší aplikace a určíte, čeho se skládá. Součástí můžou být i jiné aplikace, se kterými vaše aplikace komunikuje. Při identifikaci komponent vyhodnoťte zamýšlené hybridní operace podle jejich charakteristik tak, že položíte tyto otázky:
- Jaký je účel komponenty?
- Jaké jsou vzájemné závislosti mezi komponentami?
Aplikace může mít například front-end a back-end definovaný jako dvě komponenty. V hybridním scénáři je front-end v jednom cloudu a back-end je v druhém. Aplikace poskytuje komunikační kanály mezi front-endem a uživatelem a také mezi front-endem a back-endem.
Komponenta aplikace je definována mnoha formuláři a scénáři. Nejdůležitějším úkolem je identifikovat je a jejich cloud nebo místní umístění.
Běžné součásti aplikace, které se mají zahrnout do inventáře, jsou uvedené v tabulce 1.
Tabulka 1. Běžné komponenty aplikací
| komponent |
Pokyny k hybridní aplikaci |
|---|---|
| Klientská připojení | Vaše aplikace (na jakémkoli zařízení) má přístup k uživatelům různými způsoby, a to z jednoho vstupního bodu, včetně následujících způsobů: – Model klientského serveru, který vyžaduje, aby měl uživatel nainstalovaný klienta pro práci s aplikací. Serverová aplikace, ke které se přistupuje z prohlížeče. – Klientská připojení můžou obsahovat oznámení, když je připojení přerušené, nebo upozornění, když se můžou účtovat poplatky za roaming. |
| Autentizace | Ověřování může být vyžadováno pro uživatele, který se připojuje k aplikaci, nebo z jedné komponenty, která se připojuje k jiné. |
| Rozhraní api | Vývojářům můžete poskytnout programový přístup k aplikaci pomocí sad rozhraní API a knihoven tříd a poskytnout rozhraní pro připojení založené na internetových standardech. Rozhraní API můžete také použít k dekompilování aplikace do nezávisle provozních logických jednotek. |
| Služby | K poskytování funkcí aplikace můžete využít stručné služby. Služba může být modul, na kterém aplikace běží. |
| Fronty | Fronty můžete použít k uspořádání stavu životních cyklů a stavů součástí vaší aplikace. Tyto fronty můžou poskytovat zasílání zpráv, oznámení a ukládání do vyrovnávací paměti pro přihlášení k odběru stran. |
| Úložiště dat | Aplikace může být bezstavová nebo stavová. Stavové aplikace potřebují úložiště dat, které je možné splnit mnoha formáty a svazky. |
| Ukládání dat do mezipaměti | Komponenta ukládání dat do mezipaměti ve vašem návrhu může strategicky řešit problémy s latencí a hrát roli při aktivaci cloudového nárůstu. |
| Příjem dat | Data je možné odeslat do aplikace mnoha způsoby, od uživatelem odeslaných hodnot ve webovém formuláři až po nepřetržitě velký objem toku dat. |
| Zpracování dat | Úlohy zpracování dat (například sestavy, analýzy, dávkové exporty a transformace dat) je možné zpracovávat ve zdroji nebo přesměrovat na samostatnou komponentu pomocí kopie dat. |
Posouzení komponent aplikace pro pilíře
Pro každou komponentu vyhodnoťte její charakteristiky pro každý pilíř. Při vyhodnocování jednotlivých komponent se všemi pilíři se vám můžou otázky, které jste nepovažovaly, znáte, že to má vliv na návrh hybridní aplikace. Při optimalizaci aplikace by mohlo být přínosné při závislosti natěchtoch Tabulka 2 obsahuje popis jednotlivých pilířů v souvislosti s hybridními aplikacemi.
Tabulka 2. Pilíře
| pilíře |
popis |
|---|---|
| Umístění | Strategické umístění komponent v hybridních aplikacích. |
| Škálovatelnost | Schopnost systému zvládnout zvýšené zatížení. |
| Dostupnost | Poměr času, po který je hybridní aplikace funkční a funkční. |
| Odolnost | Možnost obnovení hybridní aplikace |
| Ovladatelnost | Provozní procesy, které udržují systém spuštěný v produkčním prostředí |
| Bezpečnost | Ochrana hybridních aplikací a dat před hrozbami |
Umístění
Hybridní aplikace má ze své podstaty důležité informace o umístění, například pro datové centrum.
Umístění je důležitou úlohou umístění součástí, aby mohly nejlépe obsluhovat hybridní aplikaci. Podle definice pokrývají hybridní aplikace umístění, například z místního prostředí do cloudu a mezi různými cloudy. Komponenty aplikace můžete umístit do cloudů dvěma způsoby:
vertikální hybridní aplikace
Komponenty aplikací se distribuují napříč umístěními. Každá jednotlivá komponenta může mít více instancí umístěných pouze v jednom umístění.horizontálních hybridních aplikací
Komponenty aplikací se distribuují napříč umístěními. Každá jednotlivá komponenta může mít více instancí, které pokrývají více umístění.Některé komponenty si mohou být vědomy jejich umístění, zatímco jiné nemají žádné znalosti o jejich umístění a umístění. Tuto virtuozitu lze dosáhnout abstrakcí vrstvy. Tato vrstva s moderní aplikační architekturou, jako jsou mikroslužby, může definovat, jak je aplikace obsluhována umístěním komponent aplikací fungujících na uzlech napříč cloudy.
Kontrolní seznam pro umístění
Ověřte požadovaná umístění. Ujistěte se, že aplikace nebo jakákoli jeho komponenta musí fungovat nebo vyžaduje certifikaci pro konkrétní cloud. To může zahrnovat požadavky na suverenitu vaší společnosti nebo diktované zákonem. Také určete, jestli se pro konkrétní umístění nebo národní prostředí vyžadují nějaké místní operace.
Zjištění závislostí připojení Požadovaná umístění a další faktory můžou určovat závislosti připojení mezi vašimi komponentami. Při umístění komponent určete optimální možnosti připojení a zabezpečení pro komunikaci mezi nimi. Mezi volby patří VPN,ExpressRoute, a hybridní připojení.
Vyhodnocení možností platformy Pro každou komponentu aplikace zjistěte, jestli je v cloudu dostupný požadovaný poskytovatel prostředků a jestli šířka pásma může vyhovovat očekávaným požadavkům na propustnost a latenci.
Naplánujte přenositelnost. Pomocí moderních aplikačních architektur, jako jsou kontejnery nebo mikroslužby, můžete naplánovat přesun operací a zabránit závislostem služeb.
Určení požadavků na suverenitu dat Hybridní aplikace jsou zaměřené na příjem izolace dat, například v místním datacentru. Zkontrolujte umístění prostředků, abyste optimalizovali úspěch pro využití tohoto požadavku.
Naplánujte latenci. Operace mezi cloudy můžou představovat fyzickou vzdálenost mezi komponentami aplikace. Ověřte požadavky, které by vyhovovaly jakékoli latenci.
Řízení toků provozu Zpracování špiček využití a vhodné a zabezpečené komunikace pro osobní identifikovatelná data informací při přístupu front-endem ve veřejném cloudu.
Škálovatelnost
Škálovatelnost je schopnost systému zpracovávat zvýšené zatížení aplikace, která se může v průběhu času lišit, protože ostatní faktory a síly ovlivňují velikost cílové skupiny kromě velikosti a rozsahu aplikace.
Základní diskuzi o tomto pilíři najdete v tématu škálovatelnosti v pěti pilířích efektivity architektury.
Horizontální škálování hybridních aplikací umožňuje přidávat další instance, aby splňovaly poptávku, a pak je zakazovaly během tišších období.
V hybridních scénářích vyžaduje horizontální navýšení kapacity jednotlivých komponent další aspekty, pokud jsou komponenty rozložené mezi cloudy. Škálování jedné části aplikace může vyžadovat škálování jiného. Pokud se například počet klientských připojení zvýší, ale webové služby aplikace se nenavýšují odpovídajícím způsobem, zatížení databáze může aplikaci saturovat.
Některé komponenty aplikace můžou škálovat lineárně, zatímco jiné mají závislosti škálování a můžou být omezené na to, v jakém rozsahu se můžou škálovat. Například tunel VPN poskytující hybridní připojení pro umístění komponent aplikace má omezení šířky pásma a latence, na které se dá škálovat. Jak se komponenty aplikace škálují, aby se zajistilo splnění těchto požadavků?
Kontrolní seznam škálovatelnosti
Zjištění prahových hodnot škálování Pokud chcete zpracovávat různé závislosti v aplikaci, určete rozsah, ve kterém se komponenty aplikací v různých cloudech můžou škálovat nezávisle na sobě, a přitom stále splňují požadavky na spuštění aplikace. Hybridní aplikace často potřebují škálovat konkrétní oblasti v aplikaci, aby zvládly funkci při interakci a ovlivňují zbytek aplikace. Například překročení počtu front-endových instancí může vyžadovat škálování back-endu.
Definujte plány škálování. Většina aplikací má zaneprázdněná období, takže je potřeba agregovat dobu špičky do plánů, abyste mohli koordinovat optimální škálování.
Použijte centralizovaný monitorovací systém. Funkce monitorování platformy můžou poskytovat automatické škálování, ale hybridní aplikace potřebují centralizovaný monitorovací systém, který agreguje stav systému a zatížení. Centralizovaný monitorovací systém může iniciovat škálování prostředku v jednom umístění a škálování v závislosti na prostředku v jiném umístění. Kromě toho může centrální monitorovací systém sledovat, které cloudy automaticky škálují prostředky a které cloudy ne.
Využijte možnosti automatického škálování (jak je k dispozici). Pokud jsou funkce automatického škálování součástí vaší architektury, implementujete automatické škálování nastavením prahových hodnot, které definují, kdy je potřeba vertikálně navýšit, snížit nebo snížit kapacitu komponenty aplikace. Příkladem automatického škálování je připojení klienta, které se automaticky škáluje v jednom cloudu, aby zvládlo zvýšenou kapacitu, ale způsobí také další závislosti aplikace rozložené do různých cloudů. Je nutné zjistit možnosti automatického škálování těchto závislých komponent.
Pokud automatické škálování není dostupné, zvažte implementaci skriptů a dalších prostředků, aby se přizpůsobily ručnímu škálování, aktivované prahovými hodnotami v centralizované monitorovacím systému.
Určete očekávané zatížení podle umístění. Hybridní aplikace, které zpracovávají požadavky klientů, se můžou primárně spoléhat na jedno umístění. Pokud zatížení požadavků klientů překročí prahovou hodnotu, je možné do jiného umístění přidat další prostředky, které distribuují zatížení příchozích požadavků. Zajistěte, aby klientská připojení zvládla zvýšené zatížení, a také určete všechny automatizované postupy pro připojení klientů ke zpracování zatížení.
Dostupnost
Dostupnost je čas, kdy je systém funkční a funkční. Dostupnost se měří jako procento doby provozu. Chyby aplikací, problémy s infrastrukturou a zatížení systému můžou snížit dostupnost.
Základní diskuzi o tomto pilíři najdete v tématu Dostupnost v pěti pilířích efektivity architektury.
Kontrolní seznam dostupnosti
Zajištění redundance pro připojení Hybridní aplikace vyžadují připojení mezi cloudy, mezi kterými je aplikace rozložená. Máte možnost volby technologií pro hybridní připojení, takže kromě vaší primární technologie použijte jinou technologii k zajištění redundance funkcí automatizovaného převzetí služeb při selhání, pokud primární technologie selže.
Klasifikovat domény selhání Aplikace odolné proti chybám vyžadují více domén selhání. Domény selhání pomáhají izolovat bod selhání, například pokud jeden pevný disk selže místně, pokud dojde k výpadku přepínače top-of-rack nebo pokud je úplné datacentrum nedostupné. V hybridní aplikaci je možné umístění klasifikovat jako doménu selhání. Čím více požadavků na dostupnost, tím více je potřeba vyhodnotit, jak se má klasifikovat jedna doména selhání.
Klasifikujte upgradové domény. Domény upgradu se používají k zajištění dostupnosti instancí komponent aplikace, zatímco jiné instance stejné komponenty se obsluhují aktualizacemi nebo upgrady funkcí. Stejně jako u domén selhání je možné upgradovat domény klasifikovat jejich umístěním napříč umístěními. Před upgradem do jiného umístění musíte určit, jestli komponenta aplikace může pojmout upgrade v jednom umístění nebo jestli se vyžadují jiné konfigurace domény. Jedna samotná lokalita může mít více upgradových domén.
Sledujte instance a dostupnost. Komponenty aplikací s vysokou dostupností můžou být dostupné prostřednictvím vyrovnávání zatížení a synchronní replikace dat. Před přerušením služby musíte určit, kolik instancí může být offline.
Implementujte samoopravení. V případě, že problém způsobí přerušení dostupnosti aplikace, může detekce monitorovacího systému zahájit aktivity samoopravení do aplikace, jako je vyprázdnění instance selhání a opětovné nasazení aplikace. S největší pravděpodobností to vyžaduje řešení centrálního monitorování integrované s hybridním kanálem kontinuální integrace a průběžného doručování (CI/CD). Aplikace je integrovaná s monitorovacím systémem, který identifikuje problémy, které by mohly vyžadovat opětovné nasazení komponenty aplikace. Monitorovací systém může také aktivovat hybridní CI/CD, aby znovu nasadil komponentu aplikace a potenciálně všechny další závislé komponenty ve stejném nebo jiném umístění.
Udržovat smlouvy o úrovni služeb (SLA). Dostupnost je důležitá pro všechny smlouvy, aby se zachovalo připojení ke službám a aplikacím, které máte se zákazníky. Každé umístění, na které vaše hybridní aplikace spoléhá, může mít vlastní smlouvu SLA. Tyto různé smlouvy SLA můžou ovlivnit celkovou smlouvu SLA hybridní aplikace.
Odolnost
Odolnost je schopnost hybridní aplikace a systému zotavit se z chyb a nadále fungovat. Cílem odolnosti je vrátit aplikaci do plně funkčního stavu po selhání. Strategie odolnosti zahrnují řešení, jako je zálohování, replikace a zotavení po havárii.
Základní diskuzi o tomto pilíři najdete v odolnosti v pěti pilířích efektivity architektury.
Kontrolní seznam odolnosti
Odkryjte závislosti zotavení po havárii. Zotavení po havárii v jednom cloudu může vyžadovat změny komponent aplikace v jiném cloudu. Pokud dojde k převzetí služeb při selhání jedné nebo více součástí z jednoho cloudu do jiného umístění, a to buď v rámci stejného cloudu, nebo do jiného cloudu, je potřeba, aby závislé komponenty o těchto změnách věděly. To zahrnuje také závislosti připojení. Odolnost vyžaduje plně otestovaný plán obnovení aplikací pro každý cloud.
Vytvoření toku obnovení Efektivní návrh toku obnovení vyhodnotil komponenty aplikace pro jejich schopnost přizpůsobit vyrovnávací paměti, opakování, opakovat neúspěšný přenos dat a v případě potřeby se vrátit k jiné službě nebo pracovnímu postupu. Musíte určit, jaký mechanismus zálohování se má použít, co zahrnuje jeho postup obnovení a jak často se testuje. Měli byste také určit frekvenci přírůstkových i úplných záloh.
Otestujte částečné obnovení. Částečné obnovení pro část aplikace může uživatelům poskytnout jistotu, že všechny nejsou dostupné. Tato část plánu by měla zajistit, aby částečné obnovení nemělo žádné vedlejší účinky, jako je služba zálohování a obnovení, která interaguje s aplikací, aby ji před provedením zálohování řádně vypnula.
Určete instigátory zotavení po havárii a přiřaďte odpovědnost. Plán obnovení by měl popisovat, kdo a jaké role může kromě toho, co je možné zálohovat a obnovovat, iniciovat akce zálohování a obnovení.
Porovnejte prahové hodnoty samoopravení s zotavením po havárii. Určete možnosti samoopravení aplikace pro automatické spuštění obnovení a dobu potřebnou k samoopravení aplikace, která se považuje za selhání nebo úspěch. Určete prahové hodnoty pro každý cloud.
Ověřte dostupnost funkcí odolnosti. Určete dostupnost funkcí a možností odolnosti pro každé umístění. Pokud umístění neposkytuje požadované funkce, zvažte integraci umístění do centralizované služby, která poskytuje funkce odolnosti.
Určení výpadků Určete očekávaný výpadek kvůli údržbě aplikace jako celku a jako součásti aplikace.
Zdokumentování postupů řešení potíží Definujte postupy řešení potíží pro opětovné nasazení prostředků a komponent aplikací.
Ovladatelnost
Důležité informace o správě hybridních aplikací při návrhu architektury jsou důležité. Dobře spravovaná hybridní aplikace poskytuje infrastrukturu jako kód, který umožňuje integraci konzistentního kódu aplikace do společného vývojového kanálu. Implementací konzistentního systémového a individuálního testování změn v infrastruktuře můžete zajistit integrované nasazení, pokud změny projdou testy a umožní jejich sloučení do zdrojového kódu.
Základní diskuzi o tomto pilíři najdete v tématu DevOps v pěti pilířích efektivity architektury.
Kontrolní seznam možností správy
Implementujte monitorování. Pomocí centralizovaného monitorovacího systému komponent aplikací rozložených mezi cloudy můžete poskytnout agregované zobrazení jejich stavu a výkonu. Tento systém zahrnuje monitorování komponent aplikace i souvisejících funkcí platformy.
Určete části aplikace, které vyžadují monitorování.
Koordinovat zásady. Každé umístění, které hybridní aplikace zahrnuje, může mít vlastní zásady, které pokrývají povolené typy prostředků, zásady vytváření názvů, značky a další kritéria.
Definujte a používejte role. Jako správce databáze musíte určit oprávnění požadovaná pro různé osoby (jako je vlastník aplikace, správce databáze a koncový uživatel), která potřebují přístup k prostředkům aplikace. Tato oprávnění je potřeba nakonfigurovat pro prostředky a uvnitř aplikace. Systém řízení přístupu na základě role (RBAC) umožňuje nastavit tato oprávnění k prostředkům aplikace. Tato přístupová práva jsou náročná, když jsou všechny prostředky nasazené v jednom cloudu, ale vyžadují ještě větší pozornost v případě, že jsou prostředky rozložené mezi cloudy. Oprávnění k prostředkům nastaveným v jednom cloudu se nevztahují na prostředky nastavené v jiném cloudu.
Používejte kanály CI/CD. Kanál kontinuální integrace a průběžného vývoje (CI/CD) může poskytovat konzistentní proces pro vytváření a nasazování aplikací, které se rozprostírá napříč cloudy, a poskytuje záruku kvality pro jejich infrastrukturu a aplikaci. Tento kanál umožňuje testování infrastruktury a aplikace v jednom cloudu a nasazení do jiného cloudu. Kanál dokonce umožňuje nasadit určité komponenty hybridní aplikace do jednoho cloudu a dalších komponent do jiného cloudu, což v podstatě tvoří základ pro hybridní nasazení aplikací. Systém CI/CD je důležitý pro zpracování komponent aplikace závislostí, které se vzájemně mají během instalace, jako je například webová aplikace, která potřebuje připojovací řetězec k databázi.
Správa životního cyklu Vzhledem k tomu, že prostředky hybridní aplikace můžou zahrnovat umístění, je potřeba agregovat jednotlivé funkce správy životního cyklu jednotlivých lokalit do jedné jednotky správy životního cyklu. Zvažte, jak se vytvářejí, aktualizují a odstraní.
Prozkoumejte strategie řešení potíží. Řešení potíží s hybridní aplikací zahrnuje více komponent aplikací, než je stejná aplikace spuštěná v jednom cloudu. Kromě připojení mezi cloudy je aplikace spuštěná na dvou platformách, nikoli na jedné. Důležitým úkolem při řešení potíží s hybridními aplikacemi je prozkoumat agregované monitorování stavu a výkonu komponent aplikace.
Bezpečnost
Zabezpečení je jedním z hlavních aspektů každé cloudové aplikace a pro hybridní cloudové aplikace se stává ještě důležitější.
Základní diskuzi o tomto pilíři najdete v zabezpečení v pěti pilířích efektivity architektury.
Kontrolní seznam zabezpečení
Předpokládejme porušení zabezpečení. Pokud dojde k ohrožení zabezpečení jedné části aplikace, ujistěte se, že existují řešení, která minimalizují šíření porušení zabezpečení, a to nejen v rámci stejného umístění, ale i napříč umístěními.
Monitorování povoleného síťového přístupu Určete zásady přístupu k síti pro aplikaci, jako je například přístup jenom k aplikaci z konkrétní podsítě, a povolte správné fungování jenom minimálních portů a protokolů mezi komponentami, které aplikace potřebuje.
Používejte robustní ověřování. Robustní schéma ověřování je důležité pro zabezpečení vaší aplikace. Zvažte použití zprostředkovatele federované identity, který poskytuje možnosti jednotného přihlašování a využívá jedno nebo několik následujících schémat: přihlašování pomocí uživatelského jména a hesla, veřejné a privátní klíče, dvojúrovňové nebo vícefaktorové ověřování a důvěryhodné skupiny zabezpečení. Kromě typů certifikátů a jejich požadavků určete vhodné prostředky pro ukládání citlivých dat a dalších tajných kódů pro ověřování aplikací.
Použijte šifrování. Určete, které oblasti aplikace používají šifrování, například pro ukládání dat nebo komunikaci klienta a přístup.
Používejte zabezpečené kanály. Zabezpečený kanál napříč cloudy je důležitý pro zajištění kontroly zabezpečení a ověřování, ochrany v reálném čase, karantény a dalších služeb napříč cloudy.
Definujte a používejte role. Implementujte role pro konfigurace prostředků a přístup s jednou identitou napříč cloudy. Určete požadavky na řízení přístupu na základě role (RBAC) pro aplikaci a její prostředky platformy.
Auditujte systém. Monitorování systému může protokolovat a agregovat data z komponent aplikace i souvisejících operací cloudové platformy.
Shrnutí
Tento článek obsahuje kontrolní seznam položek, které je důležité vzít v úvahu při vytváření a navrhování hybridních aplikací. Kontrola těchto pilířů před nasazením aplikace brání tomu, abyste na tyto otázky narazili v produkčních výpadcích a potenciálně se budete muset vrátit k návrhu.
Může to vypadat jako časově náročný úkol předem, ale pokud navrhujete aplikaci na základě těchto pilířů, snadno získáte návratnost investic.
Další kroky
Další informace najdete v následujících zdrojích informací: