Tredelad arkitektur

Introduktion till treskiktsarkitektur

Treskiktsarkitektur är den vanligaste interaktionsarkitekturen på Internet. Det dök upp när serverdelen med två nivåer var uppdelad i två delar: ett logiskt lager och ett datalager .

Det såg ut ungefär så här:

Klientlagret är den del av den "distribuerade applikationen" som ansvarar för användarinteraktion. Detta lager bör inte innehålla affärslogik och bör inte lagra kritisk data. Det bör inte heller interagera med databaslagret direkt, utan endast genom affärslogiklagret.

Men det finns fortfarande en viss logik här. För det första är detta interaktion med användaren genom gränssnittet, validering av de uppgifter som matats in av honom, arbete med lokala filer. Detta inkluderar även allt som rör användarauktorisering och datakryptering när man arbetar med servern.

För det andra är det en enkel affärslogik. Till exempel, om en onlinebutik skickade en lista med produkter kan vi sortera och filtrera dem på kundsidan. Och primitiv datalagring finns också här: caching, inloggade användarcookies och liknande.

Affärslogikskiktet ligger på den andra nivån, det mesta av affärslogiken är koncentrerad till det. Utanför den återstår endast fragment som exporteras till klienten, såväl som logiska element som är nedsänkta i databasen (lagrade procedurer och triggers).

En mycket del av affärslogikservern innehåller inte bara samma logik, utan löser även skalningsproblem: koden delas upp i delar och distribueras till olika servrar. Vissa mycket efterfrågade tjänster kan köras på dussintals servrar. Belastningen mellan dem hanteras av lastbalanseraren.

Serverapplikationer är vanligtvis utformade på ett sådant sätt att ytterligare en kopia av servern enkelt kan startas och börja arbeta i samarbete med andra kopior av den. Det vill säga, även när du skriver serverkod kommer du aldrig att ha garantier för att din statiska klass lanseras i en enda instans.

Datalagret tillhandahåller datalagring och placeras på en separat nivå, implementerad, som regel, med hjälp av databashanteringssystem (DBMS), anslutning till denna komponent tillhandahålls endast från applikationsservernivån.

Orsaker till att separera datalagret

Separationen av datalagret till ett fullfjädrat tredje lager skedde av många anledningar, men den viktigaste är den ökade belastningen på servern.

Först började databaser kräva mycket minne och processortid för databehandling. Därför började de placeras överallt på separata servrar.

Med ökad belastning kunde backend enkelt dupliceras och tio kopior av en server kunde höjas, men det var omöjligt att duplicera databasen - databasen förblev fortfarande en enda och odelbar komponent i systemet.

För det andra har databaser blivit smarta – de har sin egen affärslogik. De började stödja lagrade procedurer, triggers, sina egna språk som PLSQL. Och till och med programmerare dök upp som började skriva kod som körs inuti DBMS.

All logik som inte var bunden till data togs ut till backend och lanserades parallellt på dussintals servrar. Allt som var kritiskt kopplat till data fanns kvar i DBMS, och redan där måste problemen med den ökade belastningen lösas med våra egna metoder:

• Ett databaskluster är en grupp databasservrar som lagrar samma data och synkroniserar dem med ett specifikt protokoll.
• Sharding - data delas upp i logiska block och distribueras över olika databasservrar. Det är mycket svårt att upprätthålla databasändringar med detta tillvägagångssätt.
• NoSQL-metoden är att lagra data i databaser som är byggda för att lagra enorma mängder data. Dessa är ofta inte ens databaser, utan specifika fillagringar. Mycket dålig funktionalitet jämfört med relationsdatabaser.
• Datacaching. Istället för en enkel cache på databasnivå dök hela cachande DBMS upp, som endast lagrade resultatet i minnet.

Det är tydligt att separata personer och/eller hela team behövdes för att hantera denna zoo av serverteknologier, vilket ledde till att datalagret togs bort i ett separat lager.

Viktig! All avancerad teknologi föds i djupet av stora IT-företag, när gamla metoder inte längre klarar nya utmaningar. Att göra databaser till ett separat lager uppfanns inte av någon programmerare, utan av en grupp ingenjörer någonstans i Oracles eller IBMs djup.

Intressant! När Zuckerberg började skriva Facebook arbetade han helt enkelt på PHP + MySQL. När det fanns miljontals användare skrev de en speciell översättare som översatte all PHP-kod till C++ och kompilerade den till inbyggd maskinkod.

MySQL kan inte heller lagra data från miljarder användare, så Facebook utvecklade konceptet med NoSQL-databaser och skrev ett kraftfullt NoSQL DBMS på serversidan - Cassandra. Det är förresten helt skrivet i Java.

Oklarhet om plats i applikationslogik

Och även om en arkitektur i tre nivåer nästan entydigt fördelar roller mellan sina delar, är det inte alltid möjligt att korrekt avgöra exakt var i systemet en ny del av affärslogiken (ny kod) behöver läggas till.

Ett exempel på sådan tvetydighet visas i bilden nedan:

Serverdelen är fylld med grå bakgrund, klientdelen är fylld med vit. Ett bra exempel på det senare tillvägagångssättet (längst till höger) är moderna mobilappar. Klientsidan (på telefonen) innehåller vyn (display), logik och data. Och bara ibland synkroniseras denna data med servern.

Ett exempel på alternativet längst till vänster är en typisk PHP-server, som har all logik på servern, och den ger klienten redan statisk HTML. Någonstans mellan dessa två ytterligheter kommer ditt projekt att placeras.

I början av arbetet, efter att du har bekantat dig med projektet, måste du rådgöra med de programmerare som arbetar med det, om de platser där det är bättre för dig att implementera logiken i nästa uppgift.

Gör det gärna. För det första klättrar de inte in i någon annans kloster med sin stadga. För det andra blir det lättare för alla (och dig också) att hitta koden du behöver på den plats där du förväntar dig att hitta den.