Architectuurstijlen

Een architectuurstijl is een reeks architecturen die specifieke kenmerken delen. N-laag is bijvoorbeeld een algemene architectuurstijl. Recenter beginnen microservicearchitecturen voordeel te krijgen. Architectuurstijlen vereisen geen gebruik van specifieke technologieën, maar sommige technologieën zijn beter geschikt voor bepaalde architecturen. Containers zijn bijvoorbeeld geschikt voor microservices.

We hebben een set architectuurstijlen geïdentificeerd die vaak worden gevonden in cloudtoepassingen. Het artikel voor elke stijl bevat de volgende onderdelen:

• Een beschrijving en logisch diagram van de stijl
• Aanbevelingen voor het kiezen van deze stijl
• Voordelen, uitdagingen en best practices
• Een aanbevolen implementatie die gebruikmaakt van relevante Azure-services

Een korte rondleiding door de stijlen

In deze sectie vindt u een korte rondleiding door de architectuurstijlen die we hebben geïdentificeerd, samen met enkele overwegingen op hoog niveau voor het gebruik ervan. Deze lijst is niet volledig. Lees meer informatie in de gekoppelde artikelen.

N-laag

Het diagram illustreert de gelaagde structuur van een N-laag-architectuur met duidelijke scheiding tussen onderdelen. Clientaanvragen worden ingevoerd via een Web Application Firewall (WAF) die beveiligingsfilters biedt voordat de weblaag wordt bereikt. De weblaag fungeert als de presentatielaag. Het verwerkt gebruikersinteracties en routeringsaanvragen naar de juiste bedrijfslogica-onderdelen. Twee verschillende verwerkingspaden komen uit de weblaag: één pad loopt rechtstreeks naar de middelste laag één voor synchrone bewerkingen, terwijl een ander pad gebruikmaakt van een berichteninfrastructuur om te communiceren met de middelste laag twee voor asynchrone verwerking. Beide middelste lagen vertegenwoordigen bedrijfslogicalagen die aanvragen verwerken en communiceren met de gegevenslaag via cachingmechanismen om de prestaties te optimaliseren. De gegevenslaag fungeert als de basis. Hiermee worden toepassingsgegevens opgeslagen en beheerd en worden beide middelste lagen ondersteund via patronen voor gegevenstoegang in de cache.

N-laag is een traditionele architectuur voor bedrijfstoepassingen die een toepassing opsplitsen in logische lagen en fysieke lagen. Elke laag heeft een specifieke verantwoordelijkheid en lagen beheren afhankelijkheden door alleen onderliggende lagen aan te roepen. Typische lagen zijn presentatie, bedrijfslogica en gegevenstoegang.

N-tier architecturen zijn geschikt voor het migreren van bestaande toepassingen die al gebruikmaken van een gelaagde architectuur. Deze aanpak vereist minimale wijzigingen wanneer u overstapt naar Azure en ondersteuning biedt voor gemengde omgevingen met zowel on-premises als cloudonderdelen. Maar de horizontale lagen kunnen het moeilijk maken om wijzigingen in te voeren zonder dat dit van invloed is op meerdere onderdelen van de toepassing, waardoor de flexibiliteit voor frequente updates wordt beperkt.

Web-Queue-Worker

Het diagram toont een schone scheiding tussen gebruikersgerichte en achtergrondverwerkingsonderdelen. Clientinteracties beginnen met verificatie via een id-provider voordat ze de webfront-end bereiken, die fungeert als de primaire gebruikersinterface. De webfront-end onderhoudt drie afzonderlijke operationele relaties: deze kan rechtstreeks communiceren met externe services voor externe integraties, toegang krijgen tot de database voor directe gegevensbewerkingen en werkitems in de wachtrij zetten voor achtergrondverwerking. De wachtrij fungeert als een ontkoppelingsmechanisme. Hiermee kan het werkonderdeel resource-intensieve of langlopende taken onafhankelijk van gebruikersaanvragen verwerken. De worker haalt taken op uit de wachtrij en voert bewerkingen uit op de database, met een cache-infrastructuur die ondersteuning biedt voor zowel de webfront-end als de worker voor geoptimaliseerde gegevenstoegang. Statische inhoud wordt ook gedistribueerd via een CDN (Content Delivery Network) om de prestaties voor clienttoepassingen te verbeteren.

Web-Queue-Worker is een architectuur die bestaat uit een webfront-end, een berichtenwachtrij en een back-end worker. De webfront-end verwerkt HTTP-aanvragen en gebruikersinteracties, terwijl de werkrol resource-intensieve taken, langlopende werkstromen of batchbewerkingen uitvoert. Communicatie tussen de front-end en worker vindt plaats via een asynchrone berichtenwachtrij.

