Delen via

Aanbevelingen voor het ontwerpen voor eenvoud en efficiëntie

  • Artikel

Is van toepassing op deze aanbeveling voor de controlelijst voor betrouwbaarheid van Azure Well-Architected Framework:

RE:01 Ontwerp uw workload om te voldoen aan bedrijfsdoelstellingen en vermijd onnodige complexiteit of overhead. Gebruik een praktische en evenwichtige benadering om ontwerpbeslissingen te nemen die de gewenste resultaten opleveren. Bevatten uw ontwerp aan de behoeften om inefficiënties en potentiële problemen te verminderen.

In deze handleiding worden de aanbevelingen beschreven voor het minimaliseren van onnodige complexiteit en overhead om uw workloads eenvoudig en efficiënt te houden. Kies de beste onderdelen om de benodigde workloadtaken uit te voeren om de betrouwbaarheid van uw workload te optimaliseren. Om uw ontwikkelings- en beheerlasten te verminderen, profiteert u van efficiëntie die door het platform geleverde services bieden. Dit ontwerp helpt u bij het maken van een workloadarchitectuur die tolerant, herhaalbaar, schaalbaar en beheerbaar is.

Definities

Termijn Definitie
Workload Een discrete mogelijkheid of computingtaak die u logisch kunt scheiden van andere taken.

Belangrijke ontwerpstrategieën

Een belangrijk tenet van het ontwerpen voor betrouwbaarheid is om dingen eenvoudig en efficiënt te houden. Richt uw workloadontwerp op het voldoen aan bedrijfsvereisten om het risico op onnodige complexiteit of overtollige overhead te verminderen. Bekijk de aanbevelingen in dit artikel om u te helpen beslissingen te nemen over uw ontwerp om een slanke, efficiënte en betrouwbare workload te creëren. Verschillende workloads hebben mogelijk verschillende vereisten voor beschikbaarheid, schaalbaarheid, gegevensconsistentie en herstel na noodgevallen.

U moet elke ontwerpbeslissing rechtvaardigen met een bedrijfsvereiste. Dit ontwerpprincipe lijkt misschien duidelijk, maar het is cruciaal voor het ontwerpen van workloads. Ondersteunt uw toepassing miljoenen gebruikers of een paar duizend? Zijn er grote verkeerspieken of een stabiele werkbelasting? Welk niveau van toepassingsstoring is acceptabel? Zakelijke vereisten stimuleren deze ontwerpoverwegingen.

Compromis: Een complexe oplossing kan meer functies en flexibiliteit bieden, maar dit kan van invloed zijn op de betrouwbaarheid van de workload omdat er meer coördinatie, communicatie en beheer van onderdelen nodig zijn. Een eenvoudigere oplossing voldoet mogelijk niet volledig aan de verwachtingen van gebruikers, of het kan een negatief effect hebben op schaalbaarheid en uitbreidbaarheid naarmate de workload zich ontwikkelt.

Samenwerken met belanghebbenden aan ontwerpoefeningen

Werk samen met belanghebbenden om:

  • Definieer en wijs een kritiek niveau toe aan de gebruikersstromen en systeemstromen van uw workload. Richt uw ontwerp op kritieke stromen om u te helpen de vereiste onderdelen en de beste benadering te bepalen om het vereiste tolerantieniveau te bereiken.

  • Functionele en niet-functionele vereisten definiëren. Overweeg functionele vereisten om te bepalen of een toepassing een taak uitvoert. Overweeg niet-functionele vereisten om te bepalen hoe goed de toepassing een taak uitvoert. Zorg ervoor dat u inzicht krijgt in niet-functionele vereisten, zoals schaalbaarheid, beschikbaarheid en latentie. Deze vereisten zijn van invloed op ontwerpbeslissingen en technologische keuzes.

  • Werkbelastingen opdelen in onderdelen. Prioriteit geven aan eenvoud, efficiëntie en betrouwbaarheid in uw ontwerp. Bepaal de onderdelen die u nodig hebt om uw stromen te ondersteunen. Sommige onderdelen ondersteunen meerdere stromen. Bepaal welke uitdaging een onderdeel conceptueel aanpakt en overweeg om een onderdeel uit afzonderlijke stromen te verwijderen om het algehele ontwerp te vereenvoudigen en tegelijkertijd volledige functionaliteit te bieden. Zie Aanbevelingen voor het uitvoeren van analyse van de foutmodus voor meer informatie.

  • Gebruik analyse van foutmodus om single points of failure en potentiële risico's te identificeren. Overweeg of u rekening moet houden met onwaarschijnlijke situaties, bijvoorbeeld een geografisch gebied dat een grote natuurramp ondervindt die van invloed is op alle beschikbaarheidszones in de regio. Het is duur en brengt aanzienlijke compromissen met zich mee om deze ongebruikelijke risico's te beperken. Begrijp de tolerantie van uw bedrijf voor risico's duidelijk. Zie Aanbevelingen voor het uitvoeren van analyse van de foutmodus voor meer informatie.

  • Definieer beschikbaarheids- en hersteldoelen voor uw stromen om de architectuur van uw workload te informeren. Zakelijke metrische gegevens omvatten serviceniveaudoelstellingen (SLO's), service level agreements (SLA's), gemiddelde tijd voor herstel (MTTR), gemiddelde tijd tussen storingen (MBTF), beoogde hersteltijd (RPO's) en beoogde herstelpunten (RPO's). Definieer doelwaarden voor deze metrische gegevens. Deze oefening vereist mogelijk compromissen en wederzijds begrip tussen technologie- en bedrijfsteams om ervoor te zorgen dat de doelstellingen van elk team voldoen aan bedrijfsdoelstellingen en realistisch zijn. Zie Aanbevelingen voor het definiëren van betrouwbaarheidsdoelen voor meer informatie.

