Globalt distribuerade appar med Cosmos DB

Cosmos DB
Traffic Manager

Garantera åtkomst till användare över hela världen med funktionerna för hög tillgänglighet och låg latens som är inbyggda i Microsofts globala datacenter.

Arkitektur

Arkitekturdiagram
Ladda ned en SVG-version av den här arkitekturen.

Dataflöde

  1. Användaren kommer åt programmet via den dedikerade klienten.
  2. Azure Traffic Manager dirigerar användarens anslutning till den bästa platsen för att komma åt programmet, baserat på en enda eller kapslad routningsprofil.
  3. I den landade regionen där programmet finns hanterar programmet sessionen och anslutningen till databasen.
  4. Det här programmet kan vara allt från en enkel statisk sida upp till ett mikrotjänstorienterat program som till exempel finns i Kubernetes.
  5. Anslutningen mellan programlandskapet och Cosmos DB hanteras via en Azure Active Directory-användare som kan hämta Cosmos DB nycklar i Key Vault.
  6. Genom att Azure Cosmos DB flera API:er är ditt program medveten om den närmaste regionen och kan skicka begäranden till den regionen. Den närmaste regionen identifieras utan några konfigurationsändringar. När du lägger till och tar bort regioner till och från ditt Azure Cosmos-konto behöver programmet inte omdistribueras eller pausas. Det fortsätter att ha hög tillgång hela tiden. Under omslaget hanterar Cosmos DB den globala distributionen och replikeringen av data baserat på antalet definierade regioner. Dessutom bör du också dra nytta av alternativet automatisk redundans för att redundans redundans till regionen med högsta prioritet för redundans utan användaråtgärd om en region blir otillgänglig. När automatisk redundans är aktiverat kan regionsprioritet ändras.

Komponenter

  • Azure Traffic Manager:skapa DNS-baserad belastningsutjämning/routningsalternativ för dina program med sex typer av DNS-baserade trafikroutningsalternativ som kan kapslas.
  • Azure Active Directory:Synkronisera lokala kataloger och aktivera enkel inloggning.
  • Azure Cosmos DB:Globalt distribuerad databas med flera modeller för alla skalning.

Alternativ

Du kan utöka det här scenariot med flera beräkningsalternativ och serverlösa alternativ.

Beräkningsalternativ

  • Azure Virtual Machines:Skapa Linux Windows virtuella datorer (VM) på några sekunder och minska kostnaderna.
  • Azure Kubernetes Services:Hög tillgänglig, säker och fullständigt hanterad Kubernetes-tjänst för alla dina program- och mikrotjänstbasarbetsbelastningar.
  • App Service:Skapa snabbt kraftfulla molnappar för webben och mobilt.

Serverlösa alternativ

Överväganden

Tillgänglighet

Tillgängligheten för Cosmos DB instansen beror på ett antal faktorer. Ju fler regioner som Cosmos replikeras till, desto större blir programmets tillgänglighet. Varje region innehåller alla datapartitioner för en Azure Cosmos DB container och kan som standard visa läsningar. Om du vill öka tillgängligheten för datalagret kan du aktivera skrivning i flera regioner. Detta ökar tillgängligheten för datalagret. Du kan också öka tillgängligheten genom att använda svagare konsekvensnivåer och tillgänglighetszoner.

När du överväger ovanstående metod och uppnår hög tillgänglighet på Azure Cosmos DB Automatisk redundans konfigurerar du din lösning för att hålla programmet som körs på det högsta möjliga serviceavtalet.

För programlagret bör Traffic Manager konfigureras med kapslade profiler. När du push-ar den här designen till den högsta nivån kan du skala de olika programalternativen per region. Distributionen per region använder också en metod för hög tillgänglighet.

Prestanda

Systemprestanda påverkas av ett antal faktorer på beräknings- och databasnivå. SKU:n för en App Service plan eller något annat beräkningsalternativ påverkar det minne och de kärnor som är tillgängliga i varje region. Dessutom distribueras antalet regioner som beräkningslagret distribueras till för att avgöra skalan som den kan hantera. Distribution av ytterligare platser tar tryck på befintliga regioner och bör orsaka linjära ökningar i det maximala dataflödet som programmet kan uppfylla.

Cosmos DB bör konfigureras så att det inte orsakar en flaskhals för resurserna på beräkningsnivån. Varje databas och container i Cosmos DB ska konfigureras för automatisk skalning och ska tillhandahållas med ett högsta värde för begärandeenhet som garanterar Cosmos DB inte begränsar begäranden. Om du vill fastställa lämpliga maxvärden för enheter för programbegäran Cosmos DB entiteter kan du köra belastningstester nära ett ungefärligt maximalt dataflöde för programmet. Jämfört med deras starkare motsvarigheter ger svagare konsekvensnivåer högre dataflödes- och prestandafördelar.

Det är viktigt att när du implementerar logiken i kod som läser från och skriver till Cosmos DB, oavsett om det är via SDK, Azure Functions-bindningar och så vidare, så bör varje regionalt API dirigera begäranden till närmaste PreferredLocations Cosmos DB region. Baserat på Azure Cosmos DB kontokonfiguration, aktuell regional tillgänglighet och inställningslistan som anges väljer SDK den mest optimala slutpunkten för att utföra läs- och skrivåtgärderna. Den här processen resulterar i betydande prestandaökningar.

Återhämtning

För högre återhämtning kan du använda tillgänglighetszoner för Azure Cosmos DB distributioner. Återhämtningen beror också på vilka konsekvensnivåval du gör på Cosmos DB distributionen. Beroende på den här konsekvensnivån får du en annan återhämtningsnivå (mer information finns i Konsekvens, tillgänglighet och prestanda kompromisser).

Skalbarhet

Skalning baseras på många nivåer i det här diagrammet. Azure Cosmos DB är specialbyggt för elastisk skalning och förutsägbar prestanda. På nivån för programmet måste du titta på beräkningsmodellen som används. Azure Functions och App Service kan skalas automatiskt. För Azure Virtual Machines kan du använda Azure Virtual Machine Scale Sets. När du är medveten om det här behovet bör du alltid överväga ett serverlöst alternativ när det är möjligt.

Säkerhet

Ur ett säkerhetsperspektiv kan du arbeta mot ett identitetsbaserat system där Azure Active Directory kan användas för att skydda åtkomsten till miljön. I backend är programmet (enligt bästa design) som nås via hanterade identiteter, men man kan också överväga metoden att använda Azure Active Directory-användare och Azure Key Vault för att skydda åtkomst. Dessutom bör Cosmos DB-instansen skyddas ytterligare, så att de enda entiteter som kan läsa och skriva till den är de olika backends som distribueras till olika regioner. IP-begränsning kan tillämpas på kontot med hjälp av den inbyggda brandväggen.

Vi stöder även Azure Active Directory RBAC direkt på Cosmos DB SQL API.

Nästa steg

Mer information om Azure Cosmos DB:

Mer information om Azure Traffic Manager:

Relaterade lösningsidéer:

Relaterade fullständiga arkitekturer:

Relaterad arkitekturvägledning: