Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
In dit artikel worden overwegingen beschreven voor het beheren van gegevens in een microservicesarchitectuur. Elke microservice beheert zijn eigen gegevens, zodat gegevensintegriteit en gegevensconsistentie kritieke uitdagingen vormen.
Twee services mogen geen gegevensarchief delen. Elke service beheert een eigen persoonlijke gegevensopslag en andere services hebben er geen rechtstreeks toegang toe. Deze regel voorkomt onbedoelde koppeling tussen services, wat gebeurt wanneer services dezelfde onderliggende gegevensschema's delen. Als het gegevensschema wordt gewijzigd, moet de wijziging worden gecoördineerd voor elke service die afhankelijk is van die database. Door het gegevensarchief van elke service te isoleren, wordt het bereik van wijzigingen beperkt en blijft de flexibiliteit van onafhankelijke implementaties behouden. Elke microservice kan ook unieke gegevensmodellen, query's of lees- en schrijfpatronen hebben. Een gedeeld gegevensarchief beperkt de mogelijkheid van elk team om de gegevensopslag voor de specifieke service te optimaliseren.
In het diagram ziet u service A en een database in een sectie aan de linkerkant. Een pijl met het label Schrijfpunten van service A naar de database. Service B bevindt zich buiten deze sectie aan de rechterkant. Een pijl met het label "Lezen" wijst naar de database. Een rode X gaat over deze pijl.
Deze aanpak leidt natuurlijk tot polyglotpersistentie, wat betekent dat u meerdere technologieën voor gegevensopslag binnen één toepassing gebruikt. Een service heeft mogelijk de schema-on-read-mogelijkheden van een documentdatabase nodig. Een andere service heeft mogelijk de referentiële integriteit nodig die een relationeel databasebeheersysteem (RDBMS) biedt. Elk team kan de beste optie voor de service kiezen.
Opmerking
Services kunnen veilig dezelfde fysieke databaseserver delen. Er treden problemen op wanneer services hetzelfde schema delen of ze lezen en schrijven naar dezelfde set databasetabellen.
Uitdagingen
De gedistribueerde benadering voor het beheren van gegevens brengt verschillende uitdagingen met zich mee. Ten eerste kan redundantie optreden in gegevensarchieven. Hetzelfde gegevensitem kan op meerdere plaatsen worden weergegeven. Gegevens kunnen bijvoorbeeld worden opgeslagen als onderdeel van een transactie en vervolgens ergens anders worden opgeslagen voor analyse, rapportage of archivering. Gedupliceerde of gepartitioneerde gegevens kunnen leiden tot problemen met gegevensintegriteit en consistentie. Wanneer gegevensrelaties meerdere services omvatten, kunnen traditionele technieken voor gegevensbeheer deze relaties niet afdwingen.
Traditionele gegevensmodellering volgt de regel van één feit op één plaats. Elke entiteit wordt precies één keer weergegeven in het schema. Andere entiteiten kunnen ernaar verwijzen, maar deze niet dupliceren. Het belangrijkste voordeel van de traditionele benadering is dat updates op één plaats plaatsvinden, waardoor problemen met gegevensconsistentie worden voorkomen. In een microservicesarchitectuur moet u overwegen hoe updates worden doorgegeven aan services en hoe u uiteindelijke consistentie kunt beheren wanneer gegevens op meerdere plaatsen worden weergegeven zonder sterke consistentie.
Benaderingen voor het beheren van gegevens
Geen enkele benadering werkt voor alle gevallen. Houd rekening met de volgende algemene richtlijnen voor het beheren van gegevens in een microservicesarchitectuur:
Definieer het vereiste consistentieniveau voor elk onderdeel en geef waar mogelijk de voorkeur aan uiteindelijke consistentie. Identificeer gebieden in het systeem waar u sterke consistentie of atomiciteit, consistentie, isolatie en duurzaamheid (ACID) transacties nodig hebt. En identificeer gebieden waar uiteindelijke consistentie acceptabel is. Voor meer informatie, zie Tactisch Domain-Driven Design (DDD) gebruiken voor microservices.
Gebruik één bron van waarheid wanneer u sterke consistentie nodig hebt. Eén service kan de bron van waarheid voor een bepaalde entiteit vertegenwoordigen en deze beschikbaar maken via een API. Andere services kunnen hun eigen kopie van de gegevens bevatten, of een subset van de gegevens, die uiteindelijk consistent zijn met de primaire gegevens, maar niet als de bron van waarheid worden beschouwd. In een e-commercesysteem met een klantenservice en een aanbevelingsservice kan de aanbevelingsservice bijvoorbeeld luisteren naar gebeurtenissen van de orderservice. Maar als een klant een restitutie aanvraagt, heeft de orderservice, niet de aanbevelingsservice, de volledige transactiegeschiedenis.
Pas transactiepatronen toe om consistentie tussen services te behouden. Gebruik patronen zoals Scheduler Agent Supervisor en Compenserende transactie om gegevens consistent te houden in meerdere services. Om gedeeltelijke fouten tussen meerdere services te voorkomen, moet u mogelijk een extra stukje gegevens opslaan waarmee de status van een werkeenheid wordt vastgelegd die meerdere services omvat. Houd bijvoorbeeld een werkitem in een duurzame wachtrij terwijl er een transactie met meerdere stappen wordt uitgevoerd.
Sla alleen de gegevens op die een service nodig heeft. Een service heeft mogelijk alleen een subset met informatie over een domeinentiteit nodig. In de context voor verzendingsgrens moet u bijvoorbeeld weten welke klant is gekoppeld aan een specifieke levering. Maar u hebt het factuuradres van de klant niet nodig omdat de bounded context van de accounts die informatie beheert. Zorgvuldige domeinanalyse en een DDD-benadering kunnen dit principe afdwingen.
Overweeg of uw services coherent en losjes gekoppeld zijn. Als twee services voortdurend informatie met elkaar uitwisselen en chatty API's maken, moet u mogelijk uw servicegrenzen opnieuw tekenen. Voeg de twee services samen of herstructureer hun functionaliteit.
Gebruik een gebeurtenisgestuurde architectuurstijl. In deze architectuurstijl publiceert een service een gebeurtenis wanneer wijzigingen in de openbare modellen of entiteiten plaatsvinden. Andere services kunnen zich abonneren op deze gebeurtenissen. Een andere service kan bijvoorbeeld de gebeurtenissen gebruiken om een gerealiseerde weergave te maken van de gegevens die geschikter zijn voor het uitvoeren van query's.
Publiceer een schema voor gebeurtenissen. Een service die eigenaar is van gebeurtenissen, moet een schema publiceren om serialisatie en deserialisatie van gebeurtenissen te automatiseren. Deze aanpak voorkomt nauwe koppeling tussen uitgevers en abonnees. Overweeg het JSON-schema of een framework zoals Protobuf of Avro.
Verminder knelpunten voor gebeurtenissen op schaal. Op grote schaal kunnen gebeurtenissen een knelpunt in het systeem worden. Overweeg om aggregatie of batchverwerking te gebruiken om de totale belasting te verminderen.
Voorbeeld: Gegevensarchieven kiezen voor de droneleveringstoepassing
In de vorige artikelen in deze reeks wordt een droneleveringsservice beschreven als een actief voorbeeld. Zie Een microservicesarchitectuur ontwerpen voor meer informatie over het scenario en de bijbehorende architectuur.
Om samen te vatten definieert deze toepassing verschillende microservices voor het plannen van leveringen per drone. Wanneer een gebruiker een nieuwe levering plant, bevat de clientaanvraag informatie over de levering, zoals ophaal- en afleverlocaties, en over het pakket, zoals grootte en gewicht. Deze informatie definieert een werkeenheid.
De verschillende back-endservices gebruiken verschillende delen van de informatie in de aanvraag en hebben verschillende lees- en schrijfprofielen.
Leveringsservice
De leveringsservice slaat informatie op over elke levering die momenteel wordt gepland of wordt uitgevoerd. Het luistert naar gebeurtenissen van de drones en houdt de status van leveringen in uitvoering bij. Er worden ook domeinevenementen met updates van de leveringsstatus verzonden.
Gebruikers controleren regelmatig de status van een levering terwijl ze wachten op hun pakket. De leveringsservice vereist dus een gegevensarchief dat de doorvoer (lezen en schrijven) over langetermijnopslag benadrukt. De bezorgdienst voert geen complexe zoekopdrachten of analyses uit. Alleen de meest recente status voor een specifieke levering wordt opgehaald. Het leveringsserviceteam heeft Azure Managed Redis gekozen voor de hoge lees-schrijfprestaties. De informatie die is opgeslagen in Azure Managed Redis, is kortstondig. Nadat een levering is voltooid, wordt de leveringsgeschiedenisservice het recordsysteem.
Leveringsgeschiedenisservice
De bezorggeschiedenisservice luistert naar statusgebeurtenissen van de bezorgservice. Deze gegevens worden opgeslagen in langetermijnopslag. Deze historische gegevens ondersteunen twee scenario's, elk met verschillende opslagvereisten.
In het eerste scenario worden gegevens voor gegevensanalyse samengevoegd om het bedrijf te optimaliseren of de servicekwaliteit te verbeteren. De leveringsgeschiedenisservice voert de werkelijke gegevensanalyse niet uit. De gegevens worden alleen opgenomen en opgeslagen. Voor dit scenario moet de opslag worden geoptimaliseerd voor gegevensanalyse via grote gegevenssets en moet een schema-on-read-benadering worden gebruikt voor verschillende gegevensbronnen. Azure Data Lake Storage is geschikt voor dit scenario omdat het een Apache Hadoop-bestandssysteem is dat compatibel is met Hadoop Distributed File System (HDFS). Het is ook afgestemd op prestaties voor scenario's voor gegevensanalyse.
In het tweede scenario kunnen gebruikers de geschiedenis van een levering opzoeken nadat de levering is voltooid. Data Lake Storage biedt geen ondersteuning voor dit scenario. Voor optimale prestaties slaat u tijdreeksgegevens op in Data Lake Storage in mappen die zijn gepartitioneerd op datum. Maar deze structuur maakt afzonderlijke op id's gebaseerde zoekacties inefficiënt. Tenzij u ook de tijdstempel kent, moet u voor een id-zoekopdracht de hele verzameling scannen. Om dit probleem op te lossen, slaat de leveringsgeschiedenisservice ook een subset op van de historische gegevens in Azure Cosmos DB voor snellere zoekopdrachten. De records hoeven niet voor onbepaalde tijd in Azure Cosmos DB te blijven. U kunt oudere leveringen archiveren na een bepaalde periode, zoals een maand, door een incidenteel batchproces uit te voeren. Het archiveren van gegevens kan de kosten voor Azure Cosmos DB verlagen en de gegevens beschikbaar houden voor historische rapportage vanuit Data Lake Storage.
Zie Data Lake Storage afstemmen voor prestaties voor meer informatie.
Pakketservice
De pakketservice slaat informatie over alle pakketten op. Het gegevensarchief voor de pakketservice moet voldoen aan de volgende vereisten:
- Langetermijnopslag
- Hoge schrijfdoorvoer voor het verwerken van een groot aantal pakketten
- Eenvoudige query's per pakket-id zonder complexe joins of beperkingen voor referentiële integriteit
De pakketgegevens zijn niet relationeel, dus een documentgerichte database werkt goed. Azure DocumentDB kan hoge doorvoer bereiken met behulp van shard-verzamelingen. Het pakketserviceteam is bekend met de MongoDB-, Express.js-, AngularJS- en Node.js-stack (MEAN), zodat ze Ervoor kiezen Om Azure DocumentDB te implementeren. Met deze keuze kunnen ze hun bestaande MongoDB-ervaring gebruiken terwijl ze profiteren van de voordelen van een volledig beheerde Azure-service met hoge prestaties.