Gå globalt

  • 3 minuter

I föregående lektion beskrev vi skalning av beräkning och gjorde den mer tillgänglig i processen. Vi föreslog också att du skulle lägga till en Azure Cache for Redis för att förbättra prestanda och skala ut Azure SQL-databaser via horisontell partitionering.

Nästa steg i takt med att ditt företag växer kan vara att bli globalt. Det finns dock några saker du måste tänka på innan du försöker implementera en helt global arkitektur.

Frågor att ställa

Den första frågan är: Behöver du verkligen bli global?

Det är viktigt att förstå vilken smärta våra kunder har innan de tar på sig en sådan uppgift, så ställ dig några fler frågor:

  • Kan du få innehåll närmare dina användare via ett nätverk för innehållsleverans?
  • Behöver du verkligen skala det här systemet över två (eller flera) geografiska områden? Behöver en användare i USA till exempel ha exakt samma konto i Storbritannien? Skulle oberoende system vara lämpligare? Det här mönstret är vanligt inom e-handel.
  • Vilken konsistens behöver du för databasen om du verkligen behöver ett globalt distribuerat system? Stark konsistens runt om i världen är svår att få rätt och är inte tillåtet i tjänster som Cosmos DB, helt bokstavligt på grund av ljusets hastighet.

Datakonsekvens

Låt oss titta lite närmare på problemet med datakonsekvens.

Konsekvens i databassystem refererar till kravet att en viss databastransaktion endast måste ändra berörda data på ett sätt som tillåts. Det finns två konsekvensmodeller som används vid distribuerad databehandling.

Stark konsekvensgaranti ger en garanti för linjäriserbarhet. Läsningarna returnerar garanterat den senaste bekräftade versionen av ett objekt.

Och sedan finns det slutlig konsekvens, tanken att en databas eller ett system så småningom kommer att bli konsekvent över tid. Det finns ingen beställningsgaranti för läsningar. Vid avsaknad av ytterligare skrivningar konvergerar replikerna så småningom.

Verktyg för att bli global

Om du upptäcker att du verkligen behöver skala ditt program globalt finns det några Azure-tjänster som kan hjälpa dig att uppnå det. Nu ska vi ta en titt på Azure Traffic Manager och Azure Front Door:

  • Azure Traffic Manager är en global DNS-baserad belastningsutjämningstjänst. Den använder DNS- och hälsoavsökningar för att dirigera användarna till den bästa felfria serverdelen baserat på de routningsprinciper som du har definierat. Den här definitionen kan baseras på prestanda, plats, rundgång och så vidare. När en felfri serverdel har identifierats ansluter klienterna alltid direkt till serverdelen.
  • Azure Front Door Service är som en tjänst ett applikationsleveransnätverk (ADN) som erbjuder olika lager 7-funktioner för belastningsutjämning för dina program. Det ger dynamisk platsacceleration (DSA) tillsammans med global belastningsutjämning med nästan realtidsredundans. Det är en mycket tillgänglig och skalbar tjänst som hanteras fullt ut av Azure.

Azure Front Door är i princip en global HTTP-baserad lastbalanserare. Kunden upprättar en anslutning till Front Door, så Front Door agerar proxy för användarnas begäran. Om det begärda objektet inte finns i cacheminnet identifieras rätt routningsregel. Sedan kontrollerar den hälsoavsökningen för den relevanta serverdelen, och förutsatt att allt är felfritt vidarebefordras användarbegäran till den bästa serverdelen baserat på routningsmetoden.

För att Azure Front Door proxyar anslutningen kan du utföra vissa avancerade funktioner, såsom att köra en web application firewall (WAF) och administrera cachelagring; vilket är användbart för skalning. Ingen av dessa funktioner kan uppnås med Traffic Manager.

Diagrammet visar hur du kan använda båda tillsammans.

Diagram över fullständig arkitektur som visar både Azure Front Door och Traffic Manager i samma arkitektur.

Den här konfigurationen använder Traffic Manager för enkel DNS-baserad belastningsutjämning till dina statiska tillgångar i lagringskonton. Den använder också Front Door för sökvägsbaserad routning i ditt webbprogram över App Service och virtuella datorer.