Introduksjon til trelagsarkitektur
Trelagsarkitektur er den vanligste interaksjonsarkitekturen på Internett. Det dukket opp da den to-lags serverdelen ble delt inn i to deler: et logikklag og et datalag .
Det så omtrent slik ut:
Klientlaget er den delen av den "distribuerte applikasjonen" som er ansvarlig for brukerinteraksjon. Dette laget skal ikke inneholde forretningslogikk og skal ikke lagre kritiske data. Den skal heller ikke samhandle direkte med databaselaget, men bare gjennom forretningslogikklaget.
Imidlertid er det fortsatt en viss logikk her. For det første er dette interaksjon med brukeren gjennom grensesnittet, validering av dataene han har lagt inn, arbeid med lokale filer. Dette inkluderer også alt relatert til brukerautorisasjon og datakryptering ved arbeid med serveren.
For det andre er det en enkel forretningslogikk. For eksempel, hvis en nettbutikk sendte en liste over produkter, kan vi sortere og filtrere dem på kundesiden. Og primitiv datalagring er også her: caching, påloggede brukerinformasjonskapsler og lignende.
Forretningslogikklaget er plassert på andre nivå, det meste av forretningslogikken er konsentrert om det. Utenfor den gjenstår bare fragmenter som eksporteres til klienten, samt logiske elementer som er nedsenket i databasen (lagrede prosedyrer og triggere).
En svært del av forretningslogikkserveren inneholder ikke bare den samme logikken, men løser også skaleringsproblemer: koden deles inn i deler og distribueres til forskjellige servere. Noen svært etterspurte tjenester kan kjøre på dusinvis av servere. Lasten mellom dem styres av lastbalanseren.
Serverapplikasjoner er vanligvis utformet på en slik måte at en annen kopi av serveren enkelt kan startes og begynne å fungere i samarbeid med andre kopier av den. Det vil si at selv i prosessen med å skrive serverkode, vil du aldri ha garantier for at den statiske klassen din blir lansert i en enkelt forekomst.
Datalaget gir datalagring og er plassert på et eget nivå, implementert som regel ved hjelp av databasestyringssystemer (DBMS), tilkobling til denne komponenten leveres kun fra applikasjonsservernivået.
Årsaker til å skille datalaget
Separasjonen av datalaget til et fullverdig tredje lag skjedde av mange grunner, men den viktigste er den økte belastningen på serveren.
For det første begynte databaser å kreve mye minne og prosessortid for databehandling. Derfor begynte de å bli plassert overalt på separate servere.
Med økt belastning kunne backend enkelt dupliseres og ti kopier av én server kunne heves, men det var umulig å duplisere databasen - databasen forble fortsatt en enkelt og udelelig komponent av systemet.
For det andre har databaser blitt smarte – de har sin egen forretningslogikk. De begynte å støtte lagrede prosedyrer, triggere, deres egne språk som PLSQL. Og til og med programmerere dukket opp som begynte å skrive kode som kjører inne i DBMS.
All logikk som ikke var knyttet til data ble tatt ut til backend og lansert parallelt på dusinvis av servere. Alt kritisk knyttet til data forble inne i DBMS, og allerede der måtte problemene med den økte belastningen løses ved hjelp av våre egne metoder:
- En databaseklynge er en gruppe databaseservere som lagrer de samme dataene og synkroniserer dem ved hjelp av en bestemt protokoll.
- Deling - data deles inn i logiske blokker og distribueres på tvers av forskjellige databaseservere. Det er svært vanskelig å opprettholde databaseendringer med denne tilnærmingen.
- NoSQL-tilnærmingen er å lagre data i databaser som er bygget for å lagre enorme mengder data. Dette er ofte ikke engang databaser, men spesifikke fillagringer. Svært dårlig funksjonalitet sammenlignet med relasjonsdatabaser.
- Databufring. I stedet for en enkel cache på databasenivå, dukket det opp hele caching DBMS, som bare lagret resultatet i minnet.
Det er klart at det var behov for separate personer og/eller hele team for å administrere denne dyrehagen av serverteknologier, noe som førte til at datalaget ble fjernet i et eget lag.
Viktig! All avansert teknologi er født i dypet av store IT-selskaper, når gamle tilnærminger ikke lenger takler nye utfordringer. Å lage databaser til et eget lag ble ikke oppfunnet av noen programmerer, men av en gruppe ingeniører et sted i dypet av Oracle eller IBM.
Interessant! Da Zuckerberg begynte å skrive Facebook, jobbet han ganske enkelt på PHP + MySQL. Da det var millioner av brukere, skrev de en spesiell oversetter som oversatte all PHP-kode til C++ og kompilerte den til egen maskinkode.
MySQL er heller ikke i stand til å lagre dataene til milliarder av brukere, så Facebook utviklet konseptet med NoSQL-databaser og skrev en kraftig serverside NoSQL DBMS - Cassandra. Den er forresten helt skrevet i Java.
Applikasjonslogikk plassering tvetydighet
Og selv om en trelagsarkitektur nesten entydig fordeler roller mellom delene, er det ikke alltid mulig å bestemme nøyaktig hvor i systemet en ny del av forretningslogikken (ny kode) må legges til.
Et eksempel på slik tvetydighet er vist på bildet nedenfor:
Serverdelen er fylt med grå bakgrunn, klientdelen er fylt med hvit. Et godt eksempel på sistnevnte tilnærming (helt til høyre) er moderne mobilapper. Klientsiden (på telefonen) inneholder visningen (displayet), logikken og dataene. Og bare noen ganger synkroniseres disse dataene med serveren.
Et eksempel på alternativet lengst til venstre er en typisk PHP-server, som har all logikken på serveren, og den gir klienten allerede statisk HTML. Et sted mellom disse to ytterpunktene vil prosjektet ditt bli plassert.
I begynnelsen av arbeidet, etter at du har blitt kjent med prosjektet, må du rådføre deg med programmererne som jobber med det, om stedene der det er bedre for deg å implementere logikken til neste oppgave.
Gjør det gjerne. For det første klatrer de ikke inn i andres kloster med charteret sitt. For det andre vil det være lettere for alle (og deg også) å finne koden du trenger på stedet der du forventer å finne den.