Aanbevelingen voor ontwerpen voor eenvoud en efficiëntie

  • Artikel

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

RE:01 Ontwerp uw workload op basis van bedrijfsdoelstellingen en vermijd onnodige complexiteit of overhead. Gebruik een praktische en evenwichtige aanpak om ontwerpbeslissingen te nemen die de gewenste resultaten opleveren. Beperk uw ontwerp aan de benodigdheden 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. Als u uw ontwikkelings- en beheerlasten wilt verminderen, profiteert u van de efficiëntie die platformservices bieden. Met dit ontwerp kunt u een flexibele, herhaalbare, schaalbare en beheerbare workloadarchitectuur maken.

Definities

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

Belangrijke ontwerpstrategieën

Een belangrijk basisprincipe 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 van onnodige complexiteit of overtollige overhead te verminderen. Houd rekening met 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 kunnen verschillende vereisten hebben voor beschikbaarheid, schaalbaarheid, gegevensconsistentie en herstel na noodgevallen.

U moet elke ontwerpbeslissing rechtvaardigen met een bedrijfsvereiste. Dit ontwerpprincipe lijkt misschien voor de hand liggend, maar het is cruciaal voor het ontwerpen van workloads. Ondersteunt uw toepassing miljoenen gebruikers, of een paar duizend? Zijn er grote verkeerspieken of een constante werkbelasting? Welk niveau van toepassingsuitval is acceptabel? Zakelijke vereisten zijn de basis voor deze ontwerpoverwegingen.

Afweging: Een complexe oplossing kan meer functies en flexibiliteit bieden, maar kan de betrouwbaarheid van de workload beïnvloeden omdat er meer coördinatie, communicatie en beheer van onderdelen voor nodig zijn. Het is ook mogelijk dat een eenvoudigere oplossing niet volledig voldoet aan de verwachtingen van gebruikers of dat deze een negatief effect heeft op de schaalbaarheid en uitbreidbaarheid naarmate de workload zich ontwikkelt.

Gezamenlijke 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 bij het bepalen van de vereiste onderdelen en de beste aanpak om het vereiste tolerantieniveau te bereiken.

  • Definieer functionele en niet-functionele vereisten. Houd rekening met 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 hebt in niet-functionele vereisten, zoals schaalbaarheid, beschikbaarheid en latentie. Deze vereisten zijn van invloed op ontwerpbeslissingen en technologische keuzes.

  • Werkbelastingen opdelen in onderdelen. Geef prioriteit 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 aangaat en overweeg een onderdeel uit afzonderlijke stromen te verwijderen om het algehele ontwerp te vereenvoudigen en toch de volledige functionaliteit te bieden. Zie Aanbevelingen voor het uitvoeren van analyse van 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 te maken heeft met een grote natuurramp die alle beschikbaarheidszones in de regio treft. Het is duur en brengt aanzienlijke compromissen met zich mee om deze ongebruikelijke risico's te beperken. Inzicht in de risicotolerantie van uw bedrijf. Zie Aanbevelingen voor het uitvoeren van analyse van 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), serviceovereenkomsten (SLA's), gemiddelde hersteltijd (MTTR), gemiddelde tijd tussen storingen (MBTF), RTO's (Recovery Time Objectives) en RPO's (Recovery Point Objectives). 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 de bedrijfsdoelstellingen en realistisch zijn. Zie Aanbevelingen voor het definiëren van betrouwbaarheidsdoelen voor meer informatie.

Aanvullende ontwerpaanbeveling

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 over- of onder-engineering van uw oplossing. Als u uw code bijvoorbeeld opsplitst in meerdere kleine functies, is het moeilijk te begrijpen, te testen en te onderhouden.

  • Geef toe dat alle succesvolle toepassingen na verloop van tijd veranderen, of het nu gaat om het oplossen van fouten, het implementeren van nieuwe functies of technologieën, of het maken van bestaande systemen schaalbaarder en toleranter.

  • 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 berichtproducent 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 te dupliceren in verschillende functies en geef de voorkeur aan het hergebruik van services met goed gedefinieerde interfaces die eenvoudig kunnen worden gebruikt door verschillende onderdelen. Als bijvoorbeeld verschillende services 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 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 geschikt 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, gecomponenteerde workload de functionaliteit die een onderdeel biedt. Ontwikkel uw stromen om te profiteren van die functionaliteit. Houd rekening met deze aanbevelingen voor uw ontwikkelprocedures:

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

  • Bibliotheken en frameworks gebruiken.

  • Introduceer pair programming of toegewezen code review sessies als een ontwikkelpraktijk.

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

Het beste gegevensarchief voor uw gegevens gebruiken

In het verleden hebben veel organisaties al hun gegevens opgeslagen in grote relationele SQL-databases. Relationele databases bieden atomische, consistente, geïsoleerde en duurzame garanties (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 de prestaties beïnvloeden.

Alternatieven voor relationele databases

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

  • 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 Gegevensarchiefmodellen begrijpen voor meer informatie.

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

  • Maak gebruik van polyglot persistentie of oplossingen die gebruikmaken van een combinatie van technologieën voor gegevensopslag.

  • Houd rekening met het type gegevens dat u hebt. Bijvoorbeeld: opslaan:

    • 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-stelling. Maar u kunt een uiteindelijke consistentiemodel gebruiken om een hogere beschikbaarheid te bereiken.

  • Houd rekening met de vaardigheden van uw ontwikkelteam. Het gebruik van meertalige persistentie kent voordelen, maar u kunt ook te ver gaan. Het vereist nieuwe vaardigheden 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-persistentie kan één transactie gegevens naar meerdere winkels schrijven. Als er een fout opgetreden is, gebruikt u compenserende transacties om eventuele voltooide stappen ongedaan te maken.

  • Overweeg gebonden contexten, wat een domeingestuurd ontwerpconcept is. Een contextgrens is een expliciete grens rond een domeinmodel. Een gebonden context bepaalt op welke onderdelen van het domein het model van toepassing is. In het ideale geval wordt een contextgrens toegewezen op een subdomein van het bedrijfsdomein. Overweeg polyglot persistentie voor gebonden contexten in uw systeem. Producten kunnen bijvoorbeeld worden weergegeven in het subdomein van de productcatalogus en het subdomein van de productinventaris. Maar waarschijnlijk hebben deze twee subdomeinen verschillende vereisten voor het opslaan, bijwerken en uitvoeren van query's op 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 platform voor serverloze werkstroomintegratie 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 berichtdistributieservice voor publiceren/abonneren 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:

Voorbeeld

Zie Reliable Web App pattern (Betrouwbaar web-app-patroon) voor een voorbeeldworkload waarmee onderdelen en hun functies worden bepaald op basis van vereisten.

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor betrouwbaarheid