Mönster för distributionsstämplar

Artikel
12/09/2021
11 minuter för att läsa

Distributionsstämpelmönstret omfattar etablering, hantering och övervakning av en heterogen grupp med resurser som ska vara värd för och driva flera arbetsbelastningar eller klienter. Varje enskild kopia kallas för en stämpel,eller ibland en tjänstenhet ellerskalningsenhet. I en miljö med flera innehavare kan varje stämpel eller skalningsenhet betjäna ett fördefinierat antal klienter. Flera stämplar kan distribueras för att skala lösningen nästan linjärt och hantera ett ökande antal klienter. Den här metoden kan förbättra lösningens skalbarhet, göra det möjligt att distribuera instanser över flera regioner och separera dina kunddata.

Kontext och problem

När du är värd för ett program i molnet finns det vissa saker att tänka på. En viktig sak att tänka på är programmets prestanda och tillförlitlighet. Om du är värd för en enda instans av din lösning kan du omfattas av följande begränsningar:

Skalningsgränser. Om du distribuerar en enda instans av ditt program kan det resultera i naturliga skalningsgränser. Du kan till exempel använda tjänster som har begränsningar för antalet inkommande anslutningar, värdnamn, TCP-sockets eller andra resurser.
Icke-linjär skalning eller kostnad. Vissa av lösningens komponenter kanske inte skalas linjärt med antalet begäranden eller mängden data. I stället kan det ske en plötslig minskning av prestanda eller ökade kostnader när ett tröskelvärde har uppnåtts. Du kan till exempel använda en databas och upptäcka att marginalkostnaden för att lägga till mer kapacitet (skala upp) blir för hög och att utskalning är en mer kostnadseffektiv strategi. På samma Azure Front Door har högre priser per domän när ett stort antal anpassade domäner distribueras, och det kan vara bättre att sprida de anpassade domänerna över flera Front Door instanser.
Uppdelning av kunder. Du kan behöva hålla vissa kunders data isolerade från andra kunders data. På samma sätt kan du ha vissa kunder som behöver mer systemresurser för att hjälpa till än andra och överväga att gruppera dem i olika uppsättningar av infrastruktur.
Hantering av instanser med en eller flera innehavare. Du kan ha några stora kunder som behöver sina egna oberoende instanser av din lösning. Du kan också ha en pool med mindre kunder som kan dela en distribution för flera innehavare.
Komplexa distributionskrav. Du kan behöva distribuera uppdateringar till din tjänst på ett kontrollerat sätt och distribuera till olika delmängder av kundbasen vid olika tidpunkter.
Uppdateringsfrekvens. Du kan ha vissa kunder som är toleranta för att ha frekventa uppdateringar av systemet, medan andra kan vara riskbenägna och vill ha ovanliga uppdateringar av systemet som tillhandahåller sina förfrågningar. Det kan vara klokt att distribuera dessa kunder till isolerade miljöer.
Geografiska eller geopolitiska begränsningar. För att skapa för låg latens eller för att uppfylla kraven på datasuveränitet kan du distribuera några av dina kunder till specifika regioner.

Lösning

För att undvika dessa problem kan du gruppera resurser i skalningsenheter och etablera flera kopior av dina stämplar. Varje skalningsenhet kommer att vara värd för och betjäna en delmängd av dina klienter. Stämplar fungerar oberoende av varandra och kan distribueras och uppdateras oberoende av varandra. En enda geografisk region kan innehålla en enda stämpel eller innehålla flera stämplar för horisontell utskalning i regionen. Stämplar innehåller en delmängd av dina kunder.

En exempeluppsättning med distributionsstämplar

Distributionsstämplar kan tillämpas oavsett om din lösning använder IaaS-komponenter (infrastruktur som en tjänst) eller PaaS-komponenter (plattform som en tjänst) eller en blandning av båda. Normalt kräver IaaS-arbetsbelastningar större åtgärder för skalning, så mönstret kan vara användbart för IaaS-tunga arbetsbelastningar för att möjliggöra utskalning.

