Rekommendationer för att utforma för enkelhet och effektivitet

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

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 hanteringsbelastningar 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

Viktiga designstrategier

En viktig grundsats för design för tillförlitlighet är att hålla saker enkla och effektiva. 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 acceptabelt? Affärskrav driver dessa designöverväganden.

Kompromiss: En komplex lösning kan erbjuda fler funktioner och flexibilitet, men det 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 det ha en negativ effekt på skalbarheten och utökningsbarheten när arbetsbelastningen utvecklas.

Samarbeta med intressenter om designövningar

Arbeta med intressenter för att:

• Definiera och tilldela en kritisk nivå till arbetsbelastningens användarflöden och systemflöden. Fokusera din design på kritiska flöden som hjälper dig att fastställa nödvändiga komponenter och den bästa metoden för att uppnå den nödvändiga återhämtningsnivån.

• 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 bra 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 åtgärdar 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. Fundera på 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 arbetsbelastningens 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 (RPO). 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.

Gynna enklare designval

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öredrar att återanvända 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 hos vanliga mönster och metoder för dina behov. Undvik att följa trender eller rekommendationer som kanske inte passar bäst för din kontext eller dina krav. 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 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 avgör 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.

Välj rätt datalager

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 omstrukturera dem för schema vid skrivning.

• Låskonkurration kan påverka prestanda.

Alternativ till relationsdatabaser

I en stor lösning uppfyller en enda datalagerteknik förmodligen inte 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 fristående dokument. För frågor över hela katalogen kan du indexisera katalogen och lagra indexet i Azure Cognitive Search. Produktinventering 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 bevarade programdata. De innehåller också programloggar, händelser, meddelanden och cacheminnen.

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

• Tänk på 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.

  • Blobar 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 eventuell konsekvensmodell för att uppnå högre tillgänglighet.

• Överväg kunskapsuppsä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äver nya kompetensuppsättningar 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 för 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 persistens kan en enskild transaktion skriva data till flera lager. Om det uppstår ett fel kan du använda kompenserande transaktioner för att ångra alla steg som har slutförts.

• Överväg avgränsade kontexter, vilket är ett domänstyrt 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 persistens 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 köra frågor mot 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 serverlös arbetsflödesintegreringsplattform 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:

• Välj en Azure-beräkningstjänst
• Välj ett beräkningsalternativ för mikrotjänster
• Granska dina dataalternativ

Exempel

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

Relaterade länkar

• Azure serverlös
• Molnbaserade program
• Typer av databaser i Azure

Checklista för tillförlitlighet

Se den fullständiga uppsättningen rekommendationer.