Mönster för distributionsstämplar

Mönstret för Deployment Stamps tillhandahåller, hanterar och övervakar en grupp resurser för att hantera och driva flera arbetsbelastningar eller klienter. Varje enskild kopia kallas för en stämpel, eller ibland en tjänstenhet, skalningsenhet eller cell. I en miljö med flera hyresgäster betjänar varje enhet ett fördefinierat antal hyresgäster. Du distribuerar flera stämplar för att skala lösningen nästan linjärt och hantera ett ökande antal klienter. Den här metoden kan förbättra skalbarheten för din lösning, göra det möjligt för dig att distribuera instanser i flera regioner och separera dina kunddata.

Kontext och problem

När du är värd för ett program i molnet bör du tänka på programmets prestanda och tillförlitlighet. Om du är värd för en enda instans av din lösning kan följande begränsningar gälla:

• Skalningsgränser: En enda instans av ditt program kan nå naturliga skalningsgränser. De tjänster som du använder kan till exempel begränsa antalet inkommande anslutningar, värdnamn, TCP-socketar (Transmission Control Protocol) 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 prestandan sjunka eller kostnaden öka när du har nått ett tröskelvärde. Du kan till exempel upptäcka att det blir oöverkomligt dyrt att lägga till mer kapacitet i en databas eller skala upp och att utskalning är mer kostnadseffektivt.

• Uppdelning av kunder: Du kan behöva isolera en kunds data från en annan kunds data. Du kan också ha kunder som förbrukar mer systemresurser än andra. Du kan gruppera dem på olika infrastrukturuppsättningar.

• Instanser med en klientorganisation och flera klienter: Vissa stora kunder kan behöva sina egna oberoende instanser av din lösning. Mindre kunder kan dela en implementering med flera klienter.

• Komplexa distributionskrav: Du kan behöva distribuera uppdateringar till tjänsten på ett kontrollerat sätt och distribuera till olika delmängder av kundbasen vid olika tidpunkter.

• Uppdateringsfrekvens: Vissa kunder tolererar frekventa uppdateringar, medan riskvilliga kunder vill ha ovanliga uppdateringar av systemet som hanterar deras begäranden. Du kan distribuera dessa kunder till isolerade miljöer.

• Geografiska eller geopolitiska begränsningar: För att uppnå låg svarstid eller uppfylla kraven på datasuveränitet kan du distribuera vissa kunder till specifika regioner.

Dessa begränsningar gäller ofta för programvaruutvecklingsföretag som skapar programvara som en tjänst (SaaS), som de vanligtvis utformar som multitenant. Samma begränsningar kan också gälla för andra scenarier.

Lösning

Du kan undvika dessa problem genom att gruppera resurser i skalningsenheter och etablera flera kopior av dina stämplar. Varje skalningsmodul är värd för och hanterar en delmängd av dina hyresgäster. Stämplar körs oberoende av varandra och du kan distribuera och uppdatera dem separat. En enda geografisk region kan innehålla en stämpel eller flera stämplar som skalas ut horisontellt inom regionen. Varje stämpel tjänar en delmängd av dina kunder.

Distributionsstämplar kan gälla om din lösning använder infrastruktur som en tjänst (IaaS) eller PaaS-komponenter (plattform som en tjänst) eller en kombination av båda. IaaS-arbetsbelastningar kräver vanligtvis mer åtgärder för att skala, så det här mönstret kan hjälpa IaaS-tunga arbetsbelastningar att skala ut.

Du kan använda stämplar för att implementera distributionsringar. Om olika kunder vill ha tjänstuppdateringar med olika frekvenser grupperar du dem på olika stämplar och distribuerar uppdateringar till varje stämpel i olika takt.

Stämplar körs oberoende av varandra, så de fragmentera dina data implicit. En enskild stämpel kan också använda ytterligare sharding internt för att skala och förbli anpassningsbar.

Att distribuera identiska kopior av samma komponenter är komplext, så bra DevOps-metoder är viktiga. Beskriv infrastrukturen som kod så att distributionen av varje stämpel är förutsägbar och repeterbar.