Deze architectuur is ideaal voor toepassingen met relatief eenvoudige domeinen die een aantal resource-intensieve verwerkingsvereisten hebben. Het is eenvoudig te begrijpen en te implementeren met beheerde Azure-services, zoals App Service en Azure Functions. U kunt de front end en de worker onafhankelijk van elkaar schalen om flexibiliteit in de toewijzing van middelen te bieden. Maar zonder zorgvuldig ontwerp kunnen beide onderdelen groot en monolithisch worden.

Microservices

In het diagram ziet u een gedistribueerde microservicesarchitectuur die is ingedeeld in afzonderlijke functionele lagen. Aan de linkerkant starten clienttoepassingen en externe systemen aanvragen die via een gecentraliseerde API-gateway stromen, die fungeert als het enige toegangspunt en routeringsmechanisme voor het hele systeem. De API-gateway stuurt aanvragen door naar de juiste microserviceslaag, die meerdere servicetypen bevat: domeinservices die specifieke bedrijfsmogelijkheden inkapselen, samenstellingsservices die interacties tussen domeinservices organiseren en afzonderlijke services die discrete functies verwerken. Elke microservice behoudt gegevensautonomie door middel van een eigen toegewezen database. In het diagram ziet u een polyglot persistence-benadering met zowel SQL- als NoSQL-databases die zijn afgestemd op de specifieke gegevensvereisten van elke service. De microservices communiceren asynchroon via berichtgeoriënteerde middleware. Met deze benadering kunt u losse koppeling maken door patronen voor publiceren-abonneren en gebeurtenisgestuurde interacties te gebruiken. Drie basisinfrastructuurlagen ondersteunen deze gedistribueerde architectuur: waarneembaarheidssystemen bieden uitgebreide bewaking, logboekregistratie en gedistribueerde tracering over servicegrenzen. Beheer- en indelingsplatformen verwerken geautomatiseerde implementatie, schaalaanpassing en servicedetectie. DevOps-hulpprogrammaketens maken continue integratie, testen en leveringspijplijnen mogelijk voor onafhankelijke service-implementaties.

De Microservices-architectuur ontleden toepassingen in een verzameling kleine, autonome services. Elke service implementeert één bedrijfsmogelijkheid binnen een gebonden context en is zelfstandig met een eigen gegevensopslag. Services communiceren via goed gedefinieerde API's en kunnen onafhankelijk worden ontwikkeld, geïmplementeerd en geschaald.

Met microservices kunnen teams autonoom werken en frequente updates ondersteunen met een hogere releasesnelheid. Deze architectuur is zeer geschikt voor complexe domeinen waarvoor frequente wijzigingen en innovatie nodig zijn. Maar het introduceert een aanzienlijke complexiteit op gebieden zoals servicedetectie, gegevensconsistentie en gedistribueerd systeembeheer. Succes vereist volwassen ontwikkeling en DevOps-procedures, waardoor het beter geschikt is voor organisaties met geavanceerde technische mogelijkheden.

Gebeurtenisafhankelijke architectuur

Het diagram illustreert een ontkoppeld, asynchroon communicatiepatroon dat fundamenteel is voor gebeurtenisgestuurde architecturen. Meerdere gebeurtenisproducenten werken onafhankelijk. De gegenereerde stromen van gebeurtenissen, gebaseerd op bedrijfsactiviteiten, gebruikersinteracties of systeemstatuswijzigingen, zonder enige kennis van afnemers downstream. De producenten voeren hun gebeurtenissen door in een gecentraliseerd systeem voor opname van gebeurtenissen dat fungeert als een intelligente broker. De broker ontvangt, valideert, persisteert en distribueert gebeurtenissen betrouwbaar over de architectuur. Het onderdeel voor gebeurtenisopname fungeert als een kritiek ontkoppelingspunt. Het zorgt ervoor dat producenten geïsoleerd blijven van consumenten, terwijl het garanties biedt voor het leveren, bestellen en duurzaamheid van gebeurtenissen. Vanuit deze centrale hub worden gebeurtenissen gedistribueerd via een fan-outpatroon naar meerdere onafhankelijke gebeurtenisgebruikers die aan de rechterkant van het diagram zijn geplaatst. Elke consument vertegenwoordigt een afzonderlijke bedrijfsmogelijkheid of -service die zich abonneert op specifieke gebeurtenistypen die relevant zijn voor de verantwoordelijkheden van het domein. De consumenten verwerken gebeurtenissen asynchroon en parallel, waardoor het systeem horizontaal kan schalen terwijl losse koppeling behouden blijft. Dit architectuurpatroon verwijdert directe afhankelijkheden tussen producenten en consumenten. Hiermee kan elk onderdeel onafhankelijk evolueren, opschalen en implementeren, terwijl systeemveerkracht wordt gehandhaafd via de buffer- en herstelmogelijkheden van de event broker.