Stämplar kan användas för att implementera distributionsringar. Om olika kunder vill ta emot tjänstuppdateringar med olika frekvenser kan de grupperas på olika stämplar, och varje stämpel kan ha uppdateringar distribuerade i olika takt.

Eftersom stämplar körs oberoende av varandra partitioneras data implicit. Dessutom kan en enskild stämpel använda ytterligare horisontell partitionering för att internt möjliggöra skalbarhet och elasticitet i stämpeln.

Distributionsstämpelmönstret används internt av många Azure-tjänster, inklusive App Service, Azure Stackoch Azure Storage.

Distributionsstämplar är relaterade till, men skiljer sig från, geodes. I en distributionsstämpelarkitektur distribueras flera oberoende instanser av systemet och innehåller en delmängd av dina kunder och användare. I geodes kan alla instanser betjäna begäranden från alla användare, men den här arkitekturen är ofta mer komplex för att utforma och skapa. Du kan också överväga att blanda de två mönstren i en lösning: trafikroutningsmetod som beskrivs nedan är ett exempel på ett sådant hybridscenario.

Distribution

På grund av komplexiteten i distributionen av identiska kopior av samma komponenter är bra DevOps-metoder avgörande för att säkerställa framgång när du implementerar det här mönstret. Överväg att beskriva infrastrukturen som kod, till exempel genom att använda Bicep,JSON Azure Resource Manager (ARM-mallar), Terraformoch skript. Med den här metoden kan du se till att distributionen av varje stämpel är förutsägbar och repeterbar. Det minskar också sannolikheten för mänskliga fel, till exempel oavsiktliga matchningsfel i konfigurationen mellan stämplar.

Du kan distribuera uppdateringar automatiskt till alla stämplar parallellt. I så fall kan du överväga tekniker som Bicep eller Resource Manager-mallar för att samordna distributionen av din infrastruktur och dina program. Alternativt kan du välja att gradvis distribuera uppdateringar till vissa stämplar först och sedan progressivt till andra. Överväg att använda ett versionshanteringsverktyg som Azure Pipelines eller GitHub Actions för att dirigera distributioner till varje stämpel. Mer information finns i:

Överväg noga topologin för Azure-prenumerationer och resursgrupper för dina distributioner:

Vanligtvis innehåller en prenumeration alla resurser för en enda lösning, så i allmänhet bör du överväga att använda en enda prenumeration för alla stämplar. Men vissa Azure-tjänster inför prenumerationsomfattandekvoter, så om du använder det här mönstret för att möjliggöra en hög grad av utskalning kan du behöva överväga att distribuera stämplar över olika prenumerationer.
Resursgrupper används vanligtvis för att distribuera komponenter med samma livscykel. Om du planerar att distribuera uppdateringar till alla dina stämplar samtidigt bör du överväga att använda en enda resursgrupp som innehåller alla komponenter för alla dina stämplar och använda namngivningskonventioner och taggar för resurser för att identifiera de komponenter som tillhör varje stämpel. Alternativt, om du planerar att distribuera uppdateringar till varje stämpel separat, bör du överväga att distribuera varje stämpel till en egen resursgrupp.

Kapacitetsplanering

Använd belastnings- och prestandatestning för att fastställa den ungefärliga belastning som en viss stämpel kan hantera. Belastningsmått kan baseras på antalet kunder/klienter som en enskild stämpel kan hantera, eller mått från de tjänster som komponenterna i stämpeln märk med. Se till att du har tillräcklig instrumentation för att mäta när en viss stämpel närmar sig sin kapacitet och möjligheten att snabbt distribuera nya stämplar för att svara på efterfrågan.

Trafikroutning

Distributionsstämpelmönstret fungerar bra om varje stämpel hanteras oberoende av varandra. Om Contoso till exempel distribuerar samma API-program över flera stämplar kan de överväga att använda DNS för att dirigera trafik till relevant stämpel:

unit1.aus.myapi.contoso.com dirigerar trafik till stämpel unit1 inom en australiensisk region.
unit2.aus.myapi.contoso.com dirigerar trafik till stämpel unit2 inom en australiensisk region.
unit1.eu.myapi.contoso.com dirigerar trafik till unit1 stämpel inom en europeisk region.

Klienterna ansvarar sedan för att ansluta till rätt stämpel.

Om en enda ingresspunkt för all trafik krävs kan en trafikdirigeringstjänst användas för att matcha stämpeln för en viss begäran, kund eller klientorganisation. Trafikroutningstjänsten dirigerar antingen klienten till relevant URL för stämpeln (till exempel med hjälp av en HTTP 302-svarsstatuskod), eller kan fungera som en omvänd proxy och vidarebefordra trafiken till relevant stämpel utan att klienten är medveten om det.

En centraliserad trafikroutningstjänst kan vara en komplex komponent att utforma, särskilt när en lösning körs i flera regioner. Överväg att distribuera trafikroutningstjänsten i flera regioner (eventuellt alla regioner som stämplarna distribueras till) och se till att datalagret (mappa klienter till stämplar) synkroniseras. Trafikroutningskomponenten kan själv ha en instans av geodemönstret.

Till exempel kan Azure API Management distribueras för att agera i tjänstrollen för trafikdirigering. Den kan fastställa lämplig stämpel för en begäran genom att söka efter data i en Cosmos DB samling som lagrar mappningen mellan klienter och stämplar. API Management kan sedan dynamiskt ange backend-URL:en till API-tjänsten för den relevanta stämpeln.

Om du vill aktivera geo-distribution av begäranden och georedundans för trafikroutningstjänsten kan API Managementdistribueras över flera regioner, eller så kan Azure Front Door användas för att dirigera trafik till den närmaste instansen. Front Door kan konfigureras med en backend-pool,så att begäranden kan dirigeras till närmaste tillgängliga API Management instans. Om ditt program inte exponeras via HTTP/S kan du använda en Azure Load Balancer för att distribuera inkommande anrop till regionala Azure Load Balancers. Den globala distributionsfunktionen i Azure Cosmos DB kan användas för att hålla mappningsinformationen uppdaterad i varje region.

Exempel på arkitektur för trafikroutning

Om en trafikroutningstjänst ingår i din lösning bör du överväga om den fungerar som en gateway och därför kan utföra gateway-avlastning för tjänster som tokenvalidering, begränsning och auktorisering.

Problem och överväganden

När du bestämmer hur det här mönstret ska implementeras bör du överväga följande punkter:

Distributionsprocess. När du distribuerar flera stämplar rekommenderar vi att du har automatiserade och fullständigt upprepningsbara distributionsprocesser. Överväg att använda Bicep-,JSON ARM-mallareller Terraform-moduler för att deklarativt definiera stämpeln.
Korsstämpelåtgärder. När din lösning distribueras oberoende av varandra över flera stämplar kan frågor som "hur många kunder har vi i alla våra stämplar?" bli mer komplexa att besvara. Frågor kan behöva köras mot varje stämpel och aggregerade resultat. Du kan också överväga att alla stämplar publicerar data i ett centraliserat informationslager för konsoliderad rapportering.
Fastställa utskalningsprinciper. Stämplar har en begränsad kapacitet, som kan definieras med hjälp av ett proxymått, till exempel antalet klienter som kan distribueras till stämpeln. Det är viktigt att övervaka den tillgängliga kapaciteten och den kapacitet som används för varje stämpel och att proaktivt distribuera ytterligare stämplar så att nya klienter kan dirigeras till dem.
Kostnad. Distributionsstämpelmönstret omfattar distribution av flera kopior av infrastrukturkomponenten, vilket sannolikt innebär en betydande ökning av kostnaden för att driva din lösning.
Flytta mellan stämplar. Eftersom varje stämpel distribueras och drivs oberoende av varandra kan det vara svårt att flytta klienter mellan stämplar. Ditt program behöver anpassad logik för att överföra information om en viss kund till en annan stämpel och sedan ta bort klientorganisationens information från den ursprungliga stämpeln. Den här processen kan kräva ett bakplan för kommunikation mellan stämplar, vilket ytterligare ökar komplexiteten i den övergripande lösningen.
Trafikroutning. Som det beskrivs ovan kan dirigering av trafik till rätt stämpel för en viss begäran kräva ytterligare en komponent för att matcha klienter till stämplar. Den här komponenten kan i sin tur behöva göras mycket tillgänglig.
Delade komponenter. Du kan ha vissa komponenter som kan delas mellan stämplar. Om du till exempel har en delad ensidesapp för alla klienter bör du överväga att distribuera den till en region och använda Azure CDN för att replikera den globalt.

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

