Den här arkitekturen ger en lösning med hög tillgänglighet för ett webbprogram som använder enorma mängder data. Det är en flexibel metod som kan ge en global lösning som distribuerar program och data för att hålla den nära användarna.
Arkitekturen kräver anpassad replikeringsprogramvara. Det kan vara svårt att skapa, beroende på program och konfiguration.
Här är några möjliga konfigurationer:
Aktiv/passiv: Det finns en primär region som normalt tillhandahåller tjänster till alla användare. Det finns också en reservregion som blir aktiv när den primära regionen inte fungerar. När det primära systemet är aktivt replikerar en replikeringstjänst databasändringar till reservregionen.
Aktiv/Aktiv: Det finns en primär region som normalt är aktiv, vilket ger lästjänsten till användare i närheten och skriver tjänsten till alla användare. En eller flera andra regioner är aktiva och tillhandahåller skrivskyddade tjänster till användare i närheten. Skrivningar dirigeras alltid till den primära regionen och läsningar dirigeras alltid till närmaste aktiva region.
Precis som med konfigurationen Aktiv/Passiv finns det en reservregion som blir aktiv när den primära regionen inte fungerar. När det primära systemet är aktivt replikerar en replikeringstjänst databasändringar till de skrivskyddade regionerna och reservregionen. När väntelägesregionen är aktiv replikerar replikeringstjänsten databasändringar till de skrivskyddade regionerna.
En nackdel med den här metoden är den höga svarstiden för skrivåtgärder.
Flera aktiva: Det finns flera aktiva regioner som var och en kan tillhandahålla fullständig service till användarna. Användaraktiviteten dirigeras alltid till närmaste aktiva region.
Implementering av flera aktiva är ganska utmanande och kan kräva expertdesign och implementering.
Eftersom replikering är en anpassad implementering kan konsekvensnivån vara den som behövs.
Det kan vara svårt att implementera anpassad replikering och den tid som krävs för att göra det är viktiga överväganden med den här arkitekturen.
Anteckning
Ditt program kan kräva flera lagringskonton under vissa omständigheter. Mer information finns i Överväganden.
Potentiella användningsfall
Arkitekturen kan vara lämplig för alla program som använder enorma mängder data som alltid måste vara tillgängliga. Exempel är appar som:
- Spåra kundernas utgiftsvanor och shoppingbeteende.
- Prognostiserade väderleksprognoser.
- Erbjuda smarta trafiksystem eller implementera smarta trafiksystem eller använd smart teknik för att övervaka trafiken.
- Analysera IoT Sakernas Internet data (manufacturing Sakernas Internet).
- Visa smarta mätardata eller använd smart teknik för att övervaka mätardata.
Arkitektur
Ladda ned en Visio-fil med den här arkitekturen.
- Klienten autentiseras med Azure Active Directory (Azure AD) och beviljas åtkomst till webbprogram som finns på Azure App Service.
- Azure Front Door, en brandvägg och layer 7-lastbalanserare, växlar användartrafik till en annan Azure-region vid ett regionalt avbrott.
- Azure App Service är värd för webbplatser och RESTful-webb-API:er. Webbläsarklienter kör AJAX-program som använder API:erna.
- Webb-API:er delegerar funktionsappar för att hantera bakgrundsaktiviteter. Aktiviteterna köas i Azure Queue Storage köer.
- Funktionsapparna som Azure Functions utför bakgrundsaktiviteterna som utlöses av köade meddelanden.
- Den anpassade replikeringsprogramvaran säkerställer att tabellerna är identiska mellan regionerna.
- Azure Cache for Redis cachelagrar tabelldata för funktionsapparna. Detta avlastar databasaktiviteten och påskyndar funktionsapparna och webbapparna.
- Azure Table Storage innehåller de data som används av webbprogrammen.
Komponenter
- Azure Active Directory (Azure AD) är en identitets- och åtkomsthanteringstjänst för flera innehavare som kan synkroniseras med en lokal katalog. Azure DNS är en värdtjänst med hög tillgänglighet för DNS-domäner som tillhandahåller appar med snabba DNS-frågor och snabba uppdateringar av DNS-poster. Att Azure DNS är som att hantera andra Azure-tjänster och använder samma autentiseringsuppgifter, API:er, verktyg och fakturering.
- Azure Front Door är ett säkert nätverk för innehållsleverans (CDN) och lastbalanserare med omedelbar redundans. Den fungerar vid gränsen nära användarna, vilket påskyndar innehållsleveransen samtidigt som appar, API:er och webbplatser skyddas mot cyberhot.
- Azure App Service är en helt hanterad tjänst för att skapa, distribuera och skala webbappar. Du kan skapa appar med hjälp av .NET, .NET Core, Node.js, Java, Python eller PHP. Appar kan köras i containrar eller på Windows eller Linux. I en stordatormigrering kan frontend-skärmarna eller webbgränssnittet kodas som HTTP-baserade REST-API:er. De kan separeras och kan vara tillståndslösa för att orkestrera ett mikrotjänstbaserat system. Mer information om webb-API:er finns i RESTful web API design.
- Azure Functions en miljö för att köra små delar av kod, som kallas funktioner, utan att behöva upprätta en programinfrastruktur. Du kan använda den för att bearbeta massdata, integrera system, arbeta med IoT och skapa enkla API:er och mikrotjänster. Med mikrotjänster kan du skapa servrar som ansluter till Azure-tjänster och alltid är uppdaterade.
- Azure Storage är en uppsättning mycket skalbara och säkra molntjänster för data, appar och arbetsbelastningar. Den innehåller Azure Files,Azure Table Storageoch Azure Queue Storage. Azure Files är ofta ett effektivt verktyg för att migrera stordatorarbetsbelastningar.
- Azure Queue Storage tillhandahåller enkel, kostnadseffektiv och beständig meddelandekö för stora arbetsbelastningar.
- Azure Table Storage är ett nyckelvärdeslager i NoSQL för snabb utveckling som använder enorma halvstrukturerade datauppsättningar. Tabellerna är schemalösa och anpassas enkelt när behoven ändras. Åtkomsten är snabb och kostnadseffektiv för många typer av program och kostar vanligtvis mindre än andra typer av nyckellagring.
- Azure Cache for Redis är en fullständigt hanterad cachelagringstjänst i minnet och autjämning av meddelanden för delning av data och tillstånd mellan beräkningsresurser. Den innehåller både Redis med öppen källkod och en kommersiell produkt från Redis Labs som hanterade tjänster. Du kan förbättra prestandan för program för bearbetning av transaktioner med högt dataflöde online genom att utforma dem för skalning och för att använda ett minnesinspel, till exempel Azure Cache for Redis.
Alternativ
- Azure Traffic Manager dirigerar inkommande DNS-begäranden i de globala Azure-regionerna baserat på ditt val av trafikroutningsmetoder. Den tillhandahåller också automatisk redundans och prestandadirigering.
- Azure Content Delivery Network (CDN) cachelagrar statiskt innehåll på gränsservrar för snabba svar och använder nätverksoptimeringar för att förbättra svaret för dynamiskt innehåll. CDN är särskilt användbart när användarbasen är global.
- Azure Kubernetes Service (AKS) är en fullständigt hanterad Kubernetes-tjänst för distribution och hantering av program i containrar. Du kan använda den för att implementera en arkitektur för mikrotjänster vars komponenter skalas oberoende på begäran.
- Azure Container Instances ett snabbt och enkelt sätt att köra uppgifter utan att behöva hantera infrastrukturen. Det är användbart under utveckling eller för att köra oplanerade uppgifter.
- Azure Service Fabric är en plattform för skalning och orkestrering av containrar och mikrotjänster.
- Azure Service Bus är en tillförlitlig meddelandetjänst i molnet för enkel hybridintegrering. Det kan användas i stället för Queue Storage i den här arkitekturen. Mer information finns i Storage köer och Service Bus köer – jämförd och kontrasterad.
Överväganden
Arkitekturen kräver anpassad replikeringsprogramvara. Det kan vara svårt att skapa, beroende på program och konfiguration. Det kan vara svårt att implementera anpassad replikering och den tid som krävs för att göra det är viktiga överväganden med den här arkitekturen.
Eftersom replikeringen är specialdesignad har utvecklarna stor flexibilitet när det gäller att implementera en strategi för datakonsekvens.
Det finns prestandabegränsningar för table-Storage som kan lösas genom att lägga Storage konton. Följande omständigheter kan kräva ytterligare konton:
- Implementera flera innehavare för att stödja flera kunder
- För att stödja kunder med högre transaktionspriser
- För att stödja kunder med stora datamängder
- För att påskynda dataåtkomsten genom att distribuera data över flera lagringskonton
- Så här åtser du data till nivåerna hot, cold och archive
- Göra kopior av data i säkerhetskopierings- och rapporteringssyfte
Mer information finns i Skalbarhets- och prestandamål för Table Storage.
Om programmet redan innehåller data måste du skriva rutiner för att kopiera gamla data till lagringskonton. Kontrollera att du har tidsstämpel- och kopieringsflaggor för att spåra förloppet för datamigrering.
Nästa steg
- Arkitekturformat för Web-Queue-Worker
- Riktlinjer för tabelldesign
- Använda geo-redundans för att utforma program med hög tillgänglighet
- Strategier för datapartitionering