Introduktion til tre-lags arkitektur
Trelagsarkitektur er den mest almindelige interaktionsarkitektur på internettet. Det dukkede op, da serverdelen i to lag blev opdelt i to dele: et logiklag og et datalag .
Det så nogenlunde sådan her ud:
Klientlaget er den del af den "distribuerede applikation", der er ansvarlig for brugerinteraktion. Dette lag bør ikke indeholde forretningslogik og bør ikke gemme kritiske data. Det bør heller ikke interagere med databaselaget direkte, men kun gennem forretningslogiklaget.
Der er dog stadig en vis logik her. For det første er dette interaktion med brugeren gennem grænsefladen, validering af de data, han indtaster, arbejde med lokale filer. Dette inkluderer også alt relateret til brugerautorisation og datakryptering, når du arbejder med serveren.
For det andet er det en simpel forretningslogik. For eksempel, hvis en onlinebutik sendte en liste over produkter, kan vi sortere og filtrere dem på kundesiden. Og primitiv datalagring er også her: caching, loggede brugercookies og lignende.
Forretningslogiklaget er placeret på andet niveau, det meste af forretningslogikken er koncentreret om det. Uden for den forbliver kun fragmenter, der eksporteres til klienten, samt logiske elementer, der er nedsænket i databasen (lagrede procedurer og triggere).
En meget del af forretningslogikserveren indeholder ikke kun den samme logik, men løser også skaleringsproblemer: koden er opdelt i dele og distribueres til forskellige servere. Nogle meget efterspurgte tjenester kan køre på snesevis af servere. Belastningen mellem dem styres af belastningsbalanceren.
Serverapplikationer er normalt designet på en sådan måde, at en anden kopi af serveren nemt kan startes og begynde at arbejde i samarbejde med andre kopier af den. Det vil sige, selv i processen med at skrive serverkode, vil du aldrig have garantier for, at din statiske klasse bliver lanceret i en enkelt instans.
Datalaget giver datalagring og placeres på et separat niveau, implementeret som regel ved hjælp af databasestyringssystemer (DBMS), forbindelsen til denne komponent leveres kun fra applikationsserverniveauet.
Årsager til at adskille datalaget
Adskillelsen af datalaget til et fuldgyldigt tredje lag skete af mange årsager, men den vigtigste er den øgede belastning på serveren.
For det første begyndte databaser at kræve meget hukommelse og processortid til databehandling. Derfor begyndte de at blive placeret overalt på separate servere.
Med øget belastning kunne backend let duplikeres og ti kopier af én server kunne hæves, men det var umuligt at duplikere databasen – databasen forblev stadig en enkelt og udelelig komponent af systemet.
For det andet er databaser blevet smarte – de har deres egen forretningslogik. De begyndte at understøtte lagrede procedurer, triggere, deres egne sprog, såsom PLSQL. Og selv programmører dukkede op, som begyndte at skrive kode, der kører inde i DBMS.
Al logik, der ikke var bundet til data, blev taget ud til backend og lanceret parallelt på snesevis af servere. Alt kritisk bundet til data forblev inde i DBMS, og allerede dér skulle problemerne med den øgede belastning løses ved hjælp af vores egne metoder:
- En databaseklynge er en gruppe af databaseservere, der gemmer de samme data og synkroniserer dem ved hjælp af en bestemt protokol.
- Sharding - data opdeles i logiske blokke og fordeles på tværs af forskellige databaseservere. Det er meget vanskeligt at vedligeholde databaseændringer med denne tilgang.
- NoSQL-tilgangen er at gemme data i databaser, der er bygget til at gemme enorme mængder data. Disse er ofte ikke engang databaser, men specifikke fillager. Meget dårlig funktionalitet sammenlignet med relationelle databaser.
- Datacaching. I stedet for en simpel cache på databaseniveau dukkede hele caching-DBMS op, som kun lagrede resultatet i hukommelsen.
Det er klart, at der var behov for separate mennesker og/eller hele teams til at styre denne zoo af serverteknologier, hvilket førte til fjernelse af datalaget i et separat lag.
Vigtig! Alle avancerede teknologier fødes i dybet af store it-selskaber, når gamle tilgange ikke længere kan klare nye udfordringer. At lave databaser til et separat lag blev ikke opfundet af nogen programmør, men af en gruppe ingeniører et sted i dybet af Oracle eller IBM.
Interessant! Da Zuckerberg begyndte at skrive Facebook, arbejdede han simpelthen på PHP + MySQL. Da der var millioner af brugere, skrev de en speciel oversætter, der oversatte al PHP-kode til C++ og kompilerede den til indbygget maskinkode.
Desuden er MySQL ikke i stand til at gemme data fra milliarder af brugere, så Facebook udviklede konceptet med NoSQL-databaser og skrev en kraftfuld serverside NoSQL DBMS - Cassandra. Den er i øvrigt fuldstændig skrevet i Java.
Uklarhed om placering af applikationslogik
Og selvom en trelagsarkitektur næsten utvetydigt fordeler roller mellem sine dele, er det ikke altid muligt korrekt at bestemme, præcis hvor i systemet en ny del af forretningslogikken (ny kode) skal tilføjes.
Et eksempel på en sådan tvetydighed er vist på billedet nedenfor:
Serverdelen er fyldt med en grå baggrund, klientdelen er fyldt med hvid. Et godt eksempel på sidstnævnte tilgang (yderst til højre) er moderne mobilapps. Klientsiden (på telefonen) indeholder visningen (display), logik og data. Og kun nogle gange synkroniseres disse data med serveren.
Et eksempel på muligheden længst til venstre er en typisk PHP-server, som har al logikken på serveren, og den giver klienten allerede statisk HTML. Et sted mellem disse to yderpunkter vil dit projekt blive placeret.
I begyndelsen af arbejdet, efter at du har stiftet bekendtskab med projektet, skal du rådføre dig med de programmører, der arbejder på det, om de steder, hvor det er bedre for dig at implementere logikken i den næste opgave.
Gør det gerne. For det første klatrer de ikke ind i andres kloster med deres charter. For det andet vil det være nemmere for alle (og også dig) at finde den kode, du skal bruge, det sted, hvor du forventer at finde den.