Distributionsstämplar är relaterade till men skiljer sig från geoder. I en distributionsstämpelarkitektur hanterar varje oberoende instans av systemet en delmängd av dina kunder och användare. I en geode-arkitektur kan varje instans hantera begäranden från alla användare, men den här metoden är vanligtvis mer komplex för design och generering. Du kan också kombinera de två mönstren i en lösning. Den trafikroutningsmetod som beskrivs senare i den här artikeln är ett exempel på ett sådant hybridscenario.

Problem och överväganden

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

• Distributionsprocess: När du distribuerar flera stämplar automatiserar och upprepar du distributionsprocesserna fullständigt. Använd modulerna Bicep eller Terraform för att deklarativt definiera dina stämplar och hålla definitionerna konsekventa.

• Korsstämpelåtgärder: När du distribuerar din lösning oberoende av flera stämplar kan det vara svårt att avgöra hur många kunder du har i alla dina stämplar. Du kan behöva köra frågor mot varje stämpel och aggregera resultatet. Du kan också ha alla stämplar som publicerar data i ett centraliserat informationslager för konsoliderad rapportering.

• Utskalningsprinciper: Stämplar har en begränsad kapacitet som du kan definiera med hjälp av ett proxymått, till exempel antalet klienter som du kan distribuera till stämpeln. Övervaka den tillgängliga och använda kapaciteten för varje stämpel och distribuera proaktivt fler stämplar för att dirigera nya klienter till dem.

• Minsta antal stämplar: När du använder mönstret Distributionsstämplar distribuerar du minst två stämplar av lösningen. Om du bara distribuerar en enda stämpel kan du enkelt hårdkoda antaganden i din kod eller konfiguration som inte gäller när du skalar ut.

• Kostnad: Mönstret Distributionsstämplar distribuerar flera kopior av dina infrastrukturkomponenter, vilket avsevärt ökar kostnaden för att använda lösningen.

• Flytta mellan stämplar: Varje stämpel körs oberoende av varandra, så det kan vara svårt att flytta klienter mellan stämplar. Ditt program behöver anpassad logik för att överföra en kunds information till en annan stämpel och sedan ta bort hyresgästens information från den ursprungliga stämpeln. Den här processen kan kräva ett bakplan för att kommunicera mellan stämplar, vilket ytterligare ökar komplexiteten i din lösning.

• Trafikroutning: Som beskrivs tidigare i den här artikeln kan routning av trafik till rätt post för en viss begäran kräva en extra komponent som mapplicerar hyresgäster till poster. Den här komponenten kan också behöva ha hög tillgänglighet.

• Observerbarhet mellan stämplar: När antalet stämplar ökar blir det svårare att förstå den allmänna hälsan och snabbt identifiera incidenter. Använd Azure Monitor för att samla in och korrelera mått, loggar, spårningar och aviseringar för alla stämplar. Använd dessa data för att identifiera felstämplar och diagnostisera problem.

• Regional felpåverkan: Systemen körs oberoende av varandra, men de är inte redundanta över regioner i sig. Om en region som är värd för en eller flera stämplar blir otillgänglig förlorar klienterna på dessa stämplar åtkomst tills regionen återställs eller du migrerar klienterna till stämplar i en annan region. Planera för det här scenariot genom att dokumentera dina återställningsprocedurer, ange klientförväntningar och överväga om kritiska klienter behöver geo-redundant stämpelplacering.

• Delade komponenter: Du kan ha komponenter som du kan dela mellan stämplar. Om du till exempel har en delad enkelspårig app för alla klienter, distribuera den till en region och använd Azure Front Door gränscachelagring för att replikera den globalt.

• Styrnings- och konfigurationsavdrift: När antalet stämplar ökar blir det svårare att hålla säkerhetsprinciper, rollbaserade åtkomstkontrolltilldelningar (RBAC), nätverkskontroller, observerbarhetsinställningar och tjänstkonfigurationer konsekventa. Använd Azure Policy för att behandla styrning som kod och validera varje stämpel kontinuerligt för drift för att förhindra inkonsekventa beteende- och efterlevnadsluckor.

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

