🥇Mjukvaruarkitektur och systemdesign: en översikt och resursguide

Hej kollegor.

Idag presenterar vi en översättning av artikeln av Tugberk Ugurlu, som har tagit sig an att kortfattat beskriva principerna för design av moderna mjukvarusystem. Så här beskriver författaren sig själv i sin konklusion:

Eftersom det är nästintill omöjligt att täcka ett så kolossalt ämne som arkitekturmönster + designmönster enligt status 2019, rekommenderar vi inte bara texten av herr Ugurlu, utan också de många länkar han vänligt har inkluderat. Om ni gillar det, publicerar vi även en mer specialiserad text om design av distribuerade system.

Bild Isaac Smith från Unsplash

Om du aldrig har stött på utmaningar som att designa ett mjukvarusystem från grunden, kan det ibland vara oklart var man ska börja när man påbörjar ett sådant arbete. Jag anser att det först och främst är nödvändigt att definiera gränser för att mer eller mindre säkert kunna förstå vad du faktiskt ska designa, och sedan – att sätta igång och arbeta inom dessa gränser. En bra utgångspunkt kan vara att ta en produkt eller tjänst (idealiskt något du verkligen gillar) och analysera dess implementation. Du kanske blir förvånad över hur enkelt denna produkt verkar, och vilken enorm komplexitet som faktiskt döljer sig i den. Kom ihåg: det enkla är oftast komplext, och det är okej.

Jag tror att det bästa rådet jag kan ge till dem som börjar designa ett system är: gör inga antaganden! Från början måste du specificera de fakta som är kända om detta system och de förväntningar som är kopplade till det. Här är några bra frågor vars svar kan hjälpa dig att börja designa:

Vad är problemet vi försöker lösa?
Vad är det maximala antalet användare som kommer att interagera med vårt system?
Vilka mönster för skrivning och läsning av data kommer vi att använda?
Vad är de förväntade felen, hur planerar vi att hantera dem?
Vilka förväntningar finns det beträffande systemets konsistens och tillgänglighet?
Måste vi ta hänsyn till några krav relaterade till extern granskning och reglering?
Vilka typer av konfidentiella data planerar vi att lagra?

Detta är bara några frågor som har varit användbara både för mig och för de team jag har deltagit i under mina yrkesår. Om du känner till svar på dessa frågor (och andra relevanta frågor i den kontext där du arbetar), kan du gradvis fördjupa dig i de tekniska detaljerna av uppgiften.

Vi definierar en utgångsnivå

Vad menar jag här med "utgångsnivå" (baseline)? I våra tider kan egentligen de flesta problem inom mjukvaruindustrin "lösas" med hjälp av redan existerande metoder och teknologier. Därför, när du orienterar dig i detta landskap, får du ett visst försprång när du ställs inför problem som någon annan har löst innan dig. Kom ihåg att program skrivs för att lösa affärs- och användarproblem, därför strävar vi efter att lösa uppgiften på det mest direkta och enkla sättet (sett ur användarens perspektiv). Varför är det viktigt att komma ihåg? Kanske gillar du i ditt koordinatsystem att leta efter unika lösningar på alla uppgifter, eftersom du anser att " vilken programmerare är jag om jag alltid följer mönster"? Faktum är att konsten här ligger i att fatta beslut om var och vad som ska göras.Självklart måste vi alla regelbundet möta unika problem, var och en av dem är en verklig utmaning. Men om vår utgångsnivå är tydligt definierad, vet vi vad vi ska lägga energi på: att söka färdiga lösningar på den uppgift vi har fått, eller att studera den ytterligare för att skapa en djupare förståelse.

Jag tror att jag har lyckats övertyga dig om att om en specialist verkligen förstår arkitekturkomponenten i vissa fantastiska mjukvarusystem, kommer dessa kunskaper att vara ovärderliga för att bemästra arkitektkonsten och bygga en solid grund inom detta område.

Bra, så var ska vi börja? Vid Donna Martin har en repository på GitHub som heter system-design-primer, där du kan lära dig att designa storskaliga system, samt förbereda dig för intervjuer inom detta ämne. I repositorn finns en sektion med exempel på verkliga arkitekturer., där det bland annat diskuteras hur man närmar sig designen av sina system några välkända företag, till exempel Twitter, Uber, osv.

