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. beroende på programmen och konfigurationen kan det vara svårt att skapa.
Här följer några möjliga konfigurationer:
Aktiv/passiv: Det finns en primär region som normalt tillhandahåller tjänsten till alla användare. Det finns också en väntelägesregion som blir aktiv när den primära regionen inte kan fungera. När det primära systemet är aktivt replikerar en replikeringstjänst databasändringar till väntelägesregionen.
Aktiv/aktiv: Det finns en primär region som normalt är aktiv, vilket ger lästjänsten till närliggande användare och skriver tjänsten till alla användare. En eller flera andra regioner är aktiva och tillhandahåller skrivskyddad tjänst till närliggande användare. Skrivningar dirigeras alltid till den primära regionen och läsningar dirigeras alltid till närmaste aktiva region.
Precis som med den aktiva/passiva konfigurationen finns det en väntelägesregion som blir aktiv när den primära regionen inte kan fungera. När det primära systemet är aktivt replikerar en replikeringstjänst databasändringar till de skrivskyddade regionerna och väntelägesregionen. 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 långa svarstiden för skrivåtgärder.
Flera aktiva: Det finns flera aktiva regioner som var och en kan tillhandahålla fullständig tjänst till användare. 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 det som behövs.
De möjliga svårigheterna med att implementera anpassad replikering och den tid som krävs är viktiga överväganden med den här arkitekturen.
Kommentar
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 (detaljhandeln).
- Prognostiserat väder (jordbruk, miljö och media/nyhetsbranscher).
- Erbjuda smarta trafiksystem eller implementera smarta trafiksystem eller använd smart teknik för att övervaka trafiken (fordons- och transportindustrin).
- Analysera IoT-data (Manufacturing Internet of Things).
- Visa smarta mätardata eller använd smart teknik för att övervaka mätardata (energiindustrin).
Arkitektur
Ladda ned en Visio-fil med den här arkitekturen.
Dataflöde
- Klienten autentiserar med Microsoft Entra-ID och beviljas åtkomst till webbprogram som finns i Azure App Service.
- Azure Front Door, en brandvägg och layer 7-lastbalanserare, växlar användartrafik till en annan Azure-region om det uppstår 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 bakgrundsuppgifter. Uppgifterna köas i Azure Queue Storage-köer.
- Funktionsapparna som hanteras av Azure Functions utför bakgrundsuppgifterna som utlöses av de köade meddelandena.
- Den anpassade replikeringsprogramvaran säkerställer att tabellerna förblir identiska mellan regioner.
- Azure Cache for Redis cachelagrar tabelldata för funktionsapparna. Detta avlastar databasaktiviteten och påskyndar funktionsappar och webbappar.
- Azure Table Storage innehåller de data som används av webbprogrammen.
Komponenter
- Microsoft Entra ID är en identitets- och åtkomsthanteringstjänst för flera klientorganisationer 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 ger appar snabba DNS-frågor och snabba uppdateringar av DNS-poster. Att hantera 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. Det fungerar på gränsen nära användare, påskyndar innehållsleveransen samtidigt som appar, API:er och webbplatser skyddas från cyberhot.
- Azure App Service är en fullständigt 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 i Windows eller Linux. I en stordatormigrering kan klientdelsskä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 DESIGN av RESTful-webb-API.
- Azure Functions tillhandahåller 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 massivt skalbara och säkra molntjänster för data, appar och arbetsbelastningar. Den innehåller Azure Files, Azure Table Storage och Azure Queue Storage. Azure Files är ofta ett effektivt verktyg för att migrera stordatorarbetsbelastningar.
- Azure Queue Storage tillhandahåller enkel, kostnadseffektiv, varaktig meddelandekö för stora arbetsbelastningar.
- Azure Table Storage är ett NoSQL-nyckelvärdeslager för snabb utveckling som använder massiva halvstrukturerade datamängder. 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 minnesintern cachelagringstjänst och meddelandekö för att dela 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 onlinetransaktionsbearbetningsprogram med högt dataflöde genom att utforma dem för skalning och använda ett minnesinternt datalager, 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. Det ger också automatisk redundans och prestandadirigering.
- Azure Content Delivery Network (CDN) cachelagrar statiskt innehåll i gränsservrar för snabb respons och använder nätverksoptimeringar för att förbättra svaret på 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 att distribuera och hantera containerbaserade program. Du kan använda den för att implementera en mikrotjänstarkitektur vars komponenter skalas oberoende på begäran.
- Azure Container Instances är ett snabbt och enkelt sätt att köra uppgifter utan att behöva hantera infrastrukturen. Det är användbart under utvecklingen eller för att köra oplanerade uppgifter.
- Azure Service Bus är en tillförlitlig molnmeddelandetjänst för enkel hybridintegrering. Den kan användas i stället för Queue Storage i den här arkitekturen. Mer information finns i Lagringsköer och Service Bus-köer – jämförs och kontrasteras.
Att tänka på
Arkitekturen kräver anpassad replikeringsprogramvara. Det kan vara svårt att skapa, beroende på program och konfiguration. De möjliga svårigheterna med att implementera anpassad replikering och den tid som krävs är viktiga överväganden med den här arkitekturen.
Eftersom replikeringen är anpassad har utvecklare stor flexibilitet när det gäller att implementera en strategi för datakonsekvens.
Det finns prestandabegränsningar för Table Storage som kan övervinnas genom att lägga till lagringskonton. Följande omständigheter kan kräva fler konton:
- Implementera flera innehavare för att stödja flera kunder
- För att stödja kunder med högre transaktionshastigheter
- För att stödja kunder med stora datamängder
- Så här påskyndar du dataåtkomsten genom att distribuera data över flera lagringskonton
- Så här separerar du data i frekventa, kalla och arkiverade nivåer
- Så här gör du kopior av data i säkerhetskopierings- och rapporteringssyfte
Mer information finns i Skalbarhets- och prestandamål för Table Storage.
Om ditt program 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 migrering av data.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
- Nabil Siddiqui | Molnlösningsarkitekt – Digital innovation och programinnovation