Webtoepassing met meerdere regio's met Storage tabelreplicatie

Deze architectuur biedt een oplossing voor hoge beschikbaarheid voor een webtoepassing die gebruikmaakt van enorme hoeveelheden gegevens. Het is een flexibele benadering die een globale oplossing kan bieden die toepassingen en gegevens distribueert om deze dicht bij gebruikers te houden.

Voor de architectuur is aangepaste replicatiesoftware vereist. Dit kan lastig zijn om te maken, afhankelijk van de toepassingen en de configuratie.

Hier zijn enkele mogelijke configuraties:

• Actief/passief: Er is een primaire regio die normaal gesproken alle gebruikers service biedt. 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 naar de stand-byregio.

• Actief/actief: Er is een primaire regio die normaal gesproken actief is en die leesservice biedt aan gebruikers in de buurt en service schrijft naar alle gebruikers. Een of meer andere regio's zijn actief en bieden alleen-lezenservice aan gebruikers in de buurt. Schrijfingen worden altijd omgeleid naar de primaire regio en lees lezen worden altijd omgeleid naar de dichtstbijzijnde actieve regio.

  Net als bij de actief/passief-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 naar de alleen-lezen regio's en de stand-byregio. Wanneer de stand-byregio actief is, repliceert de replicatieservice databasewijzigingen naar de alleen-lezen regio's.

  Een nadeel van deze benadering is de hoge latentie van schrijfbewerkingen.

• Multi-active: Er zijn meerdere actieve regio's die elk volledige service aan gebruikers kunnen bieden. Gebruikersactiviteit wordt altijd omgeleid naar de dichtstbijzijnde actieve regio.

  De implementatie van meerdere actieve gebruikers is een hele uitdaging en kan een deskundige ontwerp en implementatie vereisen.

Omdat replicatie een aangepaste implementatie is, kan het consistentieniveau zijn wat nodig is.

De mogelijke problemen bij het implementeren van aangepaste replicatie en de tijd die nodig is om dit te doen, zijn belangrijke overwegingen bij deze architectuur.

Potentiële gebruikscases

De architectuur is mogelijk geschikt voor elke toepassing die gebruikmaakt van enorme hoeveelheden gegevens die altijd beschikbaar moeten zijn. Voorbeelden hiervan zijn apps die:

• Houd de bestedingsgewoonten en het winkelgedrag van klanten bij.
• Weersvoorspelling.
• Bied slimme verkeerssystemen aan of implementeert slimme verkeerssystemen of gebruik slimme technologie om verkeer te bewaken.
• Analyseer productiegegevens Internet of Things (IoT).
• Slimme metergegevens weergeven of slimme technologie gebruiken om metergegevens te bewaken.

Architectuur

Een Visio-bestand van deze architectuur downloaden.

1. De client wordt geverifieerd met Azure Active Directory (Azure AD) en krijgt toegang tot webtoepassingen die worden gehost op Azure App Service.
2. Azure Front Door firewall en laag 7-load balancer schakelt gebruikersverkeer over naar een andere Azure-regio in het geval van een regionale storing.
3. Azure App Service host websites en RESTful-web-API's. Browser-clients voeren AJAX-toepassingen uit die gebruikmaken van de API's.
4. Web-API's delegeren functie-apps voor het afhandelen van achtergrondtaken. De taken worden in de wachtrij geplaatst in Azure Queue Storage wachtrijen.
5. De functie-apps die worden gehost Azure Functions voeren de achtergrondtaken uit, geactiveerd door de berichten in de wachtrij.
6. De aangepaste replicatiesoftware zorgt ervoor dat tabellen in regio's identiek blijven.
7. Azure Cache voor Redis cachet tabelgegevens voor de functie-apps. Dit offloadt databaseactiviteit en versnelt de functie-apps en web-apps.
8. Azure Table Storage bevat de gegevens die worden gebruikt door de webtoepassingen.

Onderdelen

