Architectuur op drie niveaus

Inleiding tot drieledige architectuur

Three-tier-architectuur is de meest voorkomende interactie-architectuur op internet. Het verscheen toen het two-tier servergedeelte in twee delen werd opgedeeld: een logische laag en een datalaag .

Het zag er ongeveer zo uit:

De clientlaag is het deel van de "gedistribueerde applicatie" dat verantwoordelijk is voor gebruikersinteractie. Deze laag mag geen bedrijfslogica bevatten en mag geen kritieke gegevens bevatten. Het mag ook niet rechtstreeks communiceren met de databaselaag, maar alleen via de bedrijfslogicalaag.

Er zit hier echter nog enige logica in. Ten eerste is dit interactie met de gebruiker via de interface, validatie van de door hem ingevoerde gegevens, werken met lokale bestanden. Dit omvat ook alles met betrekking tot gebruikersautorisatie en gegevenscodering bij het werken met de server.

Ten tweede is het een eenvoudige bedrijfslogica. Als een online winkel bijvoorbeeld een lijst met producten heeft verzonden, kunnen we deze aan de kant van de klant sorteren en filteren. En primitieve gegevensopslag is er ook: caching, ingelogde gebruikerscookies en dergelijke.

De bedrijfslogica-laag bevindt zich op het tweede niveau, de meeste bedrijfslogica is daarop geconcentreerd. Daarbuiten blijven alleen fragmenten over die naar de client worden geëxporteerd, evenals logische elementen die in de database zijn ondergedompeld (opgeslagen procedures en triggers).

Een groot deel van de zakelijke logische server bevat niet alleen dezelfde logica, maar lost ook schaalproblemen op: de code wordt opgedeeld in delen en gedistribueerd naar verschillende servers. Sommige veelgevraagde services kunnen op tientallen servers worden uitgevoerd. De belasting daartussen wordt beheerd door de load balancer.

Serverapplicaties zijn meestal zo ontworpen dat een andere kopie van de server gemakkelijk kan worden gestart en kan gaan werken in samenwerking met andere kopieën ervan. Dat wil zeggen, zelfs tijdens het schrijven van servercode heb je nooit de garantie dat je statische klasse in één keer wordt gestart.

De gegevenslaag zorgt voor gegevensopslag en wordt op een apart niveau geplaatst, in de regel geïmplementeerd door middel van databasebeheersystemen (DBMS), verbinding met dit onderdeel wordt alleen geleverd vanaf het niveau van de applicatieserver.

Redenen voor het scheiden van de gegevenslaag

De scheiding van de gegevenslaag in een volwaardige derde laag vond om vele redenen plaats, maar de belangrijkste is de verhoogde belasting van de server.

Ten eerste begonnen databases veel geheugen en processortijd te vergen voor gegevensverwerking. Daarom werden ze overal op afzonderlijke servers geplaatst.

Met verhoogde belasting kon de backend gemakkelijk worden gedupliceerd en konden tien exemplaren van één server worden verhoogd, maar het was onmogelijk om de database te dupliceren - de database bleef nog steeds een enkele en ondeelbare component van het systeem.

Ten tweede zijn databases slim geworden - ze hebben hun eigen bedrijfslogica. Ze begonnen opgeslagen procedures, triggers, hun eigen talen zoals PLSQL te ondersteunen. En er verschenen zelfs programmeurs die code begonnen te schrijven die in het DBMS draait.

Alle logica die niet aan data was gebonden, werd naar de backend gebracht en parallel gelanceerd op tientallen servers. Alles wat kritisch aan gegevens was gekoppeld, bleef binnen het DBMS en daar moesten de problemen van de verhoogde belasting al worden opgelost met behulp van onze eigen methoden:

• Een databasecluster is een groep databaseservers die dezelfde gegevens opslaan en synchroniseren met behulp van een specifiek protocol.
• Sharding - gegevens worden opgesplitst in logische blokken en verdeeld over verschillende databaseservers. Het is erg moeilijk om databasewijzigingen bij te houden met deze aanpak.
• De NoSQL-benadering is om gegevens op te slaan in databases die zijn gebouwd om enorme hoeveelheden gegevens op te slaan. Dit zijn vaak niet eens databases, maar specifieke bestandsopslagplaatsen. Zeer slechte functionaliteit in vergelijking met relationele databases.
• Gegevenscaching. In plaats van een eenvoudige cache op databaseniveau verscheen een volledig caching DBMS, dat het resultaat alleen in het geheugen opsloeg.

Het is duidelijk dat er aparte mensen en/of hele teams nodig waren om deze dierentuin van servertechnologieën te beheren, wat leidde tot het verwijderen van de datalaag naar een aparte laag.

Belangrijk! Alle geavanceerde technologieën worden geboren in de krochten van grote IT-bedrijven, wanneer oude benaderingen nieuwe uitdagingen niet langer aankunnen. Het maken van databases in een aparte laag is niet door een programmeur bedacht, maar door een groep ingenieurs ergens in de krochten van Oracle of IBM.

Interessant! Toen Zuckerberg Facebook begon te schrijven, werkte hij simpelweg aan PHP + MySQL. Toen er miljoenen gebruikers waren, schreven ze een speciale vertaler die alle PHP-code vertaalde naar C++ en compileerde naar native machinecode.

MySQL is ook niet in staat om de gegevens van miljarden gebruikers op te slaan, dus ontwikkelde Facebook het concept van NoSQL-databases en schreef een krachtige server-side NoSQL DBMS - Cassandra. Het is trouwens volledig geschreven in Java.

Onduidelijkheid over locatie van toepassingslogica

En hoewel een three-tier architectuur de rollen vrijwel eenduidig ​​verdeelt over de onderdelen, is het niet altijd mogelijk om precies te bepalen waar in het systeem een ​​nieuw onderdeel van de bedrijfslogica (nieuwe code) moet worden toegevoegd.

Een voorbeeld van een dergelijke dubbelzinnigheid wordt getoond in de onderstaande afbeelding:

Het servergedeelte is gevuld met een grijze achtergrond, het clientgedeelte is gevuld met wit. Een goed voorbeeld van die laatste benadering (uiterst rechts) zijn moderne mobiele apps. De clientzijde (aan de telefoon) bevat de weergave (weergave), logica en gegevens. En slechts af en toe worden deze gegevens gesynchroniseerd met de server.

Een voorbeeld van de meest linkse optie is een typische PHP-server, die alle logica op de server heeft staan ​​en de client al statische HTML geeft. Ergens tussen deze twee uitersten zal uw project zich bevinden.

Aan het begin van het werk, nadat u kennis heeft gemaakt met het project, moet u overleggen met de programmeurs die eraan werken, over de plaatsen waar u de logica van de volgende taak beter kunt implementeren.

Voel je vrij om dit te doen. Ten eerste klimmen ze niet met hun handvest in het klooster van iemand anders. Ten tweede zal het voor iedereen (en ook voor jou) gemakkelijker zijn om de code die je nodig hebt te vinden op de plek waar je hem verwacht te vinden.