Men innan vi går vidare till detta material, låt oss ta en närmare titt på de viktigaste arkitektoniska utmaningar som praktiken ställs inför. Detta är viktigt eftersom det innebär att man måste specificera MÅNGA aspekter av ett komplext och mångfacetterat problem, och sedan lösa det inom de regelverk som gäller för detta system. Jackson Gabbard, tidigare anställd på Facebook, spelade in ett 50-minutersvideo om intervjuer kring systemdesign, där han delade med sig av sina egna erfarenheter från att ha granskat hundratals kandidater. Trots att videon tydligt handlar om design av stora system och kriterier för framgång, som är viktiga vid rekrytering för en sådan tjänst, kommer den ändå att fungera som en fullständig resurs om vad som är mest betydelsefullt vid systemdesign. Jag föreslår även en sammanfattning av denna video.

Bygg upp kunskaper om datalagring och -hämtning

I allmänhet påverkar ditt beslut om hur du långsiktigt kommer att lagra och leverera dina data kritiskt systemets prestanda. Därför måste du framför allt förstå de förväntade egenskaperna för skrivning och läsning av data i ditt system. Sedan måste du kunna utvärdera dessa parametrar och göra val baserat på dessa uppskattningar. Men för att kunna hantera detta arbete effektivt måste du ha kunskap om befintliga datalagringsmönster. I princip förutsätter detta gedigna kunskaper relaterade till val av databas.

Databaser kan betraktas som datatyper med exceptionell skalbarhet och hållbarhet. Därför kommer kunskap om datatyper att vara mycket användbar för dig även vid valet av en viss databas. Till exempel Redis – är en databasserver som stöder olika typer av värden. Den möjliggör arbete med datatyper som listor och mängder, samt läsning av data med hjälp av välkända algoritmer, såsom LRU, organiserar detta arbete på ett hållbart och hög- tillgängligt sätt.

Bild Samuel Zeller från Unsplash

När du har tillräckligt med kunskap om olika datalagringsmönster – gå vidare till att studera konsistens och tillgänglighet av data. Först och främst behöver du förstå CAP-teoremet åtminstone i grova drag, och sedan finslipa dessa kunskaper genom att noggrant undersöka etablerade mönster konsistens och tillgänglighet. På så sätt kommer du att bredda din horisont inom detta område och förstå att läsning och skrivning av data i själva verket är två mycket olika problem, och var och en av dem har sina egna särskilda utmaningar. Beväpnad med några mönster för att säkerställa konsistens och tillgänglighet kommer du att kunna avsevärt öka systemets prestanda, samtidigt som du garanterar en oavbruten tillgång till data för dina applikationer.

Slutligen, när vi avslutar diskussionen om datalagringsfrågor, bör vi också nämna cachelagring. Ska den utföras samtidigt på klienten och servern? Vilka data kommer att finnas i din cache? Och varför? Hur organiserar du cache-invalidering? Kommer det att utföras regelbundet, med vissa intervall? Om ja – hur ofta? Jag rekommenderar att du börjar behandlingen av dessa ämnen med nästa avsnitt den ovan nämnda handboken om systemdesign.

Kommunikationsmönster

System består av olika komponenter; dessa kan vara både olika processer som arbetar inom samma fysiska enhet och olika maskiner som agerar i olika delar av ditt nätverk. Vissa av dessa resurser inom ditt nätverk kan vara privata, men andra måste vara offentliga och öppna för konsumenter som kontaktar dem utifrån.

Det är nödvändigt att säkerställa kommunikationen mellan dessa resurser och även informationsutbytet mellan hela systemet och omvärlden. I sammanhanget av systemdesign står vi här återigen inför en uppsättning nya unika utmaningar. Vi undersöker hur asynkrona uppgiftsflöden, samt vilka olikakommunikationsmönster som finns tillgängliga.

Bild Tony Stoddard från Unsplash

Vid organiseringen av kommunikationen med omvärlden är det alltid mycket viktigt säkerhet, vilket också måste närmas med största allvar och aktivt skötas.

Fördelning av anslutningar

Jag är inte säker på att det är motiverat att lyfta fram detta ämne i en separat sektion. Ändå kommer jag här att utförligt redogöra för denna koncept, och jag anser att materialet i denna sektion bäst beskriver termen "anslutningsfördelning" (connection distribution).

System bildas genom att korrekt koppla samman många komponenter, och deras kommunikation med varandra organiseras ofta på grundval av etablerade protokoll, som till exempel TCP och UDP. Men dessa protokoll är ofta otillräckliga för att tillfredsställa alla behov hos moderna system som ofta körs under hög belastning och som dessutom är starkt beroende av användarnas behov. Det kan ofta vara nödvändigt att hitta sätt att fördela anslutningar för att hantera sådana hög belastningar i systemet.

