Vzor Geode

Vzor Geode zahrnuje nasazení kolekce back-end služeb do sady GE ographical n ode s, z nichž každá může obsluhovat jakoukoli žádost pro každého klienta v libovolné oblasti. Tento model umožňuje obsluhovat požadavky ve stylu aktivní-aktivní , což zlepšuje latenci a zvyšuje dostupnost distribucí požadavků po celém světě.

Kontext a problém

Mnohé služby ve velkém rozsahu mají specifické problémy s geografickou dostupností a škálováním. klasické návrhy často přinášejí data do výpočtů tím, že ukládají data na vzdáleném SQL serveru, který slouží jako výpočetní vrstva pro tato data, a spoléhá se na nárůst kapacity.

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

• Problémy latence sítě pro uživatele přicházející z druhé strany zeměkoule k připojení ke koncovému bodu hostování
• Správa provozu pro shluky vyžádaného volání, které můžou zaplavit služby v jedné oblasti
• Náklady – zakazují složitost nasazování kopií aplikační infrastruktury do několika oblastí pro nepřetržitou službu.

Moderní cloudová infrastruktura se vyvinula tak, aby umožňovala geografické vyrovnávání zatížení front-endové služby, a současně umožňuje geografickou replikaci back-end služeb. Pro zajištění dostupnosti a výkonu je lepší získat data blíž k uživateli. Pokud jsou data geograficky distribuována v rámci flung uživatelské základny, měla by být geograficky distribuovaná úložiště také společně umístěná s výpočetními prostředky, které zpracovávají data. Vzor Geode přináší výpočty na data.

Řešení

Nasaďte službu do řady satelitních nasazení po celém světě, z nichž každý se nazývá Geode. Vzor Geode využívá klíčové funkce Azure ke směrování provozu přes nejkratší cestu k okolnímu Geode, což vylepš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í, jako je Azure Cosmos DB k hostování roviny dat, a zajišťuje tak konzistenci dat mezi geode. Služby replikace dat zajišťují, že se úložiště dat shodují napříč geodes, takže všechny požadavky je možné zpracovat ze všech geodes.

Klíčový rozdíl mezi razítkem nasazení a Geode je, že geodes nikdy neexistuje v izolaci. V produkční platformě by měl vždy být více než jeden Geode.

Geodes mají následující vlastnosti:

• Sestává z kolekce různorodých typů prostředků, které jsou často definovány v šabloně.
• Neobsahují žádné závislosti mimo Geode nároky a jsou samostatné. Žádná Geode není závislá na jiném pro provoz, a pokud jedna zemře, ostatní budou i nadále fungovat.
• Jsou volně spojeny přes hraniční síť a plán pro replikaci. můžete například použít Azure Traffic Manager nebo přední dvířka Azure pro frontu geodes, zatímco Azure Cosmos DB mohou fungovat jako znovu naplánované replikace. Geodes se neshodují s clustery, protože sdílejí plán pro replikaci, takže platforma se stará o problémy s kvorem.

vzor geode se vyskytuje v architektuře s velkými objemy dat, které používají komoditní hardware ke zpracování dat umístěných ve stejném počítači, a MapReduce k konsolidaci výsledků napříč počítači. Dalším využitím je téměř hraniční výpočetní výkon, který přináší výpočetní prostředky blíže inteligentnímu hraničnímu okraji sítě, aby se snížila doba odezvy.

Služby můžou tento model používat i v desítkách nebo stovkách geodes. Navíc se odolnost celého řešení zvyšuje s každým přidaným Geode, protože kterýkoli geodes může převzít více, pokud dojde k výpadku jednoho nebo více geodes v případě regionálního výpadku.

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. Tím se zvyšuje složitost, ale je užitečná v případě, že je vaše architektura nepřipojená modulem úložiště, jako je úložiště objektů blob, které se dá replikovat jenom do spárované oblasti. Geodes můžete nasadit do zóny, oblasti nebo regionálního charakteru s ohledem na regulativní omezení nebo omezení latence na místě.

Problémy a důležité informace

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

• moderní postupy DevOps a nástroje pro vytváření a rychlé nasazování identických geodes napříč velkým počtem oblastí nebo instancí.
• Automatické škálování pro horizontální navýšení kapacity výpočetních prostředků a instancí propustnosti databáze v rámci Geode. Každé Geode se v rámci běžných omezení pro základní nastavení škáluje jednotlivě.
• Front-end služba, jako je například přední vrátka Azure, která provádí směrování dynamického obsahu, rozdělení TCP a směrování libovolného vysílání.
• úložiště dat replikace, jako je Azure Cosmos DB k řízení konzistence dat.
• Technologie bez serveru, pokud je to možné, aby se snížily náklady na nasazování, zejména pokud je zatížení často převyvážené po celém světě. Tato strategie umožňuje nasadit mnoho geodes s minimálními nároky na další investice. Technologie pro fakturaci založené na serverech a na základě spotřeby omezují ztráty a náklady z duplicitních geograficky distribuovaných nasazení.
• API Management není nutné implementovat vzor návrhu, ale je možné ho přidat do každého Geode, který předá Azure Function App oblasti, aby poskytoval robustnější vrstvu rozhraní API, což umožňuje implementaci dalších funkcí, jako je například omezení četnosti.

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