Gebeurtenisgestuurde architecturen maken gebruik van een model voor publiceren/abonneren, waarbij gebeurtenisproducenten streams van gebeurtenissen genereren en gebeurtenisconsumenten in bijna realtime reageren op deze gebeurtenissen. Producenten en consumenten worden losgekoppeld van elkaar, met communicatie via gebeurteniskanalen of brokers. Deze architectuur ondersteunt zowel eenvoudige gebeurtenisverwerking als complexe analyse van gebeurtenispatronen.

Gebeurtenisgestuurde architecturen excelleren in scenario's waarvoor realtime verwerking met minimale latentie is vereist. Enkele voorbeelden zijn IoT-oplossingen, financiële handelssystemen of toepassingen die grote hoeveelheden streaminggegevens moeten verwerken. Gebeurtenisgestuurde architecturen bieden uitstekende schaalbaarheid en foutisolatie, maar veroorzaken uitdagingen met betrekking tot gegarandeerde levering, gebeurtenisvolgorde en uiteindelijke consistentie tussen gedistribueerde onderdelen.

Big Data

Het diagram toont een uitgebreide big data-architectuur met twee complementaire verwerkingspijplijnen die verschillende gegevenssnelheden en analytische vereisten verwerken. De pijplijn voor batchverwerking begint met diverse gegevensbronnen die worden ingevoerd in schaalbare gegevensopslagsystemen, meestal data lakes of gedistribueerde bestandssystemen die grote hoeveelheden gestructureerde, semi-gestructureerde en ongestructureerde gegevens kunnen opslaan. Het batchverwerkingsonderdeel voert grootschalige transformaties, aggregaties en analytische berekeningen uit op de historische gegevens. Het werkt op geplande intervallen of wanneer er voldoende gegevens worden verzameld. Resultaten van batchverwerkingsstroom via twee paden: rechtstreeks naar analyse- en rapportagesystemen voor direct verbruik en naar analytische gegevensarchieven waar verwerkte gegevens worden bewaard in geoptimaliseerde indelingen voor complexe query's en historische analyse. Tegelijkertijd legt de realtime verwerkingspijplijn streaminggegevens vast via realtime berichtenopnamesystemen die gegevensstromen van hoge snelheid verwerken uit bronnen zoals IoT-apparaten, webtoepassingen of transactionele systemen. Streamverwerkingsonderdelen analyseren deze gegevens in beweging, waarbij realtime aggregaties, filters en patroondetectie worden uitgevoerd om onmiddellijke inzichten te genereren. De realtime resultaten volgen ook dubbele paden, die zowel rechtstreeks worden ingevoerd in analyses als rapportage voor directe dashboards en waarschuwingen, en in dezelfde analytische gegevensarchieven om een uniforme weergave te maken waarin historische en huidige gegevens worden gecombineerd. De orkestratielaag omvat beide pijplijnen. Het coördineert complexe werkstromen, beheert afhankelijkheden tussen batch- en streamingtaken, plant verwerkingstaken en zorgt voor gegevensconsistentie in de hele architectuur. Met deze indeling kunt u lambda-architecturen maken waarbij zowel batchverwerking als realtime verwerking op dezelfde gegevenssets kan worden uitgevoerd, wat zowel uitgebreide historische analyse als onmiddellijke operationele intelligentie biedt.

Big data-architecturen verwerken de opname, verwerking en analyse van gegevens die te groot of complex zijn voor traditionele databasesystemen. Deze architecturen omvatten doorgaans onderdelen voor gegevensopslag (zoals data lakes), batchverwerking voor historische analyse, stroomverwerking voor realtime inzichten en analytische gegevensarchieven voor rapportage en visualisatie.

Big data-architecturen zijn essentieel voor organisaties die inzichten moeten extraheren uit enorme gegevenssets, predictive analytics ondersteunen met behulp van machine learning of realtime streaminggegevens van IoT-apparaten moeten verwerken. Moderne implementaties maken vaak gebruik van beheerde services zoals Microsoft Fabric om de complexiteit van het bouwen en onderhouden van big data-oplossingen te vereenvoudigen.