Använd det här mönstret i sådana här scenarier:

• Din lösning har naturliga gränser för skalbarhet. Om vissa komponenter till exempel inte kan eller inte bör skalas utöver ett visst antal kunder eller begäranden använder du stämplar för att skala ut.

• Du måste separera vissa klienter från andra. Om säkerhetsproblem hindrar dig från att distribuera vissa kunder till en multitenantstämpel distribuerar du dem till en egen isolerad stämpel.

• Du måste vara värd för vissa klienter i olika versioner av din lösning samtidigt.

• Du skapar program i flera regioner som behöver dirigera varje klients data och trafik till en viss region.

• Du vill uppnå återhämtning under avbrott. Stämplar körs oberoende av varandra, så om ett avbrott påverkar en enskild stämpel, påverkas inte användare på andra stämplar. Den här isoleringen begränsar påverkningsområdet för en incident eller ett avbrott.

Det här mönstret kanske inte är lämpligt när:

• Din lösning är enkel och behöver inte skalas i hög grad.

• Du kan skala ut eller upp systemet i en enda instans, till exempel genom att öka storleken på programskiktet eller genom att öka den reserverade kapaciteten för databaser och lagringsnivån.

• Du måste replikera data över alla distribuerade instanser. Överväg Geode-mönstret för det här scenariot.

• Du behöver bara skala vissa komponenter och inte andra. Överväg till exempel om du kan skala din lösning genom att partitionera datalagret i stället för att distribuera en ny kopia av alla lösningskomponenter.

• Din lösning består enbart av statiskt innehåll, till exempel ett JavaScript-program på klientsidan. Leverera det här innehållet via ett nätverk för innehållsleverans.

Design av arbetsbelastning

Utvärdera hur du använder mönstret Distributionsstämplar i utformningen av en arbetsbelastning för att hantera de mål och principer som beskrivs i pelarna i Azure Well-Architected Framework. Följande tabell innehåller vägledning om hur det här mönstret stöder målen för varje pelare.

Om detta mönster inför kompromisser inom en pelare bör du överväga dem mot målen för de andra pelarna.

Example

I följande exempelarkitektur används Azure Front Door, Azure API Management och Azure Cosmos DB för att dirigera trafik globalt till en serie regionspecifika stämplar.

Anta att en användare finns i New York. Stamp 3, i regionen östra USA, lagrar sina data.

Om användaren reser till Kalifornien och kommer åt systemet dirigerar systemet sin anslutning via regionen USA, västra 2 eftersom den regionen ligger närmast dem när de gör begäran. Stämpel 3 måste dock i slutändan hantera begäran eftersom den lagrar deras data. Trafikroutningssystemet dirigerar begäran till rätt stämpel.

Deployment

Beskriv infrastrukturen som kod med hjälp av Bicep eller Terraform. Den här metoden säkerställer att distributionen av varje stämpel är förutsägbar och repeterbar. Det minskar också sannolikheten för mänskliga fel, till exempel oavsiktliga felaktiga inställningar i konfigurationen mellan komponenter.

Du kan distribuera uppdateringar automatiskt till alla stämplar parallellt. Tekniker som Bicep kan samordna distributionen av din infrastruktur och dina program. Du kan också välja att gradvis distribuera uppdateringar till vissa stämplar först och sedan progressivt till andra stämplar. Överväg att använda ett versionshanteringsverktyg som Azure-pipelines eller GitHub Actions för att samordna distributioner till varje stämpel.

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

• En prenumeration innehåller vanligtvis alla resurser för en enskild lösning, så överväg att använda en enda prenumeration för alla stämplar. Men somliga Azure tjänster inför prenumerationsomfattande kvoter. 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 distribuera stämplar i olika prenumerationer.

• Resursgrupper innehåller vanligtvis komponenter som delar samma livscykel. Om du planerar att distribuera uppdateringar till alla stämplar samtidigt kan du använda en enda resursgrupp som innehåller alla komponenter för alla stämplar. Använd namngivningskonventioner och taggar för resurser för att identifiera de komponenter som tillhör varje stämpel. Om du planerar att distribuera uppdateringar till varje stämpel separat kan du 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 eller klienter som en enskild stämpel kan hantera, eller på mått som tjänsterna i stämpeln genererar. Instrumentera varje stämpel så att du kan mäta när den närmar sig sin kapacitet och se till att du snabbt kan distribuera nya stämplar för att svara på efterfrågan.

