Rekommendationer för design för enkelhet och effektivitet

  • Artikel

Gäller för denna checklista för Azure Well-Architected Framework Reliability:

RE:01 Utforma din arbetsbelastning så att den överensstämmer med affärsmålen och undvik onödig komplexitet eller omkostnader. Använd en praktisk och balanserad metod för att fatta designbeslut som ger önskat resultat. Begränsa designen till nödvändigheterna för att minska ineffektiviteten och potentiella problem.

Den här guiden beskriver rekommendationerna för att minimera onödig komplexitet och omkostnader för att hålla dina arbetsbelastningar enkla och effektiva. Välj de bästa komponenterna för att utföra nödvändiga arbetsbelastningsuppgifter för att optimera arbetsbelastningens tillförlitlighet. För att minska dina utvecklings- och hanteringsbördor kan du dra nytta av de effektivitetsvinster som tjänster som tillhandahålls av plattformen erbjuder. Den här designen hjälper dig att skapa en arbetsbelastningsarkitektur som är elastisk, repeterbar, skalbar och hanterbar.

Definitioner

Period Definition
Arbetsbelastning En diskret funktions- eller beräkningsuppgift som du logiskt kan separera från andra uppgifter.

Viktiga designstrategier

En viktig grundsats i designen för tillförlitlighet är att hålla det enkelt och effektivt. Fokusera din arbetsbelastningsdesign på att uppfylla affärskraven för att minska risken för onödig komplexitet eller överbelastning. Överväg rekommendationerna i den här artikeln för att hjälpa dig att fatta beslut om din design för att skapa en mager, effektiv och tillförlitlig arbetsbelastning. Olika arbetsbelastningar kan ha olika krav för tillgänglighet, skalbarhet, datakonsekvens och haveriberedskap.

Du måste motivera varje designbeslut med ett affärskrav. Den här designprincipen kan verka uppenbar, men den är avgörande för arbetsbelastningsdesignen. Har ditt program stöd för miljontals användare eller några tusen? Finns det stora trafiktoppar eller en stadig arbetsbelastning? Vilken nivå av programstopp är acceptabel? Affärskrav driver dessa designöverväganden.

Kompromiss: En komplex lösning kan erbjuda fler funktioner och flexibilitet, men den kan påverka arbetsbelastningens tillförlitlighet eftersom den kräver mer samordning, kommunikation och hantering av komponenter. Alternativt kanske en enklare lösning inte helt uppfyller användarnas förväntningar, eller så kan den ha en negativ effekt på skalbarheten och utökningsbarheten när arbetsbelastningen utvecklas.

Samarbetsdesignövningar

Arbeta med intressenter för att:

  • Definiera och tilldela en kritiskhetsnivå till arbetsbelastningens användarflöden och systemflöden. Fokusera din design på kritiska flöden som hjälper dig att avgöra vilka komponenter som krävs och den bästa metoden för att uppnå den återhämtningsnivå som krävs.

  • Definiera funktionella och icke-funktionella krav. Överväg funktionskrav för att avgöra om ett program utför en uppgift. Överväg icke-funktionella krav för att avgöra hur väl programmet utför en uppgift. Se till att du förstår icke-funktionella krav som skalbarhet, tillgänglighet och svarstid. Dessa krav påverkar designbeslut och teknikval.

  • Dela upp arbetsbelastningar i komponenter. Prioritera enkelhet, effektivitet och tillförlitlighet i din design. Fastställ de komponenter som du behöver för att stödja dina flöden. Vissa komponenter stöder flera flöden. Identifiera vilken utmaning en komponent konceptuellt hanterar och överväg att ta bort en komponent från enskilda flöden för att förenkla den övergripande designen samtidigt som den ger fullständig funktionalitet. Mer information finns i Rekommendationer för analys av felläge.

  • Använd analys av felläge för att identifiera enskilda felpunkter och potentiella risker. Överväg om du behöver ta hänsyn till osannolika situationer, till exempel ett geografiskt område som drabbas av en större naturkatastrof som påverkar alla tillgänglighetszoner i regionen. Det är dyrt och innebär betydande kompromisser för att minimera dessa ovanliga risker. Förstå tydligt ditt företags risktolerans. Mer information finns i Rekommendationer för analys av felläge.

  • Definiera tillgänglighets- och återställningsmål för dina flöden för att informera din arbetsbelastnings arkitektur. Affärsmått omfattar servicenivåmål (SLO), serviceavtal (SLA), genomsnittlig tid för återställning (MTTR), genomsnittlig tid mellan fel (MTBF), mål för återställningstid (RTO) och mål för återställningspunkter (RPC). Definiera målvärden för dessa mått. Den här övningen kan kräva kompromisser och ömsesidig förståelse mellan teknik- och affärsteam för att säkerställa att varje teams mål uppfyller affärsmålen och är realistiska. Mer information finns i Rekommendationer för att definiera tillförlitlighetsmål.

