Mönster för distributionsstämplar

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 klientorganisationer. Varje enskild kopia kallas för en stämpel, eller ibland en tjänstenhet, skalningsenhet eller cell. I en miljö med flera klienter kan varje stämpel eller skalningsenhet hantera 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 skalbarheten för din lösning, göra det möjligt 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 är det viktigt att tänka på 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 leda till naturliga skalningsgränser. Du kan till exempel använda tjänster som har gränser för antalet inkommande anslutningar, värdnamn, TCP-socketar 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 bli en plötslig minskning av prestanda eller ökning av kostnaden 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 oöverkomlig och att utskalning är en mer kostnadseffektiv strategi.
• Separation 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 betjäna än andra och överväga att gruppera dem på olika infrastrukturuppsättningar.
• Hantera instanser med en eller flera klientorganisationer. 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 med flera klientorganisationer.
• 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 mot att ha frekventa uppdateringar av systemet, medan andra kan vara riskvilliga och vill ha ovanliga uppdateringar av systemet som betjänar deras begäranden. Det kan vara bra att ha dessa kunder distribuerade till isolerade miljöer.
• Geografiska eller geopolitiska begränsningar. För att skapa för låg svarstid eller för att uppfylla kraven på datasuveränitet kan du distribuera några av dina kunder till specifika regioner.

Dessa begränsningar gäller ofta för oberoende programvaruleverantörer (ISV:er) som skapar saaS (software as a service), som ofta är utformade för att vara multitenanted. Samma begränsningar kan dock även gälla för andra scenarier.

Lösning

Undvik dessa problem genom att gruppera resurser i skalningsenheter och etablera flera kopior av dina stämplar. Varje skalningsenhet är värd för och betjänar en delmängd av dina klientorganisationer. Stämplar fungerar oberoende av varandra och kan distribueras och uppdateras separat. En enda geografisk region kan innehålla en enda stämpel eller innehålla flera stämplar för horisontell utskalning inom regionen. Stämplar innehåller 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 blandning av båda. Vanligtvis kräver IaaS-arbetsbelastningar mer åtgärder för att skala, 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 inom stämpeln.

Mönstret för distributionsstämpel används internt av många Azure-tjänster, inklusive App Service, Azure Stack och Azure Storage.

Distributionsstämplar är relaterade till, men skiljer sig från, geoder. 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 hantera begäranden från alla användare, men den här arkitekturen är ofta mer komplex att utforma och bygga. Du kan också överväga att blanda de två mönstren i en lösning. trafikroutningsmetoden som beskrivs senare i den här artikeln är ett exempel på ett sådant hybridscenario.

Distribution

På grund av komplexiteten i att distribuera identiska kopior av samma komponenter är bra DevOps-metoder viktiga 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 med hjälp av Bicep, JSON Azure Resource Manager-mallar (ARM-mallar), Terraform och 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 matchningar i konfigurationen mellan stämplar.

Du kan distribuera uppdateringar automatiskt till alla stämplar parallellt, i vilket fall du kan överväga tekniker som Bicep eller Resource Manager-mallar för att 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. Överväg att använda ett versionshanteringsverktyg som Azure Pipelines eller GitHub Actions för att samordna distributioner till varje stämpel. Mer information finns i:

• Integrera Bicep med Azure Pipelines
• Integrera JSON ARM-mallar med Azure Pipelines

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

• Vanligtvis innehåller en prenumeration alla resurser för en enskild lösning, så i allmänhet bör du överväga att använda en enda prenumeration för alla stämplar. Vissa Azure-tjänster tillämpar dock prenumerationsomfattande kvoter, 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 i 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 kan du överväga att använda en enda resursgrupp för att innehålla 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. Om du planerar att distribuera uppdateringar till varje stämpel oberoende av varandra 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/klienter som en enskild stämpel kan hantera, eller mått från de tjänster som komponenterna i stämpeln genererar. Se till att du har tillräckligt med instrumentation för att mäta när en viss stämpel närmar sig dess kapacitet och möjligheten att snabbt distribuera nya stämplar för att svara på efterfrågan.

Trafikroutning

Mönstret Distributionsstämpel 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 australisk region.
• unit2.aus.myapi.contoso.com dirigerar trafik till stämpel unit2 inom en australisk region.
• unit1.eu.myapi.contoso.com trafik till stämpel unit1 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 trafikroutningstjä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 så kan den fungera som en omvänd proxy och vidarebefordra 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 stämplar distribueras till) och sedan se till att datalagret (mappa klienter till stämplar) synkroniseras. Trafikroutningskomponenten kan i sig vara en instans av geode-mönstret.

Azure API Management kan till exempel distribueras för att agera i trafikroutningstjänstrollen. Den kan fastställa 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 kan sedan dynamiskt ange serverdels-URL:en till relevant stämpels API-tjänst.

För att aktivera geo-distribution av begäranden och geo-redundans för trafikroutningstjänsten kan API Management distribueras över flera regioner, eller så kan Azure Front Door användas för att dirigera trafik till närmaste instans. Front Door kan konfigureras med en serverdelspool så att begäranden dirigeras till den närmaste tillgängliga API Management-instansen. Om ditt program inte exponeras via HTTP/S kan du använda en Azure Load Balancer mellan regioner 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.

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 de andra tjänsterna, till exempel tokenverifiering, begränsning och auktorisering.

