Geode-mönster

Geode-mönstret omfattar distribution av en samling serverdelstjänster till en uppsättning geographical nodes, som var och en kan hantera alla förfrågningar för alla klienter i alla regioner. Det här mönstret gör det möjligt att hantera begäranden i aktiv-aktiv stil, förbättra svarstiden och öka tillgängligheten genom att distribuera bearbetning av begäranden över hela världen.

Kontext och problem

Många storskaliga tjänster har specifika utmaningar när det gäller geo-tillgänglighet och skalning. Klassiska designer tar ofta data till beräkningen genom att lagra data på en fjärransluten SQL-server som fungerar som beräkningsnivå för dessa data och förlitar sig på uppskalning för tillväxt.

Den klassiska metoden kan innebära ett antal utmaningar:

• Problem med nätverksfördröjning för användare som kommer från andra sidan jordklotet för att ansluta till värdslutpunkten
• Trafikhantering för efterfrågetoppar som kan överbelasta tjänsterna i en enda region
• Kostnadsöverkomlig komplexitet vid distribution av kopior av appinfrastruktur till flera regioner för en 24x7-tjänst

Den moderna molninfrastrukturen har utvecklats för att möjliggöra geografisk belastningsutjämning av klientdelstjänster, samtidigt som geografisk replikering av serverdelstjänster möjliggörs. För tillgänglighet och prestanda är det bra att få data närmare användaren. När data är geo-distribuerade över en avlägsen användarbas bör de geo-distribuerade datalager också samlokaleras med beräkningsresurserna som bearbetar data. Geode-mönstret för data till data.

Lösning

Distribuera tjänsten till ett antal satellitdistributioner spridda över hela världen, som var och en kallas geode. Geode-mönstret utnyttjar viktiga funktioner i Azure för att dirigera trafik via den kortaste vägen till en närliggande geode, vilket förbättrar svarstiden och prestandan. Varje geode ligger bakom en global lastbalanserare och använder en geo-replikerad läs- och skrivtjänst som Azure Cosmos DB som värd för dataplanet, vilket säkerställer datakonsekvens mellan geod. Datareplikeringstjänster ser till att datalager är identiska mellan geoder, så att alla begäranden kan hanteras från alla geoder.

Den viktigaste skillnaden mellan en distributionsstämpel och en geode är att geoder aldrig finns isolerat. Det bör alltid finnas mer än en geode i en produktionsplattform.

Geoder har följande egenskaper:

• Består av en samling olika typer av resurser, som ofta definieras i en mall.
• Ha inga beroenden utanför geode-fotavtrycket och är självständiga. Ingen geode är beroende av en annan för att fungera, och om en dör fortsätter de andra att fungera.
• Är löst kopplade via ett gränsnätverk och replikeringsbakplan. Du kan till exempel använda Azure Traffic Manager eller Azure Front Door för att fronta geoderna, medan Azure Cosmos DB kan fungera som replikeringsbakplan. Geodes är inte samma som kluster eftersom de delar en replikerings backplan, så plattformen tar hand om kvorumproblem.

Geode-mönstret förekommer i stordataarkitekturer som använder vanlig maskinvara för att bearbeta data som samlokaliserats på samma dator och MapReduce för att konsolidera resultat mellan datorer. En annan användning är beräkning nära gränsen, vilket för beräkning närmare nätverkets intelligenta kant för att minska svarstiden.

Tjänster kan använda det här mönstret över dussintals eller hundratals geoder. Dessutom ökar motståndskraften för hela lösningen med varje tillagd geode, eftersom alla geoder kan ta över om ett regionalt avbrott tar en eller flera geoder offline.

Det är också möjligt att utöka lokala tillgänglighetstekniker, till exempel tillgänglighetszoner eller kopplade regioner, med geode-mönstret för global tillgänglighet. Detta ökar komplexiteten, men är användbart om arkitekturen stöds av en lagringsmotor, till exempel bloblagring som bara kan replikeras till en länkad region. Du kan distribuera geoder till ett zonindelat eller regionalt fotavtryck inom zonen, med tanke på regel- eller svarstidsbegränsningar på plats.

Problem och överväganden

Använd följande tekniker och tekniker för att implementera det här mönstret:

• Moderna DevOps-metoder och verktyg för att skapa och snabbt distribuera identiska geoder i ett stort antal regioner eller instanser.
• Autoskalning för att skala ut beräknings- och databasdataflödesinstanser i en geode. Varje geode skalas ut individuellt, inom de gemensamma begränsningarna för backplan.
• En klientdelstjänst som Azure Front Door som utför dynamisk innehållsacceleration, delad TCP och Anycast-routning.
• Ett replikeringsdatalager som Azure Cosmos DB för att kontrollera datakonsekvens.
• Serverlösa tekniker där det är möjligt, för att minska kostnaden för always-on-distribution, särskilt när belastningen ofta balanseras om över hela världen. Med den här strategin kan många geoder distribueras med minimala ytterligare investeringar. Serverlösa och förbrukningsbaserade faktureringstekniker minskar slöseri och kostnader från dubbletter av geo-distribuerade distributioner.
• API Management krävs inte för att implementera designmönstret, men kan läggas till i varje geode som frontar regionens Azure-funktionsapp för att tillhandahålla ett mer robust API-lager, vilket möjliggör implementering av ytterligare funktioner som hastighetsbegränsning, till exempel.