Ytterligare designrekommendationer

Du kan utföra följande rekommendationer utan intressentengagemang:

  • Sträva efter enkelhet och tydlighet i din design. Använd lämplig abstraktionsnivå och kornighet för dina komponenter och tjänster. Undvik överengineering eller underutveckling av din lösning. Om du till exempel delar upp koden i flera små funktioner är det svårt att förstå, testa och underhålla.

  • Medge att alla lyckade program ändras över tid, oavsett om de ska åtgärda buggar, implementera nya funktioner eller tekniker eller göra befintliga system mer skalbara och motståndskraftiga.

  • Använd PaaS-alternativ (plattform som en tjänst) i stället för infrastruktur som en tjänst (IaaS) när det är möjligt. IaaS är som att ha en låda fyll med delar. Du kan skapa vad som helst, men du måste sätta ihop det själv. PaaS-alternativ är enklare att konfigurera och administrera. Du behöver inte konfigurera virtuella datorer eller virtuella nätverk. Du behöver inte heller utföra underhållsaktiviteter, till exempel att installera korrigeringar och uppdateringar.

  • Använd asynkrona meddelanden för att frikoppla meddelandeproducenten från konsumenten.

  • Abstrakt infrastruktur separat från domänlogiken. Se till att domänlogik inte stör infrastrukturrelaterade funktioner, till exempel meddelanden eller beständighet.

  • Avlasta övergripande frågor till en separat tjänst. Minimera behovet av att duplicera kod mellan olika funktioner, föredra återanvändning av tjänster med väldefinierade gränssnitt som enkelt kan användas av olika komponenter. Om flera tjänster till exempel behöver autentisera begäranden kan du flytta den här funktionen till en egen tjänst. Sedan kan du utveckla autentiseringstjänsten. Du kan till exempel lägga till ett nytt autentiseringsflöde utan att röra någon av de tjänster som använder det.

  • Utvärdera lämpligheten för vanliga mönster och metoder för dina behov. Undvik att följa trender eller rekommendationer som kanske inte passar din kontext eller dina krav bäst. Mikrotjänster är till exempel inte det bästa alternativet för varje program eftersom de kan medföra problem med komplexitet, omkostnader och beroenden.

Utveckla precis tillräckligt med kod

Principerna för enkelhet, effektivitet och tillförlitlighet gäller även för dina utvecklingsmetoder. I en löst kopplad, komponentiserad arbetsbelastning fastställer du vilka funktioner en komponent tillhandahåller. Utveckla dina flöden för att dra nytta av den funktionen. Överväg dessa rekommendationer för dina utvecklingsmetoder:

  • Använd plattformsfunktioner när de uppfyller dina affärskrav. Om du till exempel vill avlasta utveckling och hantering använder du lösningar med låg kod, ingen kod eller serverlösa lösningar som molnleverantören erbjuder.

  • Använd bibliotek och ramverk.

  • Introducera parprogrammering eller dedikerade kodgranskningssessioner som en utvecklingspraxis.

  • Implementera en metod för att identifiera död kod. Var skeptisk till koden som dina automatiserade tester inte täcker.

Använda det bästa datalagret för dina data

Tidigare lagrade många organisationer alla sina data i stora relationsbaserade SQL-databaser. Relationsdatabaser ger atomiska, konsekventa, isolerade och varaktiga (ACID) garantier för relationsdatatransaktioner. Men dessa databaser har nackdelar:

  • Frågor kan kräva dyra kopplingar.

  • Du måste normalisera data och strukturera om dem för schema vid skrivning.

  • Låskonkurration kan påverka prestanda.

Alternativ till relationsdatabaser

