Model geode

Model Geode zahrnuje nasazení kolekce back-endových služeb do sady geografickýchnodes, z nichž každý může obsluhovat jakoukoli žádost o libovolného klienta v libovolné oblasti. Tento model umožňuje obsluhovat požadavky ve stylu aktivní-aktivní , což zlepšuje latenci a zvyšuje dostupnost díky distribuci zpracování požadavků po celém světě.

Kontext a problém

Řada rozsáhlých služeb má specifické problémy související s geografickou dostupností a škálováním. Klasické návrhy často přenesou data do výpočetních prostředků uložením dat na vzdáleném SQL serveru, který slouží jako výpočetní úroveň pro tato data, a spoléhá na vertikální navýšení kapacity pro růst.

Klasický přístup může představovat řadu problémů:

• Problémy s latencí sítě pro uživatele přicházející z druhé strany světa pro připojení ke koncovému bodu hostování
• Správa provozu pro nárůsty poptávky, které můžou zahltit služby v jedné oblasti
• Nákladná složitost nasazení kopií infrastruktury aplikací do několika oblastí pro službu 24x7

Moderní cloudová infrastruktura se vyvinula tak, aby umožňovala geografické vyrovnávání zatížení front-endových služeb a zároveň umožňovala geografickou replikaci back-endových služeb. Z hlediska dostupnosti a výkonu je získání dat blíže uživateli. Pokud jsou data geograficky distribuovaná napříč dalekosáhlou uživatelskou základnou, měly by být úložiště geograficky distribuovaných dat také společné s výpočetními prostředky, které zpracovávají data. Model geode přináší výpočetní prostředky do dat.

Řešení

Nasaďte službu do řady satelitních nasazení rozložených po celém světě, z nichž každá se nazývá geode. Model geode využívá klíčové funkce Azure ke směrování provozu přes nejkratší cestu k blízké geografické sadě, která zlepšuje latenci a výkon. Každá geode je za globálním nástrojem pro vyrovnávání zatížení a používá geograficky replikovanou službu pro čtení i zápis, jako je Azure Cosmos DB , k hostování roviny dat a zajišťuje konzistenci dat napříč geografickou sadou. Služby replikace dat zajišťují, aby úložiště dat byla v různých geografických oblastech stejná, takže všechny požadavky je možné obsluhovat ze všech geografických des.

Klíčovým rozdílem mezi razítkem nasazení a geode je, že geody nikdy neexistují izolovaně. V produkční platformě by vždy mělo existovat více než jedna geode.

Geody mají následující charakteristiky:

• Skládá se z kolekce různorodých typů prostředků, často definovaných v šabloně.
• Nemají žádné závislosti mimo geografickou stopu a jsou samostatné. Žádná geode není závislá na jiné, aby fungovala, a pokud jedna zemře, ostatní budou dál fungovat.
• Jsou volně svázané přes hraniční síť a backplane replikace. Můžete například použít Azure Traffic Manager nebo Azure Front Door ke frontingu geografických měr, zatímco Azure Cosmos DB může fungovat jako backplan replikace. Geodes nejsou stejné jako clustery, protože sdílejí backplan replikace, takže platforma se stará o problémy s kvorem.

Model geode se vyskytuje v architekturách velkých objemů dat, které ke zpracování dat společně přidělovaných na stejném počítači používají komoditní hardware, a MapReduce ke konsolidaci výsledků napříč počítači. Další využití je téměř hraniční výpočetní prostředky, které přiblíží výpočetní prostředky inteligentnímu hraničnímu zařízení sítě, aby se zkrátila doba odezvy.

Služby můžou tento model používat více než desítky nebo stovky geodes. Kromě toho se zvyšuje odolnost celého řešení s každou přidanou geodeí, protože jakékoli geody můžou převzít, pokud oblastní výpadek převezme jednu nebo více geografických des offline.

Je také možné rozšířit místní techniky dostupnosti, jako jsou zóny dostupnosti nebo spárované oblasti, se vzorem geode pro globální dostupnost. To zvyšuje složitost, ale je užitečné, pokud je vaše architektura založená na modulu úložiště, jako je úložiště objektů blob, které se dá replikovat pouze do spárované oblasti. Geodes můžete nasadit do prostorové, zónové nebo regionální stopy s ohledem na regulační omezení nebo omezení latence v umístění.

Problémy a důležité informace

K implementaci tohoto modelu použijte následující techniky a technologie:

• Moderní postupy a nástroje DevOps pro vytváření a rychlé nasazování identických geografických měr napříč velkým počtem oblastí nebo instancí
• Automatické škálování pro škálování instancí výpočetních prostředků a propustnosti databáze v rámci geode Každá geode se škáluje jednotlivě v rámci společných omezení backplane.
• Front-endová služba, jako je Azure Front Door, která dělá akceleraci dynamického obsahu, rozděluje směrování TCP a Anycast.
• Replikace úložiště dat, jako je Azure Cosmos DB, za účelem řízení konzistence dat.
• Bezserverové technologie, pokud je to možné, aby se snížily náklady na průběžné nasazení, zejména v případě, že se zatížení často vyrovnává po celém světě. Tato strategie umožňuje nasazení mnoha geodes s minimálními dalšími investicemi. Bezserverové a spotřebované fakturační technologie snižují plýtvání a náklady z duplicitních geograficky distribuovaných nasazení.
• Služba API Management není nutná k implementaci vzoru návrhu, ale je možné ji přidat do každé geografické oblasti, která předčítá aplikaci Azure Function App oblasti, aby poskytovala robustnější vrstvu rozhraní API, což například umožňuje implementaci dalších funkcí, jako je omezování rychlosti.

Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:

• Zvolte, jestli chcete zpracovávat data místně v jednotlivých oblastech, nebo distribuovat agregace v jedné geografické oblasti a replikovat výsledek po celém světě. Procesor kanálu změn Azure Cosmos DB nabízí tento podrobný ovládací prvek s využitím konceptu kontejneru zapůjčení a zapůjčeníprefixu v odpovídající vazbě Azure Functions. Každý přístup má odlišné výhody a nevýhody.
• Geodes může pracovat společně s využitím kanálu změn služby Azure Cosmos DB a komunikační platformy v reálném čase, jako je SignalR. Geody můžou komunikovat se vzdálenými uživateli prostřednictvím jiných geografických des ve vzoru sítě, aniž by věděly, kde se vzdálený uživatel nachází, nebo o to, kde se nachází.
• Tento vzor návrhu implicitně odděluje všechno, což vede k vysoce distribuované a oddělené architektuře. Zvažte, jak sledovat různé komponenty stejného požadavku, které se můžou spouštět asynchronně v různých instancích. Důležitá je správná strategie monitorování. Služba Azure Front Door i Azure Cosmos DB je možné snadno integrovat se službou Log Analytics a služba Azure Functions by se měla nasadit společně s aplikačními Přehledy, aby poskytoval robustní monitorovací systém v každé komponentě architektury.
• Distribuovaná nasazení mají větší počet tajných kódů a bodů příchozího přenosu dat, které vyžadují bezpečnostní opatření vlastností. Key Vault poskytuje zabezpečenou vrstvu pro správu tajných kódů a každá vrstva v architektuře rozhraní API by měla být správně zabezpečená, takže jediným bodem příchozího přenosu dat pro rozhraní API je front-endová služba, jako je Azure Front Door. Služba Azure Cosmos DB by měla omezit provoz do aplikací Azure Function Apps a aplikace funkcí do služby Azure Front Door s použitím ID Microsoft Entra nebo postupů, jako je omezení IP adres.
• Výkon je výrazně ovlivněn počtem nasazených geografických hodnot a konkrétními plány služby App Service použitými na technologii rozhraní API v každé geografické oblasti. Nasazení dalších geografických des nebo přesunů do úrovní Premium má vyšší náklady na další paměť a výpočetní prostředky, ale neprovádí to na základě transakcí. Zvažte zátěžové testování architektury rozhraní API po nasazení a kontrastu se zvýšením počtu geografických des a zvýšením cenové úrovně tak, aby se pro vaše potřeby používal nejnákladnější model.
• Určete požadavky na dostupnost vašich dat. Azure Cosmos DB má volitelné příznaky pro povolení zápisu do více oblastí, zón dostupnosti a dalších. Tím se zvýší dostupnost instance Služby Azure Cosmos DB a vytvoří odolnější datovou vrstvu, ale s dalšími náklady.
• Azure nabízí celou řadu nástrojů pro vyrovnávání zatížení, které poskytují různé funkce pro distribuci provozu. Rozhodovací strom vám pomůže vybrat správnou možnost pro front-end vašeho rozhraní API.

Kdy se má tento model použít

Použijte tento model:

• Pokud chcete implementovat vysoce škálovanou platformu, která má uživatele distribuované v široké oblasti.
• Pro všechny služby, které vyžadují extrémní charakteristiky dostupnosti a odolnosti, protože služby založené na vzoru geode mohou přežít ztrátu více oblastí služeb najednou.

Tento vzor nemusí být vhodný pro

• Architektury, které mají omezení, aby se pro úložiště dat nerovnaly všechny geografické dny. Může se například jednat o požadavky na rezidenci dat, aplikaci, která musí udržovat dočasný stav pro konkrétní relaci, nebo náročné zatížení požadavků do jedné oblasti. V takovém případě zvažte použití razítek nasazení v kombinaci s globální rovinou směrování, která je informována o tom, kde se nacházejí data uživatele, například komponenta směrování provozu popsaná ve vzoru kolků nasazení.
• Situace, kdy není potřeba žádné geografické rozdělení. Místo toho zvažte zóny dostupnosti a spárované oblasti pro clustering.
• Situace, kdy je potřeba zpětně namontovat starší platformu. Tento model funguje jenom pro vývoj nativní pro cloud a může být obtížné ho zpětně přizpůsobit.
• Jednoduché architektury a požadavky, kdy geografická redundance a geografická distribuce nejsou povinné ani výhodné.

Návrh úloh

Architekt by měl vyhodnotit způsob použití vzoru Geode v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

Příklady

• Windows Active Directory implementuje ranou variantu tohoto modelu. Replikace s více primárními rolemi znamená, že všechny aktualizace a požadavky se teorii můžou obsluhovat ze všech servisních uzlů, ale role FSMO (Flexible Single Master Operation) znamenají, že všechny geody nejsou stejné.
• Akcelerátor geografického vzoru na GitHubu předvádí tento vzor návrhu v praxi a je navržený tak, aby vývojářům pomohl implementovat ho pomocí skutečných rozhraní API.
• Ukázková aplikace QnA na GitHubu předvádí tento vzor návrhu v praxi.