Det här mönstret är användbart när du har:

Naturliga gränser för skalbarhet. Om vissa komponenter till exempel inte kan eller inte ska skalas utanför ett visst antal kunder eller begäranden bör du överväga att skala ut med hjälp av stämplar.
Ett krav på att separera vissa klienter från andra. Om du har kunder som inte kan distribueras till en stämpel för flera innehavare med andra kunder av säkerhetsskäl kan de distribueras till sin egen isolerade stämpel.
Du måste ha vissa klienter på olika versioner av din lösning samtidigt.
Program i flera regioner där varje klientorganisations data och trafik ska dirigeras till en specifik region.
En vilja att uppnå återhämtning under avbrott. Eftersom stämplar är oberoende av varandra bör inte klienter som distribueras till andra stämplar påverkas om ett avbrott påverkar en enskild stämpel. Den här isoleringen hjälper till att begränsa "radien" för en incident eller ett avbrott.

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

Enkla lösningar som inte behöver skalas i hög grad.
System som enkelt kan skalas ut eller upp inom en enda instans, till exempel genom att öka storleken på programlagret eller genom att öka den reserverade kapaciteten för databaser och lagringsnivån.
Lösningar där data ska replikeras över alla distribuerade instanser. Överväg geode-mönstret för det här scenariot.
Lösningar där endast vissa komponenter behöver skalas, men inte andra. Överväg till exempel om din lösning kan skalas genom horisontell partitionering av datalagret i stället för att distribuera en ny kopia av alla lösningskomponenter.
Lösningar som endast består av statiskt innehåll, till exempel ett JavaScript-program på frontend-sidan. Överväg att lagra sådant innehåll i ett lagringskonto och använda Azure CDN.

Stödteknik

Infrastruktur som kod. Till exempel Bicep, Resource Manager, Azure CLI, Terraform, PowerShell, Bash.
Azure Front Door, som kan dirigera trafik till en specifik stämpel eller till en trafikdirigeringstjänst.

Exempel

I följande exempel distribueras flera stämplar av en enkel PaaS-lösning med en apptjänst och en SQL Database i varje stämpel. Även om stämplar kan konfigureras i vilken region som helst som stöder de tjänster som distribueras i mallen, distribuerar den här mallen två stämplar i regionen USA, västra 2 och en ytterligare stämpel i regionen Europa, västra. Inom en stämpel tar App Service emot sitt eget offentliga DNS-värdnamn och kan ta emot anslutningar oberoende av alla andra stämplar.

Varning

I exemplet nedan används ett SQL Server administratörskonto. Det är vanligtvis inte en bra idé att använda ett administratörskonto från ditt program. För ett verkligt program kan du överväga att använda en hanterad identitet för att ansluta från ditt program till en SQL-databaseller använda ett konto med minsta behörighet.

Klicka på länken nedan för att distribuera lösningen.

Anteckning

Det finns alternativa metoder för att distribuera stämplar med en Resource Manager-mall, inklusive att använda kapslade mallar eller länkade mallar för att frikoppla definitionen av varje stämpel från iterationen som krävs för att distribuera flera kopior.

Exempel på trafikroutningsmetod

I följande exempel distribueras en implementering av en trafikroutningslösning som kan användas med en uppsättning distributionsstämplar för ett hypotetiskt API-program. För att möjliggöra geografisk distribution av inkommande Front Door distribueras tillsammans med flera instanser API Management på förbrukningsnivån. Varje API Management-instans läser klient-ID:t från begärande-URL:en och söker sedan upp relevant stämpel för begäran från ett geo-distribuerat Cosmos DB datalager. Begäran vidarebefordras sedan till relevant backend-stämpel.