I en stor lösning uppfyller förmodligen inte en enda datalagerteknik alla dina behov. Alternativ till relationsdatabaser är:

  • Nyckelvärdeslager

  • Dokumentdatabaser

  • Sökmotordatabaser

  • Tidsseriedatabaser

  • Kolumnfamiljedatabaser

  • Grafdatabaser

Varje alternativ har för- och nackdelar. Olika datatyper passar bättre för olika typer av datalager. Välj den lagringsteknik som passar bäst för dina data och hur du använder dem.

Du kan till exempel lagra en produktkatalog i en dokumentdatabas, till exempel Azure Cosmos DB, som stöder ett flexibelt schema. Varje produktbeskrivning är ett självständigt dokument. För frågor över hela katalogen kan du indexisera katalogen och lagra indexet i Azure Cognitive Search. Produktinventeringen kan gå till en SQL-databas eftersom dessa data kräver ACID-garantier.

Rekommendationer

  • Överväg andra datalager. Relationsdatabaser är inte alltid lämpliga. Mer information finns i Förstå datalagermodeller.

  • Kom ihåg att data innehåller mer än bara sparade programdata. De innehåller också programloggar, händelser, meddelanden och cacheminnen.

  • Använd flerspråkig beständighet eller lösningar som använder en kombination av datalagertekniker.

  • Överväg vilken typ av data du har. Lagra till exempel:

    • Transaktionsdata i en SQL-databas.

    • JSON-dokument i en dokumentdatabas.

    • Telemetri i en tidsseriedatabas.

    • Programloggar i Azure Cognitive Search.

    • Blobbar i Azure Blob Storage.

  • Prioritera tillgänglighet framför konsekvens. CAP-satsen innebär att du måste göra kompromisser mellan tillgänglighet och konsekvens i ett distribuerat system. Du kan inte helt undvika nätverkspartitioner, vilket är den andra komponenten i CAP-satsen. Men du kan använda en slutlig konsekvensmodell för att uppnå högre tillgänglighet.

  • Överväg kompetensuppsättningen för ditt utvecklingsteam. Det finns fördelar med att använda flerspråkig beständighet, men det kan också gå överstyr. Det krävs nya kunskaper för att införa en ny datalagringsteknik. För att få ut mesta möjliga av tekniken måste utvecklingsteamet:

    • Optimera frågor.

    • Justera prestanda.

    • Arbeta med lämpliga användningsmönster.

Tänk på dessa faktorer när du väljer en lagringsteknik:

  • Använd kompenserande transaktioner. Med flerspråkig beständighet kan en enda transaktion skriva data till flera butiker. Om det uppstår ett fel kan du använda kompenserande transaktioner för att ångra alla steg som har slutförts.

  • Överväg begränsade kontexter, vilket är ett domändrivet designkoncept. En begränsad kontext är en explicit gräns runt en domänmodell. En begränsad kontext definierar vilka delar av domänen som modellen gäller för. Vi rekommenderar att en begränsad kontext mappas till en underdomän till affärsdomänen. Överväg flerspråkig beständighet för begränsade kontexter i systemet. Till exempel kan produkter visas i produktkatalogens underdomän och underdomänen för produktinventering. Men troligtvis har dessa två underdomäner olika krav för att lagra, uppdatera och fråga produkter.

Azure-underlättande

Azure erbjuder följande tjänster:

  • Azure Functions är en serverlös beräkningstjänst som du kan använda för att skapa orkestrering med minimal kod.

  • Azure Logic Apps är en plattform för serverlös arbetsflödesintegrering som du kan använda för att skapa orkestrering med ett GUI eller genom att redigera en konfigurationsfil.

  • Azure Event Grid är en mycket skalbar, fullständigt hanterad meddelandedistributionstjänst för publicering och prenumeration som erbjuder flexibla mönster för meddelandeförbrukning som använder MQTT- och HTTP-protokollen. Med Event Grid kan du skapa datapipelines med enhetsdata, skapa händelsedrivna serverlösa arkitekturer och integrera program.

Mer information finns i:

Exempel

Ett exempel på en arbetsbelastning som bestämmer komponenter och deras funktioner baserat på krav finns i Reliable Web App pattern (Tillförlitlig webbappsmönster).

Checklista för tillförlitlighet

Se den fullständiga uppsättningen rekommendationer.

Checklista för tillförlitlighet