Grunden för sådan fördelning ligger i det välkända domännamnssystemet (DNS). Detta system möjliggör omvandling av domännamn, till exempel viktscyklisk algoritm (weighted round robin) och metoder baserade på latens, som hjälper till att fördela belastningen.

Lastbalansering är grundläggande och praktiskt taget varje stort system på Internet, som vi har att göra med idag, ligger bakom en eller flera belastningsbalanserare. Belastningsbalanserare hjälper till att fördela klientförfrågningar mellan flera tillgängliga instanser. Belastningsbalanserare kan vara både hårdvarubaserade och mjukvarubaserade, men i praktiken handlar vi oftast med mjukvarubaserade, som till exempel HAProxy och ELB. Omvända proxyservrar är i princip också mycket likartade belastningsbalanserare, även om det finns en rad tydliga skillnader. Dessa skillnader måste beaktas när man designar ett system utifrån dina behov.

Det är också viktigt att förstå innehållsleveransnätverk (CDN). CDN är ett globalt distribuerat nätverk av proxyservrar som levererar information från de noder som geografiskt ligger närmast en specifik användare. CDN-nätverk är att föredra när du arbetar med statiska filer skrivna i JavaScript, CSS och HTML. Dessutom är det idag vanligt med sådana molntjänster där trafikhanterare erbjuds, till exempel Azure Traffic Manager, som ger dig global distribution och minskad fördröjning vid arbete med dynamiskt innehåll. Men sådana tjänster är vanligtvis användbara i situationer där man arbetar med tillståndslösa webbservices.

Låt oss prata om affärslogik. Strukturerande affärslogik, arbetsflöden och komponenter

Så, vi har hunnit diskutera olika infrastrukturaspekter av systemet. Användaren tänker troligen inte ens på alla dessa element i ditt system och, ärligt talat, bryr de sig överhuvudtaget inte om dem. Användarna är intresserade av hur det är att interagera med ditt system, vad man kan uppnå genom att agera på detta sätt, samt hur systemet utför användarens kommandon, vad som görs med användardata.

Som titeln på denna artikel antyder, tänkte jag berätta om mjukvaruarkitektur och systemdesign. Därför planerade jag inte att gå in på designmönster för mjukvara, vilka beskriver hur programkomponenter skapas. Men ju mer jag funderar på det, desto mer känns det som att gränsen mellan designmönster för mjukvara och arkitektoniska mönster är mycket otydlig, och dessa två begrepp är tätt sammanlänkade. Låt oss till exempel ta event sourcing. Så snart du tillämpar detta arkitektoniska mönster – kommer det att påverka nästan alla aspekter av ditt system: långsiktig datalagring, nivån av konsistens som accepteras i ditt system, konturerna av komponenterna i den, osv. Därför har jag beslutat att nämna några arkitektoniska mönster som direkt rör affärslogik. Även om denna artikel kanske tvingas begränsa sig till en enkel lista, rekommenderar jag att du bekantar dig med den och reflekterar över idéerna som rör dessa mönster. Här är den:

Kollaborativa metoder

Det är mycket osannolikt att du kommer att vara den enda personen ansvarig för designprocessen av systemet i projektet. Snarare kommer du troligen att behöva samarbeta med kollegor som arbetar både inom och utanför din uppgift. I detta fall kan det bli nödvändigt att utvärdera de valda teknologiska lösningarna tillsammans med kollegor, identifiera affärsbehov och förstå hur man bäst kan parallellisera uppgifter.

Bild Kaleidico från Unsplash

Först och främst måste ett exakt och allmänt accepterat begrepp utvecklas om vilket affärsmål du försöker nå och vilka rörliga delar du kommer att behöva hantera. Metoder för gruppmodellering, särskilt event storming hjälper avsevärt att snabba upp denna process och ökar dina chanser till framgång. Detta arbete kan utföras innan eller efter att du har skisserat gränserna för dina tjänster, och sedan fördjupa det i takt med att produkten mognar. Baserat på den nivå av enighet som uppnås här kan du också formulera ett gemensamt språk för det begränsade sammanhang där du arbetar. När det är dags att prata om arkitekturen för ditt system kan en C4-modell, föreslagen av Simon Brown, vara till stor hjälp, särskilt när det handlar om att förstå hur mycket du behöver gå in på detaljer när du visualiserar de saker du vill kommunicera.

Det finns förmodligen också annan mogen teknik inom detta ämne som är lika användbar som domänorienterad design. Men vi återkommer hur som helst till förståelsen av ämnesområdet, så kunskap och erfarenhet inom domänorienterad design kommer att vara till nytta för dig.

Källa: habr.com

Programvaruarkitektur och systemdesign: en översikt och resursguide.