Trafikroutning

Mönstret Distributionsstämplar fungerar bra när du hanterar varje stämpel oberoende av varandra. Om Contoso till exempel distribuerar samma API-program över flera stämplar kan Contoso använda DNS (Domain Name System) för att dirigera trafik till relevant stämpel:

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

I Azure kan du vara värd för dessa poster i Azure DNS och använda en konsekvent underdomänkonvention för varje region och stämpel. Den här metoden upprätthåller förutsägbar routning och åtgärder.

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

Om din lösning behöver en enda ingresspunkt för all trafik kan du använda en trafikdirigeringstjänst för att identifiera 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 genom att returnera en HTTP 302-svarsstatuskod), eller så fungerar den som en omvänd proxy och vidarebefordrar trafiken till relevant stämpel utan att klienten känner till 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 till flera regioner, eventuellt inklusive varje region som hanterar stamp-enheter, och synkronisera datalagret som associerar hyresgäster med stamp-enheter. Trafikroutningskomponenten kan i sig vara en instans av Geode-mönstret.

Du kan till exempel distribuera API Management för att fungera som trafikroutningstjänst. API Management avgör lämplig stämpel för en begäran genom att leta upp data i en Azure Cosmos DB samling som lagrar mappningen mellan klienter och stämplar. API Management anger sedan dynamiskt serverdels-URL:en till den relevanta stämpelns API-tjänst.

Om du vill geodistribuera begäranden och tillhandahålla geo-redundans för trafikroutningstjänsten distribuera API Management i flera regioner och använda Azure Front Door för att dirigera trafik till närmaste API Management-gateway. I den här topologin använder Azure Front Door origin-grupper, hälsoavsökningar och en lämplig dirigeringsmetod för att dirigera begäranden bort från felaktiga regionala API Management-gatewayer. API Management dirigerar sedan till rätt stämpel med hjälp av mappningen klient-till-stämpel och dess serverdelskonfiguration (eller serverdelspooler), inklusive redundansregler mellan stämpelslutpunkter efter behov. Om ditt program inte exponeras via HTTP eller HTTPS kan du använda en cross-region Azure lastbalanserare för att distribuera inkommande anrop till regionala Azure lastbalanserare. Använd funktionen global distribution i Azure Cosmos DB för att hålla mappningsinformationen uppdaterad i varje region.

Om din lösning innehåller en trafikroutningstjänst bör du överväga om den fungerar som en gateway och kan utföra gateway-avlastning för de andra tjänsterna, till exempel tokenverifiering, hastighetsbegränsning och auktorisering.

Nästa steg

• Azure Front Door
• Integrera Bicep med Azure-pipelines
• Integrera JSON ARM-mallar med Azure-pipelines

Contributors

Microsoft ansvarar för den här artikeln. Följande bidragsgivare skrev den här artikeln.

Huvudförfattare:

• John Downs | Principal Software Engineer, Azure Patterns &Practices

Övriga medarbetare:

• Federico Arambarri | Senior Software Developer, Clarius Consulting
• Daniel Larsen | Huvudkundtekniker, FastTrack för Azure
• Angel Lopez | Senior Software Engineer, Azure Patterns and Practices
• Paolo Salvatori | Huvudkundtekniker, FastTrack för Azure
• Arsen Vladimirskiy | Huvudkundtekniker, FastTrack för Azure

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Relaterade resurser

• Du kan använda horisontell partitionering som en annan enklare metod för att skala ut datanivån. Stämplar fragmenterar implicit sina data, men horisontell partitionering kräver ingen distributionsstämpel. Mer information finns i mönster för horisontell partitionering.
• Om din lösning distribuerar en trafikroutningstjänst kan du kombinera gateway-routing och gateway-avlastningsmönster för att optimalt utnyttja denna komponent.