Introducere în arhitectura cu trei niveluri
Arhitectura cu trei niveluri este cea mai comună arhitectură de interacțiune de pe Internet. A apărut atunci când partea de server cu două niveluri a fost împărțită în două părți: un strat logic și un strat de date .
Arăta cam așa:
Stratul client este partea din „aplicația distribuită” care este responsabilă pentru interacțiunea utilizatorului. Acest strat nu trebuie să conțină logica de afaceri și nu ar trebui să stocheze date critice. De asemenea, nu ar trebui să interacționeze direct cu nivelul bazei de date, ci doar prin stratul logic de afaceri.
Cu toate acestea, există încă ceva logică aici. În primul rând, aceasta este interacțiunea cu utilizatorul prin interfață, validarea datelor introduse de acesta, lucrul cu fișierele locale. Aceasta include, de asemenea, tot ceea ce este legat de autorizarea utilizatorului și criptarea datelor atunci când lucrați cu serverul.
În al doilea rând, este o simplă logică de afaceri. De exemplu, dacă un magazin online a trimis o listă de produse, le putem sorta și filtra din partea clientului. Și stocarea primitivă a datelor este, de asemenea, aici: stocarea în cache, cookie-uri de utilizator conectat și altele asemenea.
Stratul logicii de afaceri este situat la al doilea nivel, cea mai mare parte a logicii de afaceri este concentrată pe acesta. În afara acestuia, rămân doar fragmente care sunt exportate către client, precum și elemente logice care sunt scufundate în baza de date (proceduri stocate și declanșatoare).
O mare parte a serverului de logică de afaceri conține nu numai aceeași logică, dar rezolvă și problemele de scalare: codul este împărțit în părți și distribuit pe diferite servere. Unele servicii foarte solicitate pot rula pe zeci de servere. Sarcina dintre ele este gestionată de echilibrator de încărcare.
Aplicațiile server sunt de obicei proiectate în așa fel încât să poată fi lansată cu ușurință o altă copie a serverului și să înceapă să lucreze în cooperare cu alte copii ale acestuia. Adică, chiar și în procesul de scriere a codului de server, nu veți avea niciodată garanții că clasa dvs. statică este lansată într-o singură instanță.
Stratul de date asigură stocarea datelor și este plasat la un nivel separat, implementat, de regulă, prin intermediul sistemelor de management al bazelor de date (DBMS), conectarea la această componentă este asigurată doar de la nivelul serverului de aplicații.
Motive pentru separarea stratului de date
Separarea stratului de date într-un al treilea strat cu drepturi depline a avut loc din mai multe motive, dar principalul este încărcarea crescută a serverului.
În primul rând, bazele de date au început să necesite multă memorie și timp de procesor pentru procesarea datelor. Prin urmare, au început să fie plasate peste tot pe servere separate.
Cu o încărcare crescută, backend-ul putea fi cu ușurință duplicat și zece copii ale unui server puteau fi ridicate, dar era imposibil să se dubleze baza de date - baza de date rămânea totuși o componentă unică și indivizibilă a sistemului.
În al doilea rând, bazele de date au devenit inteligente - au propria lor logică de afaceri. Au început să accepte proceduri stocate, declanșatoare, propriile limbaje, cum ar fi PLSQL. Și au apărut chiar și programatori care au început să scrie cod care rulează în interiorul DBMS.
Toată logica care nu era legată de date a fost scoasă în backend și lansată în paralel pe zeci de servere. Tot ceea ce este legat în mod critic de date a rămas în SGBD și acolo deja problemele legate de încărcare crescută trebuiau rezolvate folosind propriile noastre metode:
- Un cluster de baze de date este un grup de servere de baze de date care stochează aceleași date și le sincronizează folosind un protocol specific.
- Sharding - datele sunt împărțite în blocuri logice și distribuite pe diferite servere de baze de date. Este foarte dificil să mențineți modificările bazei de date cu această abordare.
- Abordarea NoSQL este de a stoca date în baze de date care sunt construite pentru a stoca cantități uriașe de date. Acestea nu sunt adesea nici măcar baze de date, ci depozite de fișiere specifice. Funcționalitate foarte slabă în comparație cu bazele de date relaționale.
- Memorarea în cache a datelor. În loc de un simplu cache la nivel de bază de date, a apărut întregul SGBD de cache, care a stocat rezultatul doar în memorie.
Este clar că au fost necesare persoane separate și/sau echipe întregi pentru a gestiona această grădină zoologică de tehnologii de server, ceea ce a dus la eliminarea stratului de date într-un strat separat.
Important! Toate tehnologiile avansate se nasc în adâncul marilor corporații IT, când abordările vechi nu mai fac față noilor provocări. Transformarea bazelor de date într-un strat separat nu a fost inventată de niciun programator, ci de un grup de ingineri undeva în adâncurile Oracle sau IBM.
Interesant! Când Zuckerberg a început să scrie Facebook, a lucrat pur și simplu pe PHP + MySQL. Când erau milioane de utilizatori, au scris un traducător special care a tradus tot codul PHP în C ++ și l-a compilat în cod nativ de mașină.
De asemenea, MySQL nu este capabil să stocheze datele a miliarde de utilizatori, așa că Facebook a dezvoltat conceptul de baze de date NoSQL și a scris un SGBD NoSQL puternic pe partea de server - Cassandra. Apropo, este scris complet în Java.
Ambiguitatea locației logicii aplicației
Și, deși o arhitectură pe trei niveluri distribuie aproape fără ambiguitate roluri între părțile sale, nu este întotdeauna posibil să se determine corect exact unde în sistem trebuie adăugată o nouă parte a logicii de afaceri (noul cod).
Un exemplu de astfel de ambiguitate este prezentat în imaginea de mai jos:
Partea server este umplută cu un fundal gri, partea client este umplută cu alb. Un bun exemplu al acestei din urmă abordari (extrema dreapta) sunt aplicațiile mobile moderne. Partea client (pe telefon) conține vizualizarea (afișajul), logica și datele. Și doar uneori aceste date sunt sincronizate cu serverul.
Un exemplu de opțiune din stânga este un server PHP tipic, care are toată logica pe server și oferă clientului HTML deja static. Undeva între aceste două extreme, proiectul tău va fi localizat.
La începutul lucrărilor, după ce vă familiarizați cu proiectul, va trebui să vă consultați cu programatorii care lucrează la el, despre locurile în care este mai bine pentru dvs. să implementați logica sarcinii următoare.
Simțiți-vă liber să faceți acest lucru. În primul rând, ei nu se urcă în mănăstirea altcuiva cu hrisovul lor. În al doilea rând, va fi mai ușor pentru toată lumea (și și pentru dvs.) să găsească codul de care aveți nevoie în locul în care vă așteptați să îl găsiți.