Exempel på trafikroutningsarkitektur

Överväg följande exempel på trafikroutningsarkitektur, som använder Azure Front Door, Azure API Management och Azure Cosmos DB för global trafikroutning och sedan en serie regionspecifika stämplar:

Anta att en användare normalt finns i New York. Deras data lagras i stämpel 3 i regionen USA, östra.

Om användaren reser till Kalifornien och sedan kommer åt systemet dirigeras anslutningen troligen via regionen USA, västra 2 eftersom det är närmast där de är geografiskt när de gör begäran. Begäran måste dock i slutändan hanteras med stämpel 3, eftersom det är där deras data lagras. Trafikroutningssystemet ser till att begäran dirigeras till rätt stämpel.

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 helt repeterbara distributionsprocesser. Överväg att använda Bicep-, JSON ARM-mallar eller Terraform-moduler för att deklarativt definiera dina stämplar och för att hålla definitionerna konsekventa.
• Korsstämpelåtgärder. När din lösning distribueras oberoende av flera stämplar kan frågor som "hur många kunder vi har i alla våra stämplar?" bli mer komplexa att besvara. Frågor kan behöva köras mot varje stämpel och resultatet aggregeras. Du kan också överväga att låta alla stämplar publicera 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 använda kapaciteten för varje stämpel och att proaktivt distribuera ytterligare stämplar så att nya klienter kan dirigeras till dem.
• Minsta antal stämplar. När du använder mönstret Distributionsstämpel rekommenderar vi att du distribuerar minst två stämplar av din lösning. Om du bara distribuerar en enda stämpel är det enkelt att oavsiktligt hårdkoda antaganden i din kod eller konfiguration som inte tillämpas när du skalar ut.
• Kostnad. Mönstret Distributionsstämpel omfattar distribution av flera kopior av din infrastrukturkomponent, vilket sannolikt innebär en betydande ökning av kostnaden för att använda din lösning.
• Flytta mellan stämplar. Varje stämpel distribueras och drivs oberoende av varandra, så det kan vara svårt att flytta klienter mellan stämplar. Ditt program skulle behöva anpassad logik för att överföra informationen 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 en backplan för kommunikation mellan stämplar, vilket ytterligare ökar komplexiteten i den övergripande lösningen.
• Trafikroutning. Som beskrivs tidigare i den här artikeln kan routning av trafik till rätt stämpel för en viss begäran kräva en ytterligare komponent för att matcha klientorganisationer till stämplar. Den här komponenten kan i sin tur behöva göras högtillgä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 kan 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 bör skalas utöver ett visst antal kunder eller begäranden kan du överväga att skala ut med hjälp av stämplar.
• Ett krav på att skilja vissa klienter från andra. Om du har kunder som inte kan distribueras till en multitenantstämpel med andra kunder på grund av säkerhetsproblem kan de distribueras till sin egen isolerade stämpel.
• Ett behov av att ha vissa klienter i olika versioner av din lösning på samma gång.
• Program i flera regioner där varje klients data och trafik ska dirigeras till en viss region.
• En önskan att uppnå återhämtning under avbrott. Eftersom stämplar är oberoende av varandra, bör klientorganisationer som distribueras till andra stämplar inte påverkas om ett avbrott påverkar en enskild stämpel. Den här isoleringen hjälper till att begränsa "explosionsradien" 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 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.
• Lösningar där data ska replikeras i 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. Tänk till exempel på om lösningen kan skalas genom att partitionera 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å klientsidan. Överväg att lagra sådant innehåll på ett lagringskonto och använda Azure CDN.

Design av arbetsbelastning

En arkitekt bör utvärdera hur mönstret Distributionsstämplar 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.

Stödtekniker

• Infrastruktur som kod. Till exempel Bicep, Resource Manager-mallar, Azure CLI, Terraform, PowerShell, Bash.
• Azure Front Door, som kan dirigera trafik till en specifik stämpel eller till en trafikroutningstjä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. Stämplar kan konfigureras i alla regioner som stöder de tjänster som distribueras i mallen, men i illustrationssyfte distribuerar den här mallen två stämplar i regionen USA, västra 2 och ytterligare en stämpel i regionen Europa, västra. Inom en stämpel får apptjänsten sitt eget offentliga DNS-värdnamn och kan ta emot anslutningar oberoende av alla andra stämplar.

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

Exempel på trafikroutning

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 begäranden distribueras Front Door tillsammans med flera instanser av API Management på förbrukningsnivån. Varje API Management-instans läser klientorganisations-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 Azure Cosmos DB-datalager. Begäran vidarebefordras sedan till relevant backend-stämpel.

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

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

• John Downs | Programhanteraren för huvudnamn

Övriga medarbetare:

• 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 icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Relaterade resurser

• Horisontell partitionering kan användas 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 dokumentationen om mönster för horisontell partitionering.
• Om en trafikroutningstjänst distribueras kan gatewayroutnings- och gateway-avlastningsmönstren användas tillsammans för att använda den här komponenten på bästa sätt.