Deze architectuur biedt een oplossing voor hoge beschikbaarheid voor een webtoepassing die enorme hoeveelheden gegevens gebruikt. Het is een flexibele benadering die een wereldwijde oplossing kan bieden die toepassingen en gegevens distribueert om deze dicht bij gebruikers te houden.
Voor de architectuur is aangepaste replicatiesoftware vereist. afhankelijk van de toepassingen en de configuratie kan dit lastig zijn om te maken.
Hier volgen enkele mogelijke configuraties:
Actief/passief: er is een primaire regio die normaal gesproken service biedt aan alle gebruikers. Er is ook een stand-byregio die actief wordt wanneer de primaire regio niet kan functioneren. Wanneer het primaire systeem actief is, repliceert een replicatieservice databasewijzigingen in de stand-byregio.
Actief/actief: er is een primaire regio die normaal gesproken actief is, waardoor leesservice wordt geboden aan gebruikers in de buurt en service naar alle gebruikers schrijft. Een of meer andere regio's zijn actief en bieden alleen-lezenservice aan gebruikers in de buurt. Schrijfbewerkingen worden altijd omgeleid naar de primaire regio en leesbewerkingen worden altijd omgeleid naar de dichtstbijzijnde actieve regio.
Net als bij de actieve/passieve configuratie is er een stand-byregio die actief wordt wanneer de primaire regio niet kan functioneren. Wanneer het primaire systeem actief is, repliceert een replicatieservice databasewijzigingen in de alleen-lezen regio's en de stand-byregio. Wanneer de stand-byregio actief is, repliceert de replicatieservice databasewijzigingen in de alleen-lezen regio's.
Een nadeel van deze benadering is de hoge latentie van schrijfbewerkingen.
Multi-actief: Er zijn meerdere actieve regio's, die elk geschikt zijn voor volledige service aan gebruikers. Gebruikersactiviteit wordt altijd omgeleid naar de dichtstbijzijnde actieve regio.
De implementatie van multi-actief is een hele uitdaging en kan een deskundige ontwerp en implementatie vereisen.
Omdat replicatie een aangepaste implementatie is, kan het consistentieniveau wat nodig is.
De mogelijke problemen bij het implementeren van aangepaste replicatie en de benodigde tijd zijn belangrijke overwegingen met deze architectuur.
Notitie
Uw toepassing vereist mogelijk meerdere opslagaccounts onder bepaalde omstandigheden. Zie Overwegingen voor meer informatie.
Potentiële gebruikscases
De architectuur kan geschikt zijn voor elke toepassing die gebruikmaakt van enorme hoeveelheden gegevens die altijd beschikbaar moeten zijn. Voorbeelden zijn apps die:
- Houd bestedingsgewoonten en winkelgedrag van klanten bij (detailhandel).
- Weer voorspellen (landbouw, milieu en media/nieuwsindustrie).
- Bied slimme verkeerssystemen aan of implementeer slimme verkeerssystemen of gebruik slimme technologie om verkeer (automobiel- en transportindustrie) te bewaken.
- IoT-gegevens (Manufacturing Internet of Things) analyseren.
- Slimme metergegevens weergeven of slimme technologie gebruiken om metergegevens (energie-industrie) te bewaken.
Architectuur
Een Visio-bestand van deze architectuur downloaden.
Gegevensstroom
- De client wordt geverifieerd met Microsoft Entra-id en krijgt toegang tot webtoepassingen die worden gehost op Azure-app Service.
- Azure Front Door, een firewall en laag 7 load balancer, schakelt gebruikersverkeer over naar een andere Azure-regio als er een regionale storing is.
- Azure-app Service host websites en RESTful-web-API's. Browserclients voeren AJAX-toepassingen uit die gebruikmaken van de API's.
- Web-API's delegeren functie-apps om achtergrondtaken af te handelen. De taken worden in de wachtrij geplaatst in Azure Queue Storage-wachtrijen.
- De functie-apps die door Azure Functions worden gehost, voeren de achtergrondtaken uit die worden geactiveerd door de berichten in de wachtrij.
- De aangepaste replicatiesoftware zorgt ervoor dat tabellen identiek blijven tussen regio's.
- Azure Cache voor Redis tabelgegevens voor de functie-apps in de cache opgeslagen. Hiermee worden databaseactiviteit offload en worden de functie-apps en web-apps versneld.
- Azure Table Storage bevat de gegevens die worden gebruikt door de webtoepassingen.
Onderdelen
- Microsoft Entra ID is een service voor identiteits- en toegangsbeheer met meerdere tenants die kan worden gesynchroniseerd met een on-premises directory. Azure DNS is een hostingservice met hoge beschikbaarheid voor DNS-domeinen die apps snelle DNS-query's en snelle updates voor DNS-records biedt. Het beheren van Azure DNS is net zoals het beheren van andere Azure-services en maakt gebruik van dezelfde referenties, API's, hulpprogramma's en facturering.
- Azure Front Door is een beveiligd CDN (Content Delivery Network) en een load balancer met directe failover. Het werkt aan de rand dicht bij gebruikers, het versnellen van de levering van inhoud tijdens het beveiligen van apps, API's en websites tegen cyberbedreigingen.
- Azure-app Service is een volledig beheerde service voor het bouwen, implementeren en schalen van web-apps. U kunt apps bouwen met behulp van .NET, .NET Core, Node.js, Java, Python of PHP. Apps kunnen worden uitgevoerd in containers of in Windows of Linux. In een mainframemigratie kunnen de front-endschermen of webinterface worden gecodeerd als OP HTTP gebaseerde REST API's. Ze kunnen worden gescheiden en kunnen staatloos zijn om een systeem op basis van microservices te organiseren. Zie RESTful web-API-ontwerp voor meer informatie over web-API's.
- Azure Functions biedt een omgeving voor het uitvoeren van kleine stukjes code, ook wel functies genoemd, zonder dat er een toepassingsinfrastructuur hoeft te worden gemaakt. U kunt het gebruiken om bulkgegevens te verwerken, systemen te integreren, met IoT te werken en eenvoudige API's en microservices te bouwen. Met microservices kunt u servers maken die verbinding maken met Azure-services en altijd up-to-date zijn.
- Azure Storage is een set zeer schaalbare en veilige cloudservices voor gegevens, apps en workloads. Het omvat Azure Files, Azure Table Storage en Azure Queue Storage. Azure Files is vaak een effectief hulpprogramma voor het migreren van mainframeworkloads.
- Azure Queue Storage biedt eenvoudige, rendabele, duurzame berichtenwachtrijen voor grote workloads.
- Azure Table Storage is een NoSQL-sleutel-waardearchief voor snelle ontwikkeling die gebruikmaakt van enorme semi-gestructureerde gegevenssets. De tabellen zijn schemaloos en kunnen gemakkelijk worden aangepast naarmate de behoeften veranderen. Toegang is snel en rendabel voor veel soorten toepassingen en kost doorgaans minder dan andere typen sleutelopslag.
- Azure Cache voor Redis is een volledig beheerde cacheservice in het geheugen en berichtenbroker voor het delen van gegevens en status tussen rekenresources. Het omvat zowel de opensource Redis als een commercieel product van Redis Labs als beheerde services. U kunt de prestaties van toepassingen voor online transactieverwerking met hoge doorvoer verbeteren door ze te ontwerpen om te schalen en om gebruik te maken van een gegevensarchief in het geheugen, zoals Azure Cache voor Redis.
Alternatieven
- Azure Traffic Manager stuurt binnenkomende DNS-aanvragen door in de globale Azure-regio's op basis van uw keuze aan verkeersrouteringsmethoden. Het biedt ook automatische failover- en prestatieroutering.
- Azure Content Delivery Network (CDN) slaat statische inhoud in de cache op in edge-servers voor snelle reactie en maakt gebruik van netwerkoptimalisaties om de reactie op dynamische inhoud te verbeteren. CDN is vooral handig wanneer de gebruikersbasis wereldwijd is.
- Azure Kubernetes Service (AKS) is een volledig beheerde Kubernetes-service voor het implementeren en beheren van toepassingen in containers. U kunt deze gebruiken om een microservicesarchitectuur te implementeren waarvan de onderdelen onafhankelijk op aanvraag worden geschaald.
- Azure Container Instances biedt een snelle en eenvoudige manier om taken uit te voeren zonder infrastructuur te hoeven beheren. Het is handig tijdens de ontwikkeling of voor het uitvoeren van niet-geplande taken.
- Azure Service Bus is een betrouwbare cloudberichtenservice voor eenvoudige hybride integratie. Het kan worden gebruikt in plaats van Queue Storage in deze architectuur. Zie Storage-wachtrijen en Service Bus-wachtrijen voor meer informatie, vergeleken en gecontrast.
Overwegingen
Voor de architectuur is aangepaste replicatiesoftware vereist. Dit kan lastig zijn om te maken, afhankelijk van de toepassingen en de configuratie. De mogelijke problemen bij het implementeren van aangepaste replicatie en de benodigde tijd zijn belangrijke overwegingen met deze architectuur.
Omdat replicatie aangepast is ontworpen, hebben ontwikkelaars veel flexibiliteit bij het implementeren van een strategie voor gegevensconsistentie.
Er zijn prestatielimieten voor Table Storage die kunnen worden opgelost door Opslagaccounts toe te voegen. Voor de volgende omstandigheden zijn mogelijk meer accounts vereist:
- Meerdere tenants implementeren ter ondersteuning van meerdere klanten
- Klanten met hogere transactietarieven ondersteunen
- Klanten ondersteunen met grote gegevenssets
- Gegevenstoegang versnellen door gegevens over meerdere opslagaccounts te distribueren
- Gegevens scheiden in dynamische, koude en archieflagen
- Kopieën van gegevens maken voor back-up- en rapportagedoeleinden
Zie Schaalbaarheids- en prestatiedoelen voor Table Storage voor meer informatie.
Als uw toepassing al gegevens bevat, moet u routines schrijven om oude gegevens naar opslagaccounts te kopiëren. Zorg ervoor dat u tijdstempels en kopieervlagmen hebt om de voortgang van de migratie van gegevens bij te houden.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
- Nabil Siddiqui | Cloud Solution Architect - Digitaal en Toepassingsinnovatie
Volgende stappen
- Richtlijnen voor tabelontwerp
- Georedundantie gebruiken om maximaal beschikbare toepassingen te ontwerpen