• Azure Active Directory (Azure AD) is een multi-tenant service voor identiteits- en toegangsbeheer 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 Azure DNS is hetzelfde als het beheren van andere Azure-services en maakt gebruik van dezelfde referenties, API's, hulpprogramma's en facturering.
• Azure Front Door is een beveiligd netwerk voor contentlevering (CDN) en load balancer met directe failover. Het werkt aan de rand dicht bij gebruikers, wat de levering van inhoud versnelt en tegelijkertijd apps, API's en websites beveiligt 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 op Windows of Linux. In een mainframe-migratie kunnen de front-endschermen of webinterface worden gecodeerd als REST API's op basis van HTTP. Ze kunnen worden gescheiden en kunnen staatloos zijn om een systeem op basis van microservices te orkestreren. Zie RESTful web-API-ontwerpvoor meer informatie over web-API's.
• Azure Functions biedt een omgeving voor het uitvoeren van kleine stukjes code, functies genoemd, zonder een toepassingsinfrastructuur tot stand te brengen. U kunt deze 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 bevat Azure Files, Azure Table Storageen Azure Queue Storage. Azure Files is vaak een effectief hulpprogramma voor het migreren van mainframe-workloads.
• Azure Queue Storage eenvoudige, rendabele en duurzame berichtenwachtrijen voor grote workloads.
• Azure Table Storage is een NoSQL-sleutel-waardeopslag voor snelle ontwikkeling die gebruikmaakt van enorme semi-gestructureerde gegevenssets. De tabellen zijn schemaloos en kunnen gemakkelijk worden aangepast wanneer 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 in-memory cachingservice en berichtenbroker voor het delen van gegevens en status tussen rekenbronnen. Het bevat 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 zo te ontwerpen dat ze kunnen worden geschaald en door gebruik te maken van een gegevensopslag in het geheugen, zoals Azure Cache voor Redis.

Alternatieven

• Azure Traffic Manager inkomende DNS-aanvragen doorsturen naar de wereldwijde Azure-regio's op basis van uw keuze van verkeersrouteringsmethoden. Het biedt ook automatische failover en prestatieroutering.
• Azure Content Delivery Network (CDN) cachet statische inhoud op edge-servers voor snelle reacties en maakt gebruik van netwerkoptimalisaties om de reactie op dynamische inhoud te verbeteren. CDN is vooral nuttig wanneer de gebruikersbasis globaal 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 microservicearchitectuur 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 dat u de infrastructuur moet beheren. Dit is handig tijdens de ontwikkeling of bij het uitvoeren van niet-geplande taken.
• Azure Service Fabric is een platform voor het schalen en inschalen van containers en microservices.
• Azure Service Bus is een betrouwbare cloudberichtenservice voor eenvoudige hybride integratie. Deze kan worden gebruikt in plaats van Storage in deze architectuur. Zie Storage wachtrijen en Service Bus - vergeleken en contrasterend voor meer informatie.

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 tijd die nodig is om dit te doen, zijn belangrijke overwegingen bij deze architectuur.

• Omdat replicatie op maat is ontworpen, hebben ontwikkelaars veel flexibiliteit bij het implementeren van een strategie voor gegevensconsistentie.

• Er zijn prestatielimieten voor Tabel-Storage die kunnen worden ondervangen door Storage toevoegen. In de volgende omstandigheden zijn mogelijk extra accounts vereist:

  • Meerdere tenancy implementeren ter ondersteuning van meerdere klanten
  • Ter ondersteuning van klanten met hogere transactiesnelheden
  • Klanten ondersteunen met grote gegevenssets
  • Gegevenstoegang versnellen door gegevens te distribueren over meerdere opslagaccounts
  • Gegevens scheiden in hot-, koude- en archieflagen
  • Kopieën van gegevens maken voor back-up- en rapportagedoeleinden

  Zie Schaalbaarheids- en prestatiedoelen voor Table Storage voor meer Storage.

• Als uw toepassing al gegevens bevat, moet u routines schrijven om oude gegevens naar opslagaccounts te kopiëren. Zorg ervoor dat u tijdstempel- en kopieervlaggen hebt om de voortgang van de migratie van gegevens bij te houden.

Volgende stappen

• Architectuurstijl Werkrol-voor-webwachtrij
• Richtlijnen voor tabelontwerp
• Geo-redundantie gebruiken om toepassingen met hoge beschikbare gegevens te ontwerpen
• Strategieën voor gegevenspartities

Gerelateerde resources

• Schaalbare databaseoplossingen bouwen met Azure-services
• RESTful-web-API-ontwerp