Geode-mönster

Geode-mönstret omfattar distribution av en samling backend-tjänster till en uppsättning geographicn-ode:er,som var och en kan tillhandahålla alla förfrågningar för alla klienter i vilken region som helst. Det här mönstret gör att begäranden kan betjänas i aktiv-aktiv-stil, vilket förbättrar svarstiden och ökar 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 ge ett antal utmaningar:

• Problem med nätverksfördröjning för användare som kommer från andra sidan av världen för att ansluta till värdslutpunkten
• Trafikhantering för efterfrågan 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

Modern molninfrastruktur har utvecklats för att möjliggöra geografisk belastningsutjämning för frontend-tjänster, samtidigt som den möjliggör geografisk replikering av backend-tjänster. För tillgänglighet och prestanda är det bra att komma data närmare användaren. När data geo-distribueras över en mycket utspridd användarbas bör de geo-distribuerade datalageren också samplaceras med de beräkningsresurser som bearbetar data. Geodemönstret hämtar beräkningen till data.

Lösning

Distribuera tjänsten till ett antal satellitdistributioner över hela världen, som var och en kallas för en geode. Geodemö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 geodelade data. Datareplikeringstjänster säkerställer att datalager är identiska mellan geodes, så att alla begäranden kan betjänas från alla geodes.

Den största skillnaden mellan en distributionsstämpel och en geode är att geodes aldrig finns isolerat. Det bör alltid finnas fler än en geode i en produktionsplattform.

Geodes har följande egenskaper:

• Består av en samling olika typer av resurser, som ofta definieras i en mall.
• Ha inga beroenden utanför geodeavtrycket och är fristående. Ingen geode är beroende av en annan för att fungera, och om den ena gör det fortsätter de andra att fungera.
• Är löst kopplade via ett gränsnätverk och ett bakåtplan för replikering. Du kan till exempel använda Azure Traffic Manager eller Azure Front Door för att fronta geoderna, Azure Cosmos DB kan fungera som replikeringens bakplan. Geodes är inte samma som kluster eftersom de delar ett backplan för replikering, så plattformen tar hand om kvorumproblem.

Geodemönstret förekommer i stordataarkitekturer som använder maskinvara för att bearbeta data som samplaceras 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 den intelligenta nätverkskanten för att minska svarstiden.

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

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

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 geodes över ett stort antal regioner eller instanser.
• Automatisk skalning för att skala ut beräknings- och databasdataflödesinstanser inom en geode. Varje geode skalas ut individuellt inom de vanliga begränsningar som gäller för bakplan.
• En frontend-tjänst som Azure Front Door som acceleration av dynamiskt innehåll, delad TCP och Anycast-routning.
• Ett replikerande datalager, till exempel Azure Cosmos DB för att kontrollera datakonsekvens.
• Serverlös teknik 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 geod:er distribueras med minimala ytterligare investeringar. Teknik för serverlös och förbrukningsbaserad fakturering minskar slöseri och kostnader från duplicerade geo-distribuerade distributioner.
• API Management krävs inte för att implementera designmönstret, men kan läggas till i varje geode som ligger framför 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 distribuera sammansättningar i en enda geode och replikera resultatet över hela världen. Den Azure Cosmos DB ändringsflödesprocessorn erbjuder den här detaljerade kontrollen med hjälp av begreppet lånecontainer och leasecollectionprefix i motsvarande Azure Functions bindning. Varje metod har distinkta fördelar och nackdelar.
• Geodes kan fungera tillsammans med hjälp Azure Cosmos DB en ändringsflöde och en kommunikationsplattform i realtid som SignalR. Geodes kan kommunicera med fjärranvändare via andra geodes i ett nätmönster, utan att känna till eller bry sig om var fjärranvändaren finns.
• Det här designmönstret frikopplar implicit allt, vilket resulterar i en mycket distribuerad och fristående arkitektur. Överväg hur du spårar olika komponenter i samma begäran eftersom de kan köras asynkront på olika instanser. En korrekt övervakningsstrategi är avgörande. Både Azure Front Door och Cosmos DB enkelt kan 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 ger ett säkert lager för hemlighetshantering och varje lager i API-arkitekturen bör skyddas korrekt så att den enda ingresspunkten för API:et är frontend-tjänsten som Azure Front Door. Den Cosmos DB trafik till Azure-funktionsapparna och funktionsapparna till att Azure Front Door med Azure Active Directory eller metoder som IP-begränsning.
• Prestanda påverkas drastiskt av antalet geodes som distribueras och de specifika App Service-planer som tillämpas på API-tekniken i varje geode. Distribution av ytterligare geodes eller förflyttning mot premiumnivåer ger ökade kostnader för ytterligare minne och beräkning, men gör inte det per transaktion. Överväg att belastningstesta API-arkitekturen när den har distribuerats och kontrastera hur du ökar antalet geodes 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. Cosmos DB har valfria flaggor för att aktivera skrivningar i flera regioner, tillgänglighetszoner med mera. Dessa ökar tillgängligheten för 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 frontend.

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

Använd det här mönstret:

• Implementera en plattform i hög skala som har användare distribuerade över ett brett område.
• För alla tjänster som kräver extrema egenskaper för tillgänglighet och återhämtning, eftersom tjänster som baseras på geode-mönstret kan överleva förlusten av flera tjänstregioner samtidigt.

Det här mönstret kanske inte är lämpligt för

• Arkitekturer som har begränsningar så att alla geodes inte kan vara lika med för datalagring. Det kan till exempel finnas krav på datahemlighet, ett program som behöver upprätthålla ett tillfälligt tillstånd för en viss session eller en tung viktning av begäranden till 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 medveten om var en användares data finns, till exempel den komponent för trafikdirigering som beskrivs i distributionsstämpelmönstret.
• Situationer där det inte krävs någon geografisk distribution. Överväg i stället tillgänglighetszoner och parkopplade 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 efteranpassa.
• Enkla arkitekturer och krav, där geo-redundans och geo-distribution inte krävs eller är fördelaktigt.

Exempel

• Windows Active Directory implementerar en tidig variant av det här mönstret. Replikering med flera primära resurser innebär att alla uppdateringar och begäranden i teorin kan betjänas från alla tjänstbara noder, men FSMO-rollerna (Flexible Single Master Operation) innebär att alla geode:er inte är lika.
• Geode-mönsteracceleratorn på GitHub demonstrerar det här designmönstret i praktiken och är utformat för att hjälpa utvecklare att implementera det med verkliga API:er.
• Artikeln globalt distribuerade program med Cosmos DB undersöker en geografisk baserad distribution som använder Traffic Manager för belastningsutjämning och Azure App Service som värd för API-koden.
• Ett QnA-exempelprogram på GitHub demonstrerar det här designmönstret i praktiken.
• Geode-cache över SAP OData-API:er:En OData API Geode-exempeluppsättning som backas upp av Cosmos som en globalt accelererad datacache för SAP Retail-program.