• Vyberte, jestli se mají data zpracovávat místně v každé oblasti, nebo pokud chcete distribuovat agregace v jednom Geode a replikovat výsledek po celém světě. procesor Azure Cosmos DB change feed nabízí tento podrobný ovládací prvek s použitím konceptu kontejneru zapůjčení a leasecollectionprefix v odpovídající Azure Functions vazbě. Každý přístup má různé výhody a nevýhody.
• Geodes může pracovat společně s použitím kanálu změny Azure Cosmos DB a komunikační platformy v reálném čase, jako je například signál. Geodes může komunikovat se vzdálenými uživateli přes jiné Geodes v mřížce, aniž by znali nebo caring, kde se nachází vzdálený uživatel.
• Tento vzor návrhu implicitně odděluje vše, což vede k extrémně vysoce vysoké a oddělené architektuře. Vezměte v úvahu, jak sledovat různé komponenty stejné žádosti, které se můžou spouštět asynchronně v různých instancích. Vhodná strategie monitorování je zásadní. přední dveře a Cosmos DB pro Azure je možné snadno integrovat s Log Analytics a Azure Functions by se měly nasadit společně s Application Insights k zajištění robustního monitorovacího systému v každé součásti architektury.
• Distribuovaná nasazení mají větší počet tajných klíčů a vstupní body, které vyžadují míry zabezpečení vlastností. Key Vault poskytuje zabezpečenou vrstvu pro správu tajných kódů a každá vrstva v rámci architektury rozhraní API by měla být správně zabezpečená, aby jediný vstupní bod pro rozhraní API byl front-end služba, jako je třeba přední vrátka Azure. Cosmos DB by měl omezit provoz do aplikací služby azure functions a aplikace function app do Front azure na přední dveře pomocí Azure Active Directory nebo postupů jako omezení IP adres.
• Výkon je drasticke ovlivněn počtem nasazených geodes a konkrétními plány App Service použitými pro technologii rozhraní API v každé Geode. Nasazení dalších geodes nebo přesunu na úrovně Premium přináší zvýšené náklady na další paměť a výpočetní výkon, ale neuděláme je na základě transakcí. Zvažte zátěžové testování architektury rozhraní API po nasazení a kontrastně zvyšte počet geodes s rostoucím cenovou úrovní tak, aby se pro vaše potřeby používal nákladově efektivní model.
• Určete požadavky na dostupnost vašich dat. Cosmos DB obsahuje volitelné příznaky pro povolení zápisu do více oblastí, zón dostupnosti a dalších možností. zvyšují se tím dostupnost instance Cosmos DB a vytváří pružnější datovou vrstvu, ale přináší další náklady.
• Azure nabízí celou řadu nástrojů pro vyrovnávání zatížení, které poskytují různé funkce pro distribuci provozu. Pomocí rozhodovacího stromu můžete vybrat správnou možnost pro front-end rozhraní API.

Kdy se má tento model použít

Použijte tento model:

• K implementaci vysoce škálovatelné platformy, která má uživatele distribuované v rámci rozsáhlé oblasti.
• Pro každou službu, která vyžaduje extrémní dostupnost a charakteristiky odolnosti, protože služby založené na vzorech Geode můžou zamezit ztrátě více oblastí služeb současně.

Tento model nemusí být vhodný pro

• Architektury, které mají omezení, aby všechny geodes nemohly být pro úložiště dat stejné. Mohou být například požadavky na zaregistrování dat, aplikaci, která potřebuje udržovat dočasný stav pro určitou relaci, nebo vysoké váhy 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í, na které se dozvíte, kde jsou umístěna data uživatele, jako je například komponenta směrování provozu, která je popsána ve vzoru razítka nasazení.
• V situacích, kdy není vyžadována geografická distribuce. Místo toho vezměte v úvahu zóny dostupnosti a spárované oblasti pro clustering.
• V situacích, kdy musí být starší verze platformy retrofitted. Tento model funguje jenom pro vývoj v nativním cloudu a může být obtížné ho zpětnému pozměnění.
• Jednoduché architektury a požadavky, kde geografická redundance a geografická distribuce není nutná nebo je výhodná.

Příklady

• Windows Služba Active Directory implementuje počáteční variantu tohoto vzoru. Vícenásobná replikace znamená, že všechny aktualizace a požadavky můžou být teoreticky obsluhovány ze všech uzlů, ale role FSMO (Flexible Single Master Operation) to znamená, že všechny geodes nejsou stejné.
• akcelerátor vzorů geode na GitHub prezentuje tento vzor návrhu v praxi a je navržený tak, aby usnadnil vývojářům implementaci rozhraní api reálného světa.
• globálně distribuované aplikace využívající Cosmos DB článku prozkoumají geografické nasazení, které využívá Traffic Manager k vyrovnávání zatížení a Azure App Service k hostování kódu rozhraní API.
• ukázková aplikace QnA na GitHub prezentuje tento vzor návrhu v praxi.
• Geode Cache přes SAP OData api: ukázka rozhraní OData api Geode nastavené na základě Cosmos jako globálně akcelerovaná mezipaměť dat pro maloobchodní aplikace SAP.