Tänk på följande när du bestämmer hur du ska implementera mönstret:

• Välj om du vill bearbeta data lokalt i varje region eller om du vill distribuera aggregeringar i en enda geode och replikera resultatet över hela världen. Azure Cosmos DB-ändringsflödesprocessorn erbjuder den här detaljerade kontrollen med hjälp av dess lånecontainerkoncept och leasecollectionprefix i motsvarande Azure Functions-bindning. Varje metod har distinkta fördelar och nackdelar.
• Geodes kan fungera tillsammans med hjälp av Azure Cosmos DB-ändringsflödet och en kommunikationsplattform i realtid som SignalR. Geodes kan kommunicera med fjärranvändare via andra geoder i ett nätmönster, utan att veta eller bry sig om var fjärranvändaren finns.
• Det här designmönstret frikopplar implicit allt, vilket resulterar i en ultrahögt distribuerad och frikopplad arkitektur. Fundera på hur du spårar olika komponenter i samma begäran som de kan köra asynkront på olika instanser. En lämplig övervakningsstrategi är avgörande. Både Azure Front Door och Azure Cosmos DB kan enkelt integreras med Log Analytics och Azure Functions bör distribueras tillsammans med Application Insights för att tillhandahålla ett robust övervakningssystem för varje komponent i arkitekturen.
• Distribuerade distributioner har ett större antal hemligheter och ingresspunkter som kräver egenskapssäkerhetsåtgärder. Key Vault tillhandahåller ett säkert lager för hantering av hemligheter och varje lager i API-arkitekturen bör skyddas korrekt så att den enda ingresspunkten för API:et är klientdelstjänsten som Azure Front Door. Azure Cosmos DB bör begränsa trafiken till Azure Function Apps och funktionsapparna till Azure Front Door med hjälp av Microsoft Entra-ID eller metoder som IP-begränsning.
• Prestanda påverkas drastiskt av antalet geoder som distribueras och de specifika App Service-planer som tillämpas på API-tekniken i varje geode. Distribution av ytterligare geoder eller förflyttning till premiumnivåer medför ökade kostnader för extra minne och beräkning, men gör det inte per transaktion. Överväg att belastningstesta API-arkitekturen när den har distribuerats och kontrastera att öka antalet geoder med att öka prisnivån så att den mest kostnadseffektiva modellen används för dina behov.
• Fastställa tillgänglighetskraven för dina data. Azure Cosmos DB har valfria flaggor för att aktivera skrivning i flera regioner, tillgänglighetszoner med mera. Dessa ökar tillgängligheten för Azure Cosmos DB-instansen och skapar ett mer motståndskraftigt datalager, men medför ytterligare kostnader.
• Azure erbjuder en mängd olika lastbalanserare som tillhandahåller olika funktioner för distribution av trafik. Använd beslutsträdet för att välja rätt alternativ för API:ets klientdel.

När du ska använda det här mönstret

Använd det här mönstret:

• Så här implementerar du en storskalig plattform som har användare distribuerade över ett stort område.
• För alla tjänster som kräver extrema tillgänglighets- och motståndskraftsegenskaper, eftersom tjänster baserade på geode-mönstret kan överleva förlusten av flera tjänstregioner samtidigt.

Det här mönstret kanske inte lämpar sig för

• Arkitekturer som har begränsningar så att alla geoder inte kan vara lika med datalagring. Det kan till exempel finnas krav på datahemvist, ett program som behöver behålla tillfälligt tillstånd för en viss session eller en tung viktning av begäranden mot en enda region. I det här fallet bör du överväga att använda distributionsstämplar i kombination med ett globalt routningsplan som är medvetet om var en användares data finns, till exempel den trafikroutningskomponent som beskrivs i mönstret för distributionsstämplar.
• Situationer där det inte krävs någon geografisk fördelning. Överväg i stället tillgänglighetszoner och länkade regioner för klustring.
• Situationer där en äldre plattform måste eftermonteras. Det här mönstret fungerar endast för molnbaserad utveckling och kan vara svårt att eftermontera.
• Enkla arkitekturer och krav, där geo-redundans och geo-distribution inte krävs eller är fördelaktiga.

Design av arbetsbelastning

En arkitekt bör utvärdera hur Geode-mönstret kan användas i arbetsbelastningens design för att uppfylla de mål och principer som beskrivs i grundpelarna i Azure Well-Architected Framework. Till exempel:

Som med alla designbeslut bör du överväga eventuella kompromisser mot målen för de andra pelarna som kan införas med det här mönstret.

Exempel

• Windows Active Directory implementerar en tidig variant av det här mönstret. Multi-primary-replikering innebär att alla uppdateringar och begäranden i teorin kan hanteras från alla servicebara noder, men FSMO-roller (Flexible Single Master Operation) innebär att alla geoder inte är lika.
• Geode-mönsteracceleratorn på GitHub visar det här designmönstret i praktiken och är utformat för att hjälpa utvecklare att implementera det med verkliga API:er.
• Ett QnA-exempelprogram på GitHub visar det här designmönstret i praktiken.