Grote Rekencapaciteit

Het diagram illustreert een geavanceerd taakdistributie- en besturingssysteem dat is ontworpen voor high-performance computing-werklasten. Op het toegangspunt verzenden clienttoepassingen rekenintensieve taken via een taakwachtrijinterface die fungeert als buffer- en intakemechanisme voor binnenkomende werkaanvragen. De taken stromen over in een gecentraliseerd scheduler- of coördinatoronderdeel dat fungeert als het intelligente brein van het systeem, verantwoordelijk voor het analyseren van taakkenmerken, resourcevereisten en rekenafhankelijkheden. De scheduler voert kritieke functies uit, waaronder taakontleding, resourcetoewijzingsplanning en workloadoptimalisatie op basis van beschikbare rekenresources en taakafhankelijkheden. Vanaf dit centrale coördinatiepunt werkt de planner op intelligente wijze langs twee verschillende bewerkingspaden op basis van de rekenkundige kenmerken van elke taak. Het eerste traject leidt werk naar omgevingen voor parallelle taakafhandeling die zijn ontworpen voor gênante parallelle workloads waar afzonderlijke taken onafhankelijk kunnen worden uitgevoerd zonder dat er communicatie tussen verwerkingseenheden nodig is. Deze parallelle taken worden tegelijkertijd verdeeld over honderden of duizenden kernen, waarbij elke kern afzonderlijke werkeenheden in isolatie verwerkt. Het tweede pad verwerkt nauw gekoppelde taken waarvoor regelmatige communicatie tussen processen, gedeelde geheugentoegang of gesynchroniseerde bewerkingspatronen is vereist. Deze nauw gekoppelde workloads maken doorgaans gebruik van snelle interconnects zoals InfiniBand- of RDMA-netwerken (Remote Direct Memory Access) om snelle gegevensuitwisseling tussen verwerkingsknooppunten mogelijk te maken. De scheduler bewaakt continu beide bewerkingsomgevingen, beheert resourcetoewijzing, verwerkt fouttolerantie en optimaliseert de prestaties door de verdeling van werk dynamisch aan te passen op basis van systeemcapaciteit, taakprioriteiten en voltooiingsvereisten. Met de bifurcated benadering kan de architectuur efficiënt diverse rekenworkloads verwerken en tegelijkertijd het gebruik van resources in de hele computerinfrastructuur maximaliseren.

Big compute-architecturen ondersteunen grootschalige workloads waarvoor honderden of duizenden kernen nodig zijn voor rekenintensieve bewerkingen. Het werk kan worden gesplitst in discrete taken die tegelijkertijd op veel kernen worden uitgevoerd, waarbij elke taak invoer neemt, verwerkt en uitvoer produceert. Taken kunnen onafhankelijk (gênant parallel) of nauw gekoppeld zijn waarvoor snelle communicatie vereist is.

Big compute is essentieel voor simulaties, financiële risicomodellering, wetenschappelijke computing, technische stressanalyse en 3D-rendering. Azure biedt opties zoals Azure Batch voor beheerde big compute-workloads of HPC Pack voor meer traditioneel clusterbeheer. Deze architecturen kunnen de capaciteit op aanvraag bursten en naar duizenden kernen schalen wanneer dat nodig is.

Architectuurstijlen als beperkingen

Een architectuurstijl plaatst beperkingen op het ontwerp, inclusief de set elementen die kunnen worden weergegeven en de toegestane relaties tussen deze elementen. Beperkingen begeleiden de 'vorm' van een architectuur door het universum van keuzes te beperken. Wanneer een architectuur voldoet aan de beperkingen van een bepaalde stijl, komen bepaalde wenselijke eigenschappen voor.

De beperkingen in microservices zijn bijvoorbeeld:

• Een service vertegenwoordigt één verantwoordelijkheid.
• Elke service is onafhankelijk van de andere services.
• Gegevens zijn privé voor de service die eigenaar is van de gegevens. Services delen geen gegevens.

Wanneer u aan deze beperkingen voldoet, krijgt u een systeem waarmee u de volgende acties kunt uitvoeren:

• Services onafhankelijk implementeren.
• Fouten isoleren.
• Voer vaker updates uit.
• Introduceer eenvoudiger nieuwe technologieën in de toepassing.