De voorkeur geven aan eenvoudigere ontwerpkeuzen

U kunt de volgende aanbevelingen uitvoeren zonder betrokkenheid van belanghebbenden:

  • Streven naar eenvoud en duidelijkheid in uw ontwerp. Gebruik het juiste abstractie- en granulariteitsniveau voor uw onderdelen en services. Vermijd overengineering of under-engineering van uw oplossing. Als u uw code bijvoorbeeld opsplitst in meerdere kleine functies, is het moeilijk te begrijpen, te testen en te onderhouden.

  • Concede dat alle succesvolle toepassingen in de loop van de tijd veranderen, of fouten moeten worden opgelost, nieuwe functies of technologieën moeten worden geïmplementeerd of dat bestaande systemen schaalbaarder en toleranter worden.

  • Gebruik waar mogelijk PaaS-opties (Platform as a Service) in plaats van IaaS (Infrastructure as a Service). IaaS is vergelijkbaar met een doos met onderdelen. U kunt er alles mee maken, maar u moet het wel allemaal zelf doen. PaaS-opties zijn eenvoudiger te configureren en te beheren. U hoeft geen virtuele machines (VM's) of virtuele netwerken in te stellen. U hoeft ook geen onderhoudstaken uit te voeren, zoals het installeren van patches en updates.

  • Gebruik asynchrone berichten om de producent van berichten los te koppelen van de consument.

  • Isoleer infrastructuur van de domeinlogica. Zorg ervoor dat domeinlogica geen invloed heeft op infrastructuurgerelateerde functionaliteit, zoals berichten of persistentie.

  • Verplaats functies naar een afzonderlijke service om wederzijdse beïnvloeding te voorkomen. Minimaliseer de noodzaak om code over verschillende functies te dupliceren, waarbij u liever services hergebruikt met goed gedefinieerde interfaces die eenvoudig kunnen worden gebruikt door verschillende onderdelen. Als verschillende services bijvoorbeeld aanvragen moeten verifiëren, kunt u deze functionaliteit verplaatsen naar een eigen service. Vervolgens kunt u de verificatieservice ontwikkelen. U kunt bijvoorbeeld een nieuwe verificatiestroom toevoegen zonder de services aan te raken die deze gebruiken.

  • Evalueer de geschiktheid van algemene patronen en procedures voor uw behoeften. Vermijd het volgen van trends of aanbevelingen die mogelijk niet het beste zijn voor uw context of vereisten. Microservices zijn bijvoorbeeld niet de beste optie voor elke toepassing, omdat ze complexiteit, overhead en afhankelijkheidsproblemen kunnen veroorzaken.

Net genoeg code ontwikkelen

De principes van eenvoud, efficiëntie en betrouwbaarheid zijn ook van toepassing op uw ontwikkelprocedures. Bepaal in een losjes gekoppelde, gecomponentiseerde workload de functionaliteit die een onderdeel biedt. Ontwikkel uw stromen om te profiteren van die functionaliteit. Bekijk deze aanbevelingen voor uw ontwikkelprocedures:

  • Gebruik platformmogelijkheden wanneer ze voldoen aan uw bedrijfsvereisten. Als u bijvoorbeeld ontwikkeling en beheer wilt offloaden, gebruikt u weinig code, geen code of serverloze oplossingen die uw cloudprovider biedt.

  • Bibliotheken en frameworks gebruiken.

  • Introduceer paarprogrammeringssessies of speciale codebeoordelingssessies als een ontwikkelpraktijk.

  • Implementeer een benadering om dode code te identificeren. Wees sceptisch over de code die niet door uw geautomatiseerde tests wordt behandeld.

Het juiste gegevensarchief selecteren

In het verleden hebben veel organisaties al hun gegevens opgeslagen in grote relationele SQL-databases. Relationele databases bieden garanties voor atomische, consistente, geïsoleerde en duurzame (ACID) voor relationele gegevenstransacties. Maar deze databases hebben nadelen:

  • Query's kunnen dure joins vereisen.

  • U moet de gegevens normaliseren en herstructureren voor schema bij schrijven.

  • Vergrendelingsconflicten kunnen van invloed zijn op de prestaties.

Alternatieven voor relationele databases

In een grote oplossing voldoet één technologie voor gegevensopslag waarschijnlijk niet aan al uw behoeften. Alternatieven voor relationele databases zijn:

  • Sleutel-waardearchieven

  • Documentdatabases

  • Zoekprogrammadatabases

  • Tijdreeksdatabases

  • Kolomfamiliedatabases

  • Grafiekdatabases

Elke optie heeft voor- en nadelen. Verschillende gegevenstypen zijn beter geschikt voor verschillende typen gegevensarchieven. Kies de opslagtechnologie die het beste past bij uw gegevens en hoe u deze gebruikt.

U kunt bijvoorbeeld een productcatalogus opslaan in een documentdatabase, zoals Azure Cosmos DB, die ondersteuning biedt voor een flexibel schema. Elke productbeschrijving is een zelfstandig document. Voor query's in de hele catalogus kunt u de catalogus indexeren en de index opslaan in Azure Cognitive Search. Productinventaris kan naar een SQL-database gaan, omdat voor die gegevens ACID-garanties zijn vereist.

Aanbevelingen

  • Overweeg andere gegevensarchieven. Relationele databases zijn niet altijd geschikt. Zie Modellen voor gegevensopslag begrijpen voor meer informatie.

  • Houd er rekening mee dat gegevens meer dan alleen persistente toepassingsgegevens bevatten. Er zijn ook toepassingslogboeken, gebeurtenissen, berichten en caches.

  • Gebruik polyglot persistence of oplossingen die gebruikmaken van een combinatie van technologieën voor gegevensopslag.

  • Houd rekening met het type gegevens dat u hebt. Sla bijvoorbeeld het volgende op:

    • Transactionele gegevens in een SQL-database.

    • JSON-documenten in een documentdatabase.

    • Telemetrie in een tijdreeksdatabase.

    • Toepassingslogboeken in Azure Cognitive Search.

    • Blobs in Azure Blob Storage.

  • Prioriteit geven aan beschikbaarheid boven consistentie. De CAP-theorema impliceert dat u een afweging moet maken tussen beschikbaarheid en consistentie in een gedistribueerd systeem. U kunt netwerkpartities niet volledig vermijden. Dit is het andere onderdeel van de CAP-theorema. Maar u kunt een uiteindelijke consistentiemodel gebruiken om een hogere beschikbaarheid te bereiken.

  • Houd rekening met de vaardighedenset van uw ontwikkelteam. Het gebruik van meertalige persistentie kent voordelen, maar u kunt ook te ver gaan. Er zijn nieuwe vaardighedensets vereist om een nieuwe technologie voor gegevensopslag te gebruiken. Als u optimaal gebruik wilt maken van de technologie, moet uw ontwikkelteam het volgende doen:

    • Query's optimaliseren.

    • Afstemmen op prestaties.

    • Werk met de juiste gebruikspatronen.

Houd rekening met deze factoren wanneer u een opslagtechnologie kiest:

  • Compenserende transacties gebruiken. Met polyglot persistence kan één transactie gegevens naar meerdere winkels schrijven. Als er een fout optreedt, gebruikt u compenserende transacties om alle voltooide stappen ongedaan te maken.

  • Overweeg gebonden contexten, wat een domeingestuurd ontwerpconcept is. Een gebonden context is een expliciete grens rond een domeinmodel. Een gebonden context definieert op welke onderdelen van het domein waarop het model van toepassing is. In het ideale geval wordt een contextgrens toegewezen op een subdomein van het bedrijfsdomein. Overweeg polyglotpersistentie voor gebonden contexten in uw systeem. Producten kunnen bijvoorbeeld worden weergegeven in het subdomein van de productcatalogus en het subdomein voor productinventaris. Maar waarschijnlijk hebben deze twee subdomeinen verschillende vereisten voor het opslaan, bijwerken en opvragen van producten.

Azure-facilitering

Azure biedt de volgende services:

  • Azure Functions is een serverloze rekenservice die u kunt gebruiken om indeling met minimale code te bouwen.

  • Azure Logic Apps is een serverloos werkstroomintegratieplatform dat u kunt gebruiken om indeling te bouwen met een GUI of door een configuratiebestand te bewerken.

  • Azure Event Grid is een uiterst schaalbare, volledig beheerde service voor het distribueren van berichten met een publicatie-abonnement die flexibele patronen voor berichtverbruik biedt die gebruikmaken van de MQTT- en HTTP-protocollen. Met Event Grid kunt u gegevenspijplijnen bouwen met apparaatgegevens, gebeurtenisgestuurde serverloze architecturen bouwen en toepassingen integreren.

Zie voor meer informatie:

Opmerking

Zie het patroon Reliable Web App voor een voorbeeldworkload die onderdelen en de bijbehorende functies bepaalt op basis van vereisten.

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor betrouwbaarheid