Elke architectuurstijl heeft zijn eigen compromissen. Voordat u een architectuurstijl kiest, is het essentieel om de onderliggende principes en beperkingen te begrijpen. Zonder dat begrip riskeert u een ontwerp te creëren dat oppervlakkig voldoet aan de stijl zonder de volledige voordelen ervan te realiseren. Richt u meer op waarom u een specifieke stijl selecteert dan hoe u deze implementeert. Wees praktisch. Soms is het beter om een beperking te versoepelen dan om architecturale zuiverheid na te streven.

In het ideale geval moet de keuze van de architectuurstijl worden gemaakt met input van goed geïnformeerde belanghebbenden. Het workloadteam moet beginnen met het identificeren van de aard van het probleem dat ze oplossen. Ze moeten vervolgens de belangrijkste zakelijke stuurprogramma's en de bijbehorende architectuurkenmerken definiëren, ook wel niet-functionele vereisten genoemd, en ze prioriteren. Als de markttijd bijvoorbeeld essentieel is, kan het team prioriteit geven aan onderhoudbaarheid, testbaarheid en betrouwbaarheid om snelle implementatie mogelijk te maken. Als het team strikte budgetbeperkingen heeft, kunnen haalbaarheid en eenvoud voorrang krijgen. Het selecteren en onderhouden van een architectuurstijl is geen eenmalige taak. Hiervoor is doorlopende meting, validatie en verfijning vereist. Omdat het later kostbaar kan zijn om de architectuurrichting te veranderen, is het vaak de moeite waard om vooraf meer inspanning te investeren om efficiëntie op de lange termijn te ondersteunen en risico's te verminderen.

De volgende tabel bevat een overzicht van de manier waarop elke stijl afhankelijkheden beheert en de typen domeinen die het meest geschikt zijn voor elke stijl.

Architectuurstijl	Beheer van afhankelijkheden	Domeintype
N-laag	Horizontale lagen verdeeld door het subnet	Traditioneel bedrijfsdomein. Frequentie van updates is laag.
Web-Queue-Worker	Front-end- en back-endtaken, losgekoppeld door asynchrone berichten.	Relatief eenvoudig domein met een aantal resource-intensieve taken.
Microdiensten	Verticaal (functioneel) uitgevouwen services die elkaar aanroepen via API's.	Gecompliceerd domein. Regelmatige updates.
Gebeurtenisgestuurde architectuur	Producent of consument. Onafhankelijke weergave voor elk subsysteem.	Internet of Things (IoT) en realtime systemen.
Grote gegevens	Verdeel een enorme gegevensset in kleine segmenten. Parallelle verwerking van lokale gegevenssets.	Batch- en realtime gegevensanalyse. Voorspellende analyse met behulp van machine learning.
Grote rekenkracht	Gegevenstoewijzing naar duizenden kernen.	Rekenintensieve domeinen zoals simulatie.

Houd rekening met uitdagingen en voordelen

Beperkingen zorgen ook voor uitdagingen, dus het is belangrijk om inzicht te krijgen in de afwegingen wanneer u een van deze stijlen gebruikt. Bepaal of de voordelen van de architectuurstijl opwegen tegen de uitdagingen, voor dit subdomein en gebonden context.

Houd rekening met de volgende typen uitdagingen wanneer u een architectuurstijl selecteert:

• Complexiteit: De complexiteit van de architectuur moet overeenkomen met het domein. Als het te simplistisch is, kan het resulteren in een grote bal modder, waarbij afhankelijkheden niet goed worden beheerd en de structuur afbreekt.

• Asynchrone berichten en uiteindelijke consistentie: Asynchrone berichten worden gebruikt om services los te koppelen en de betrouwbaarheid te verbeteren, omdat berichten opnieuw kunnen worden geprobeerd. Het verbetert ook de schaalbaarheid. Asynchrone berichten creëren echter ook uitdagingen bij het afhandelen van uiteindelijke consistentie en de mogelijkheid van dubbele berichten.

• Communicatie tussen services: Het opsplitsen van een toepassing in afzonderlijke services kan de communicatieoverhead verhogen. In microservicesarchitecturen leidt deze overhead vaak tot latentieproblemen of netwerkcongestie.

• Meegaandheid: Het beheren van de toepassing omvat taken zoals bewaking, het implementeren van updates en het onderhouden van de operationele status.

Verwante middelen

• Ten ontwerpprincipes voor Azure-toepassingen

Volgende stappen

• Toepassingen bouwen in de Microsoft Cloud
• Best practices voor cloudtoepassingen
• Cloudontwerppatronen
• Prestatietests en antipatronen voor cloudtoepassingen
• Multitenant-oplossingen ontwerpen in Azure
• Bedrijfskritieke workloadarchitectuur in Azure
• Architectuur voor start-ups